这是学习笔记的第 1987 篇文章
GTID是一种很不错的复制解决方案，但是在使用中还是碰到一些问题，经过整理我梳理了如下的一些不规范的GTID使用场景
l 从库可写
如果在从库端写入了数据，GTID_Set就包含两个源，在使用中可能会混淆，比较规范的方式是对从库开启只读模式，如果碰到数据修复的场景，我们可以使用sql_log)bin=0来临时修复。
l Purge binlog
GTID复制错误中很常见的就属这个错误了：
the master has purged binary logs containing GTIDs that the slave requires
如果主库端对于binary log的保留时间过短，同时主从网络链路的问题，都可能导致要应用的GTID事务已经在主库被清理。
l 复制模式为MASTER_AUTO_POSITION =0
如果我们开启了GTID,还是建议使用GTID协议的数据复制方式，如果依旧使用偏移量的复制方式，在主从切换的时候很容易出问题。
同时，在一些特殊的数据修复场景中，我们使用change master to xxx,master_auto_position=0;
配置复制关系时，语句不带relay_log_file和relay_log_pos选项都会导致relay log被清理，所以一组相对完整的语句为：
change master to master_user=[Master_user],master_port=[Master_port],master_host=[Master_Host],master_port=[Master_port],master_log_file=[Relay_Master_Log_File],master_log_pos=[Exec_Master_Log_Pos],relay_log_file=[Relay_Log_File],relay_log_pos=[Relay_Log_Pos],master_auto_position=0;
Change master master_auto_position=1;
l 在线启停GTID
官方明确说GTID是可以在线启停的，但是不建议在线做这样的操作，一来是维稳，因为这种操作的频率是很低的，不排除有一些复杂的bug,二来是对于配置GTID应该是统一的规划，反复变化说明管理是混乱的，一般建议在参数文件中配置后启动数据库。
l mysqldump导出导入可能导致从库混乱
l mysqldump会默认开启set-gtid-purged 选项，在导出的dump文件中会包含set @@gtid_purge=xxx的语句，如果在跨服务器环境中导入数据，可能导致操作失误而直接对主库做了reset master操作。
