一、GTID简介
MySQL 5.6 的新特性之一，是加入了全局事务 ID (GTID) 来强化数据库的主备一致性，故障恢复，以及容错能力。它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
在传统的slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。GTID用来代替classic的复制方法，不在使用binlog+pos开启复制。而是使用master_auto_postion=1的方式自动匹配GTID断点进行复制。
mysql的主从复制是十分经典的一个应用，但是主从之间总会有数据一致性（data consistency ）的问题，一般情况从库会落后主库几个小时，而且在传统一主多从(mysql5.6之前)的模型中当master down掉后，我们不只是需要将一个slave提成master就可以，还要将其他slave的同步目的地从以前的master改成现在master，而且bin-log的序号和偏移量也要去查看，这是十分不方便和耗时的，但mysql5.6引入gtid之后解决了这个问题。
二、GTID参数配置
1、主master：
[mysqld]
#GTID:
server_id=1 #服务器id
gtid_mode=on #开启gtid模式
enforce_gtid_consistency=on #强制gtid一致性，开启后对于特定create table不被支持
#binlog
log_bin=master-binlog
log-slave-updates=1
binlog_format=row #强烈建议，其他格式可能造成数据不一致
#relay log
skip_slave_start=1
2、从slave：
[mysqld]
#GTID:
gtid_mode=on
enforce_gtid_consistency=on
server_id=2
#binlog
log-bin=slave-binlog
log-slave-updates=1
binlog_format=row #强烈建议，其他格式可能造成数据不一致
#relay log
skip_slave_start=1
综上所述：配置没有太大区别，仅仅只是server_id不一致。
三、配置主从
master:
创建并授权salve远程访问的用户：GRANT REPLICATION SLAVE ON *.* TO [email protected] IDENTIFIED BY ‘123456‘;
flush privileges;
查看授权slave用户表：show grants for [email protected];
查看binlog信息：show master status;
slave;（这里的bin与pos根据实际情况更换）
CHANGE MASTER TO MASTER_HOST=‘192.168.50.116‘, MASTER_USER=‘root‘, MASTER_PASSWORD=‘123456‘, master_log_file=‘mysql-bin.000009‘, master_log_pos=194, MASTER_AUTO_POSITION=0;
start slave;
show slave status\G;
报错示例：
2017-10-12T09:59:27.660287Z 4 [ERROR] Slave I/O for channel ‘‘: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work. Error_code: 1593
解决方法：
如果是copy的data目录可能会出现这个错，将data目录里auto.cnf 文件中的uuid改为与master不一样的即可。
2017-10-12T10:09:15.365312Z 4 [ERROR] Slave I/O for channel ‘‘: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file‘, Error_code: 1236
解决办法：
是因为找不到master的二进制文件，查看master的binlog二进制文件、pos位置是否与slave相同，不相同关闭salve并在slave执行CHANGE MASTER TO MASTER_LOG_FILE=‘mysqld-bin.000011‘,MASTER_LOG_POS=106;更改，然后开启start slave;并进行查看show slave status\G
主从不同步，但slave显示双yes，日志无报错问题。
这个解决方法是下下策，我不知道不同步的原因是什么，如果有知道的T友，请评论告知。
重置主从：reset master；reset slave #清除binlog日志信息
备份主的全库到slave：
mysqldump -h 192.168.50.116 -uroot -p123456 --all-databases --skip-lock-tables --set-gtid-purged=off > qk.sql
然后导入：mysql -uroot -p123456 <aaa.sql
导入时若提示：ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.则在本地执行reset master即可。
导入成功后重新开启slave同步，
如若slave需要重新挂载在master端，则执行命令change时忽略MASTER_AUTO_POSITION即可。
注意：
开启GTID主从复制之后，就不可以在从的上面进行操作，否则会出现slave_sql_running为NO的提示。
当已经在从库进行删除或则添加数据时，挽救的方法就是关闭slave，然后将删除的数据创建回来或将添加的数据删除，目的是为了与master一致，然后开启slave。
优秀文章分享：
http://www.cnblogs.com/luckcs/articles/6295992.html
http://blog.csdn.net/leshami/article/details/50630691