As with our previous scenario we used the mysqlreplicate utility to set up a replication topology between the existing server and the two new servers. Notice the use of the -b flag which this replication start from the first event recorded in the master's binary log.
After setting our replication topology we made use of the mysqlrpladmin utility specifying both the master and slave servers and using the health command to check the status of the replication. Since our master server had lots of information, it is normal for the new slaves to take some time to catch up, thus the slave delay message on the health column of the output.
However, if all goes well, after some time the slaves will
eventually catch up, and when that happens, the
health column will show an OK status.
When this happened, we used the
mysqlrpladmin utility yet again, this time
with switchover command. Using the
--new-master option we
specify the server that will become the new master. We can not
which turns the old master into a slave, otherwise it would
still behave as a master just without any slaves, Server3 will
become a slave of Server2.
After the switchover, Server2 becomes the master server for both Server1 and Server3 which are now the slaves.