I have some questions about the failover approach described in this article.
As I understand it, MySQL replication works as follows:
1. Begin with identical baseline copies of the database on both master and slaves;
2. Make changes to the master database, logging the changes in the binlog files.
3. Asynchronously propogate the changes (from the binlogs) to relay logs on each slave and apply the changes to the slave database. Each slave will likely be at a slightly different position in the master's binlogs (master-binlogfile/position), due to factors like local load and propogation delay.
4. If a slave has log-slave-updates turned on, it will write the changes into its own binlogs. Although each slave-binlogfile/position will correspond to a master-binlogfile/position, both the filename and the position will likely be different.
In the 'normal' failover scenario a failed master is replaced with a former slave, starting replication for all other slaves at the new master's 'mysql-bin.000001', position 0. Would this cause to the other slaves to attempt to repeat all previous transactions? I can see many issues with this, starting with unique key collisions.
In the circular replication scenario, if a server fails, its slave changes to another master without specifying a binlogfile/position. Does this mean that the the slave uses the old master's binlog name and position with the new master?
Database changes applied at each server will be propagating asynchronously around the circle. It seems unlikely that all servers will all be at exactly the same binlog/position. Is it possible that a slave will ask its new master for a binlog/position from some time in the past or that doesn't yet exist?