Databases Reference
In-Depth Information
monitor replication delay, and help maintain metadata such as binary log positions,
which can ease the problems with some of the strategies we just discussed.
If you don't care how much hardware it takes to serve your load, you can keep things
simpler and not use replication for scaling reads. That might let you avoid the com-
plexity of splitting reads between the master and replicas. Some people think this makes
sense; others think it wastes hardware. This division reflects differing goals: do you
want scalability only, or both scalability and efficiency? If you want efficiency too, and
thus want to use the replicas for something other than just keeping a copy of the data,
you'll probably have to deal with some added complexity.
Changing the application configuration
One way you can distribute load is to reconfigure your application. For example, you
can configure several machines to share the load of generating large reports. Each ma-
chine's configuration can instruct it to connect to a different MySQL replica and gen-
erate reports for every
N
th customer or site.
This system is generally very simple to implement, but if it requires any code changes—
including changes to configuration files—it becomes brittle and unwieldy. Anything
hardcoded that you have to change on every server, or change in a central location and
“publish” via file copies or source-control update commands, is inherently limited. If
you store the configuration in the database and/or a cache, you can avoid the need to
publish code changes.
Changing DNS names
A crude load-balancing technique, but one that works acceptably for some simple ap-
plications, is to create DNS names for various purposes. You can then point the names
at different servers as appropriate. The simplest implementation is to have one DNS
name for the read-only servers and one for the writable server. If the replicas are keeping
up with the master, you can change the read-only DNS name to point to the replicas;
when they fall behind, you can point it back to the master.
The DNS technique is very easy to implement, but it has many drawbacks. The biggest
problem is that DNS is not completely under your control:
• DNS changes are not instantaneous or atomic. It can take a long time for DNS
changes to propagate throughout a network or between networks.
• DNS data is cached in various places, and expiry times are advisory, not mandatory.
• DNS changes might require an application or server restart to take effect fully.
• It's not a good idea to use multiple IP addresses for a DNS name and rely on round-
robin behavior to balance requests. The round-robin behavior isn't always
predictable.
• The DBA might not always have direct access to DNS.
