Mysql主从复制GTID是什么？

什么是GTID？

1. 全局唯一，一个事务对应一个GTID
2. 替代传统的binlog+pos复制；使用master_auto_position=1自动匹配GTID断点进行复制
3. MySQL5.6开始支持，在传统的主从复制中，slave端不用开启binlog；但是在GTID主从复制中，必须开启binlog
4. slave端在接受master的binlog时，会校验GTID值
5. 为了保证主从数据的一致性，多线程同时执行一个GTID

组成

Master_UUID:序列号举例：ceb0ca3d-8366-11e8-ad2b-000c298b7c9a:1-5ceb0ca3d-8366-11e8-ad2b-000c298b7c9a其实就是master的uuid值；1-5是序列号，每次一个事务完成都会自增1，也就是说下一次为1-6。

工作原理

• master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
• slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
• sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
• 如果有记录，说明该GTID的事务已经执行，slave会忽略。
• 如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
• 在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描

优缺点

基于日志点复制的缺点：

• 故障转移时重新获取master的日志点信息比较困难。基于日志点复制是从master的binlog的偏移量进行增量同步。如果指定错误会造成遗漏或者重复，造成主从不一致

基于GTID复制的优点是：

• 可以很方便的进行故障转移，记录master最后事务的GTID值。比如master：A，slave：B,C。当A挂了后，B执行了所有A传过来的事务。当C连接到B后，在自己的binlog找到最后一次A传过来的GTID。然后C将这个GTID发送给B，B获取到这个GTID，就开始从这个GTID的下一个GTID开始发送事务给C。这种自我寻找复制位置的模式减少事务丢失的可能性以及故障恢复的时间。
• slave不会丢失master的任何修改(开启了log_slave_updates)