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

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

Switching Masters During Failover
1494
Each MySQL Slave (
Slave 1
,
Slave 2
, and
Slave 3
) is a slave running with
--log-bin
[1467]
and without
--log-slave-updates
[1451] . Because updates received by a slave from the master
are not logged in the binary log unless
--log-slave-updates
[1451] is specified, the binary log on
each slave is empty initially. If for some reason
MySQL Master
becomes unavailable, you can pick
one of the slaves to become the new master. For example, if you pick
Slave 1
, all
Web Clients
should be redirected to
Slave 1
, which will log updates to its binary log.
Slave 2
and
Slave 3
should then replicate from
Slave 1
.
The reason for running the slave without
--log-slave-updates
[1451] is to prevent slaves from
receiving updates twice in case you cause one of the slaves to become the new master. Suppose that
Slave 1
has
--log-slave-updates
[1451] enabled. Then it will write updates that it receives from
Master
to its own binary log. When
Slave 2
changes from
Master
to
Slave 1
as its master, it may
receive updates from
Slave 1
that it has already received from
Master
Make sure that all slaves have processed any statements in their relay log. On each slave, issue
STOP
SLAVE IO_THREAD
, then check the output of
SHOW PROCESSLIST
until you see
Has read all
relay log
. When this is true for all slaves, they can be reconfigured to the new setup. On the slave
Slave 1
being promoted to become the master, issue
STOP SLAVE
and
RESET MASTER
.
On the other slaves
Slave 2
and
Slave 3
, use
STOP SLAVE
and
CHANGE MASTER TO
MASTER_HOST='Slave1'
(where
'Slave1'
represents the real host name of
Slave 1
). To use
CHANGE MASTER TO
, add all information about how to connect to
Slave 1
from
Slave 2
or
Slave
3
(
user
,
password
,
port
). In
CHANGE MASTER TO
, there is no need to specify the name of the
Slave 1
binary log file or log position to read from: We know it is the first binary log file and position 4,
which are the defaults for
CHANGE MASTER TO
. Finally, use
START SLAVE
on
Slave 2
and
Slave
3
.
Once the new replication is in place, you will then need to instruct each
Web Client
to direct its
statements to
Slave 1
. From that point on, all updates statements sent by
Web Client
to
Slave 1
are written to the binary log of
Slave 1
, which then contains every update statement sent to
Slave 1
since
Master
died.
The resulting server structure is shown in Figure 16.5, “Redundancy Using Replication, After Master
Failure” .