而较量贫苦的处所是：由于同一个事务在每台处事器上地址的 binlog 名字和 Postion 位置点都纷歧样，那么怎么找到 slave2 当前同步遏制点，对应 New Master 的 master_log_file 和 Master_log_pos 是什么的时候就成为了困难。这也就是为什么 M-S 复制集群需要利用 MMM,MHA 这样的特别打点东西的一个重要原因。
其实也可以找到，只是较量贫苦，我们都知道主从复制情况中 master 的 binlog 复制到 slave 上后 事务执行时的时间戳是稳定的，所有 slave 上同一个事务的时间戳都是沟通的。可以按照这个时间戳定位到 Master_log_file 和 Master_log_pos。只是很费时间；贫苦。。。
GTID 呈现之后：
在 MySQL 5.6 的 GTID 呈现之后，处理惩罚这个问题就很是简朴了。
由于同一个事务的 GTID 在所有的节点上都是一致的，那么按照 Slave 当前遏制点的 GTID 就能唯必然位到 New Master 的 GTID。
更简朴的是，由于 MASTER_AUTO_POSITION 成果的呈现，我们都不需要知道 GTID 的详细值。直接利用
mysql> CHANGE MASTER TO
MASTER_HOST='XXXX',
MASTER_USER='XXXXX',
MASTER_PASSWORD='XXXXX',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;
呼吁就可以直接完成 failover 的事情了。利用 GTID 处理惩罚这个问题就简朴许多。
Linux公社的RSS地点：https://www.linuxidc.com/rssFeed.aspx