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 forget the --demote-master option 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.

User Comments
Sign Up Login You must be logged in to post a comment.