Databases Reference
In-Depth Information
out of your control, such as DNS changes or application configuration files. Some of
the worst problems don't show up until a system becomes larger, when issues such as
forced application restarts and the need for atomicity rear their heads.
Because load balancing and failover are closely related, and the same piece of hardware
or software often serves both purposes, we suggest that any load-balancing technique
you choose should provide failover capabilities as well. This is the real reason we sug-
gested you avoid DNS or code changes for load balancing. If you use these strategies
for load balancing, you'll create extra work: you'll have to rewrite the affected code
later when you need high availability.
The following sections discuss some common failover techniques. You can perform
these manually, or use tools to accomplish them.
Promoting a Replica or Switching Roles
Promoting a replica to master, or switching the active and passive roles in a master-
master replication setup, is an important part of many failover strategies for MySQL.
See
Chapter 10
for detailed explanations of how to accomplish this manually. As men-
tioned earlier in this chapter, we aren't aware of any automated tools that always do
the right thing in all situations—or at least, none that we'll put our reputations behind.
Depending on your workload, you shouldn't assume that you can fail over to a passive
replica instantly. Replicas replay the master's writes, but if you're not also using them
for reads, they will not be warmed up to serve the production workload. If you want a
replica to be ready for read traffic, you have to continuously “train” it, either by letting
it participate in the production workload or by mirroring production read queries onto
it. We've sometimes done this by sniffing TCP traffic, filtering out everything but
SELECT
queries, and replaying those against the replica. Percona Toolkit has tools that
can help with this.
Virtual IP Addresses or IP Takeover
You can assign a logical IP address to a MySQL instance that you expect to perform
certain services. If the MySQL instance fails, you can move the IP address to a different
MySQL server. This is essentially the same approach we wrote about in the previous
chapter, except that now we're using it for failover instead of load balancing.
The benefit of this approach is its transparency for the application. It will abort existing
connections, but it doesn't require you to change your application's configuration. It
is also sometimes possible to move the IP address atomically, so all applications see the
change at the same time. This can be especially important when a server is “flapping”
between available and unavailable states.
The downsides are as follows:
