一主多从
主备切换
一个切换系统完成一主多从的主备切换过程
GTID的全称是Global Transaction Identifier，也就是全局事务ID，是一个事务在提交的时候生成的，是这个事务的唯一标识。它由两部分组成，格式是：
GTID=server_uuid:gno
其中：
server_uuid是一个实例第一次启动时自动生成的，是一个全局唯一的值；
gno是一个整数，初始值是1，每次提交事务的时候分配给这个事务，并加1。
在MySQL的官方文档里，GTID格式是这么定义的：GTID=source_id:transaction_id
在MySQL里面我们说transaction_id就是指事务id，事务id是在事务执行过程中分配的，如果这个事务回滚了，事务id也会递增，而gno是在事务提交的时候才会分配。
基于GTID的主备切换
现在，我们已经理解GTID的概念，再一起来看看基于GTID的主备复制的用法。
在GTID模式下，备库B要设置为新主库A’的从库的语法如下：
CHANGE MASTER TO
MASTER_HOST=port
MASTER_USER=password
master_auto_position=1
其中，master_auto_position=1就表示这个主备关系使用的是GTID协议。可以看到，前面让我们头疼不已的MASTER_LOG_FILE和MASTER_LOG_POS参数，已经不需要指定了。
我们把现在这个时刻，实例A’的GTID集合记为set_a，实例B的GTID集合记为set_b。接下来，我们就看看现在的主备切换逻辑。
我们在实例B上执行start slave命令，取binlog的逻辑是这样的：
实例B指定主库A’，基于主备协议建立连接。
实例B把set_b发给主库A’。
实例A’算出set_a与set_b的差集，也就是所有存在于set_a，但是不存在于set_b的GITD的集合，判断A’本地是否包含了这个差集需要的所有binlog事务。
a. 如果不包含，表示A’已经把实例B需要的binlog给删掉了，直接返回错误；
b. 如果确认全部包含，A’从自己的binlog文件里面，找出第一个不在set_b的事务，发给B；
之后就从这个事务开始，往后读文件，按顺序取binlog发给B去执行。
其实，这个逻辑里面包含了一个设计思想：在基于GTID的主备关系里，系统认为只要建立主备关系，就必须保证主库发给备库的日志是完整的。因此，如果实例B需要的日志已经不存在，A’就拒绝把日志发给B。
这跟基于位点的主备协议不同。基于位点的协议，是由备库决定的，备库指定哪个位点，主库就发哪个位点，不做日志的完整性判断。
基于上面的介绍，我们再来看看引入GTID后，一主多从的切换场景下，主备切换是如何实现的。
由于不需要找位点了，所以从库B、C、D只需要分别执行change master命令指向实例A’即可。
其实，严谨地说，主备切换不是不需要找位点了，而是找位点这个工作，在实例A’内部就已经自动完成了。但由于这个工作是自动的，所以对HA系统的开发人员来说，非常友好。
