Oracle 5.0, Справочное руководство

Страница: 1513 / 3232

Switching Masters During Failover
1493
• If your slaves are not acting as masters, and you have a potential solution in place to ensure
that you can bring up a master in the event of failure, then you can switch off
--log-slave-
updates
[1451] . This prevents “dumb” slaves from also logging events they have executed into
their own binary log.
16.3.6. Switching Masters During Failover
There is currently no official solution for providing failover between master and slaves in the event
of a failure. With the currently available features, you would have to set up a master and a slave (or
several slaves), and to write a script that monitors the master to check whether it is up. Then instruct
your applications and the slaves to change master in case of failure.
Remember that you can tell a slave to change its master at any time, using the
CHANGE MASTER TO
statement. The slave will not check whether the databases on the master are compatible with the
slave, it will just start reading and executing events from the specified binary log coordinates on the
new master. In a failover situation, all the servers in the group are typically executing the same events
from the same binary log file, so changing the source of the events should not affect the database
structure or integrity providing you are careful.
Run your slaves with the
--log-bin
[1467] option and without
--log-slave-updates
[1451] . In
this way, the slave is ready to become a master as soon as you issue
STOP SLAVE
;
RESET MASTER
,
and
CHANGE MASTER TO
statement on the other slaves. For example, assume that you have the
structure shown in Figure 16.4, “Redundancy Using Replication, Initial Structure” .
Figure 16.4. Redundancy Using Replication, Initial Structure
In this diagram, the
MySQL Master
holds the master database, the
MySQL Slave
hosts are
replication slaves, and the
Web Client
machines are issuing database reads and writes. Web clients
that issue only reads (and would normally be connected to the slaves) are not shown, as they do not
need to switch to a new server in the event of failure. For a more detailed example of a read/write
scale-out replication structure, see
Section 16.3.3, “Using Replication for Scale-Out” .