GTID replication has made it convenient to setup and maintain MySQL replication. You need not worry about binary log file and position thanks to GTID and auto-positioning. However, things can go wrong when pointing a slave to a different master. Consider a situation where the new master has executed transactions that haven’t been executed on the old master. If the corresponding binary logs have been purged already, how do you point the slave to the new master?
Based on technical requirements and architectural change, there is a need to point the slave to a different master by
- Pointing it to another node in a PXC cluster
- Pointing it to another master in master/master replication
- Pointing it to another slave of a master
- Pointing it to the slave of a slave of the master … and so on and so forth.
Theoretically, pointing to a new master with GTID …[Read more]