Oracle 5.0 Reference Manual page 1514

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