Mysql8.0.22主备GTID Replication中的那些坑

导读

作者：杨漆
16年关系型数据库管理，从oracle 9i 、10g、11g、12c到Mysql5.5、5.6、5.7、8.0 到TiDB获得3个OCP、2个OCM；运维路上不平坦，跌过不少坑、熬过许多夜。把工作笔记整理出来分享给大伙儿，希望帮到大家少走弯路、少熬夜。

Mysql 中的GTID是什么 ？
答：全局事务ID，为每一个在Master上提交的事务在集群内Replication时只生成一个唯一的ID，为规避冗余和错误提供了有力保障。
一条GITD信息由两部分组成，即source_id + transaction_id，GTID=source_id:transaction_id，其中source_id是执行事务的主库server-uuid值，在mysql首次启动时生成，保存在DB的数据目录中auto.conf文件里，存放server-uuid的值（唯一性）。transaction_id是从1开始自增的序列，记录在主库上执行的第几个事务，Mysql会保证这个事务和GTID是唯一的（一比一的关系）。

为何要使用GTID Replication ？
答：GTID Replication是从Mysql5.6开始支持的一种新的复制方式，与传统基于日志的方式存在着很大的差异。旧有基于日志的复制中，Slave端连接到Master端并告诉Master 从哪个二进制日志的偏移量开始执行增量同步，此刻若指定的日志偏移量不对，就会造成Master–>Slave数据的不一致，而基于GTID的复制不会出现此类错误。
GTID Replication中Slave会将执行完的事务的GTID值告知Master，之后Master把所有没在Slave端执行过的事务发送到Slave端并执行。GTID Replication可以保证同一个事务在指定的Slave端只执行一次，规避了由于偏移量的问题造成的数据不一致风险。
GTID Replication优点:
1、故障转移更为方便（因GTID是全局唯一的标识符，能更简单的知道哪些事务在Slave端没有执行，在多Slave场景下使用master_auto_position=1省去了多个日志偏移量配置的麻烦）
2、Slave和Master的d