Databases Reference
In-Depth Information
If you need to recover missing events from the old master, we recommend that you do
so
after
you promote the new master, but
before
you let clients connect to it. This way,
you won't have to execute the missing events on every replica; replication will take care
of that for you. If the failed master is totally unavailable, however, you might have to
wait and do this work later.
A variation on this procedure is to use a reliable way to store the master's binary log
files, such as a SAN or a distributed replicated block device (DRBD). Even if the master
has a complete failure, you'll still have its binary log files. You can set up a log server,
point the replicas to it, and then let them all catch up to the point at which the master
failed. This makes it trivial to promote one of the replicas to be a new master—it's
essentially the same process we showed for a planned promotion. We discuss these
storage options further in the next chapter.
When you promote a replica to master, don't change its server ID to
match the old master's. If you do, you won't be able to use a log server
to replay events from the old master. This is one of many reasons it's a
good idea to treat server IDs as fixed.
Switching Roles in a Master-Master Configuration
One of the advantages of master-master replication is that you can switch the active
and passive roles easily, because of the symmetrical configuration. In this section, we
show you how to accomplish the switch.
When switching the roles in a master-master configuration, the most important thing
is to ensure that only one of the co-masters is written to at any time. If writes from one
master are interleaved with writes from the other, the writes can conflict. In other
words, the passive server must not receive any binary log events from the active server
after the roles are switched. You can guarantee this doesn't happen by ensuring that
the passive server's replication SQL thread is caught up to the active server before you
make it writable.
The following steps switch the roles without danger of conflicting updates:
1. Stop all writes on the active server.
2. Execute
SET GLOBAL read_only = 1
on the active server, and set the
read_only
option in its configuration file for safety in case of a restart. Remember, this won't
stop users with the
SUPER
privilege from making changes. If you want to prevent
changes from all users, use
FLUSH TABLES WITH READ LOCK
. If you don't do this, you
must kill all client connections to make sure there are no long-running statements
or uncommitted transactions.
3. Execute
SHOW MASTER STATUS
on the active server and note the binary log coordi-
nates.
