GTID介绍
从MySQL 5.6.5开始支持GTID，每一个在主库上提交的事务在复制集群中可以生成一个唯一的ID。
一个GTID在一个服务器上只执行一次，避免重复执行导致主从不一致或者数据混乱。
在传统复制的slave，binlog日志可以不开启，但是在GTID中，slave的binlog必须开启，目的是记录执行过的GTID。
GTID的组成
GTID = server_uuid:transaction_id
server_uuid：在数据目录下的 auto.cnf 文件是用来保存 server_uuid的。MySQL启动时，会读取 auto.cnf 文件，如果 auto.cnf 文件丢失，则生成一个新的 server_uuid，那么这样GTID的值也会改变。
transaction_id表示该实例上已经提交的事务数量，并且随着事务提交单调递增。例如，要提交的第一个事务的 transaction_id 是1，第十个 transaction_id 是 10，在GTID中，transaction_id不可能是0。
GTID的好处
1.更简单的实现failover ，主从环境主库的dump进程可以直接通过GTID定位到需要发送的binary log位置，而不再需要指定binary log的 LOG_FILE和LOG_POS，只需指定主库的ip、port、username、password 就可以了，因为GTID的复制是自动的，所以会自动找到GTID去同步。根据GTID可以知道事务最初是在哪个实例上提交的。
2.基于库的多线程复制，多线程是针对每个database开启相应的独立线程，即每个库有一个单独的sql thread，如果线上业务中，只有一个database或者绝大多数压力集中在个别database的话，多线程并发复制特性就没有意义了（slave-parallel-workers=0 表示禁用多线程功能）。
GTID的限制
1.不支持非事务引擎（从库报错，stop slave;start slave;忽略）。
2.不支持create table xxx select 语句复制（在最新版本8.0.21已经解决了）。
3.不允许一个SQL同时更新一个事务引擎和非事务引擎的表。
4.在一个复制组中，必须要求统一开启GTID或者是关闭GTID。
5.开启GTID需要重启（MySQL5.7.6版本开始可以在线升级gtid模式）。
6.开启GTID后，就不再使用原来的传统的复制方式。
7.对于create temporary table和drop temporary语句不支持。
8.不支持sql_slave_skip_counter。
开启GTID
gtid_mode = on
log-bin = mysql-bin #5.6必选 5.7.5和之后可选，为了高可用，最好设置
log-slave-updates = 1 #5.6必选 5.7.5和之后可选，为了高可用，最好设置
enforce-gtid-consistency = 1
判断复制方式GTID 还是传统复制pos
Show slave status 查看Auto_Position字段。
0是传统复制pos方式。
1是gtid方式。
gtid_pureged
gtid_pureged 命令的实际意义：因为没有binlog信息（expire_logs_days），不考虑这些gtid确认和回滚。常用备份恢复，搭建从库的时候使用。
自动触发机制：flush，服务器重新启动
如果purged掉的GTIDs会包含到gtid_executed中。
mysqldump --set-gtid-purged=off/on 参数：是否将GTID_PURGED 添加到输出中。
gtid_pureged使用场景：
1.在副本上禁用二进制日志记录提交的复制事务的GTIDs。
2.写入二进制日志文件的事务的GTIDs，该文件现在已被清除。
3.通过语句set @@GLOBAL.gtid_purged显式添加到集合中的gtid。