一、前言
msyql 切换主库一般都是用高可用方案，例如MHA,MGR，高可用方案可以自动切主，但是MHA的failover功能无法把旧主自动挂到新主上作为从库使用，所以发生failover后，还需要手动把旧的主库作为备库挂到新的主库上。此时常规操作就是备份新主库，然后应用到旧主库上，然后再重新搭建主从。但是如果数据量非常大（例如TB级数据），备份就会耗费大量的时间和磁盘空间，这时候最佳方案就是不备份，利用gtid原理和binlog直接把旧的主库挂到新的主库上搭建好主从（下文会详细介绍）还有就是没有用高可用架构的情况，只有主从集群，如果遇到需要切换的情况（比如物理机需要停机，日常计划中维护），这时也需要手动切换，此时也可以不用备份，利用gtid原理和binlog直接把旧的主库挂到新的主库上搭建好主从。注意，这种方式的切换必须要开启gtid，否则change master to 时需要自己手动去找对应的binlog file 和 position号。
二、手动切换操作实验
现在我们给两个mysql实例起名叫A，B，A是主库，B是备库1、把原主从集群断开，在从库(B实例)上操作
stop slave;
reset slave all;
2、查看原主库(A实例)binlog情况
3、查看原备库(B实例)binlog情况
3cb75db8-6bf6-11ee-b1ce-0050569149b4:1-142 这个是模拟切换过程中向新的主库(B实例)写入数据，B实例自己产生的gtid事务。
4、把老的主库(A实例)挂到新的主库(B实例)上面,在A实例上操作
change master to
master_host='192.168.167.133',
master_user='repl',
master_password='111222',
master_port=3306,
MASTER_AUTO_POSITION=1;
start slave;
show slave status\G 查看没有问题
5、查看新从库(A实例)binlog情况
可以看到B实例上的事务3cb75db8-6bf6-11ee-b1ce-0050569149b4:1-142 也都被接收并写入A实例了。
至此，手动切换实验完成，下面我们看下master_auto_position 这个参数的原理
三、master_auto_position 参数原理
我们知道开启gtid事务后，就不用指定file 和 position 号了，master_auto_position这个参数会自动去找主库上的事务，那它是怎么找的呢？下面是官网的描述：
这句话意思是，在执行change master to 命令后，从库会发送一个GTID SET，其中包含它已经接收、提交或两者兼而有之的事务，这个gtid set就是show master status;命令结果中的Executed_Gtid_Set字段值。
下面我们来验证下是不是这样：
验证原理是这样：现在A实例是从库，并且已经拥有主库的完整数据，也就是
3ab75db8-6bf6-11ee-b1ce-0050569149b4:1-621664,
3cb75db8-6bf6-11ee-b1ce-0050569149b4:1-142
这些事务，如果我们现在把主从断开，然后把A实例上的事务设置成3ab75db8-6bf6-11ee-b1ce-0050569149b4:1-621664这个，然后把A实例再挂到B实例上作为从库，看下是否A实例从3ab75db8-6bf6-11ee-b1ce-0050569149b4:1-621664 这些事务之后去自动找对应的gtid事务。如果是从3ab75db8-6bf6-11ee-b1ce-0050569149b4:1-621664 这写事务之后开始寻找，那么 3cb75db8-6bf6-11ee-b1ce-0050569149b4:1-142 这些事务都会再执行一遍，这样即可验证官网所说。
由于上面已经切换过主从，现在A实例是备库，B实例是主库
1、把现在的主从再断开，在A实例上操作
stop slave;
reset slave all;
2、在A实例上重新设置事务
reset master;
set @@GLOBAL.GTID_PURGED='3ab75db8-6bf6-11ee-b1ce-0050569149b4:1-621664';
show master status;
# 这里注意，Executed_Gtid_Set 这个值没法直接设置，但是可以设置GTID_PURGED值，在Executed_Gtid_Set值为空时，Executed_Gtid_Set值就等于设置的GTID_PURGED值。
3、重新启动从库线程
change master to
master_host='192.168.167.133',
master_user='repl',
master_password='111222',
master_port=3306,
MASTER_AUTO_POSITION=1;
start slave;
show slave status \G
查看数据发现3cb75db8-6bf6-11ee-b1ce-0050569149b4:1-142 这些事务确实又执行了一遍，即验证master_auto_position 这个参数自动找的位置是Executed_Gtid_Set值的下一个事务号。