Quick Comment on MySQL Clustering - master.info
Let\'s consider a relatively typical scenario: MySQL with clustering, Master instance and Slave instance. The master processes day-to-day operations and Slave is in standby to kick-in if something happens to the master.
Let\'s now imagine a stormy, cold Monday that Master decided to die on. Sysadmin quickly re-configures slave to kick-in as Master. Another sysadmin figures-out the problem with ex-master and reincarnates it. However, Manager decides that the swap-back can not be allowed until the weekend (4 days left, huh?). Sysadmin decides that to minimize the risks, it\'s the best to setup ex-master as the slave of the now-master (ex-slave). Who knows if the current master decides to die, too? What will we fail-over to, in that case?
Pretty reasonable assumption and come weekend the sysadmin re-configures my.cnf files, once again - restarts servers + some magic that goes with it and proud of himself goes home...
Alert: bad move. It may be too late but eventually the sysadmin will find out that even though he re-configured ex-slave to be master now, it still continues to be slave, as well. He will be very surprised because he definitely edited my.cnf and made sure that it removes all slave properties makes the server purely master. So - what the heck?
MySQL creates master.info file for a slave database. Even if you edit my.cnf and remove all traces of the instance being slave, it will still remain to be slave unless you delete the master.info file.
Do not forget to remove master.info if you do not want a MySQL instance to be a slave, anymore.