GTID复制异常的解决方法，主从复制使用的是GTID方式。
下面这个环境，出问题的原因不提了。
下面是从库的截图：
Retrieved_Gtid_Set:167b4197-09fa-11e7-993f-000c296a2c0d:1-6
Executed_Gtid_Set:167b4197-09fa-11e7-993f-000c296a2c0d:1-5,
261aafbc-0ace-11e7-9ea6-000c298f384b:1-305
第一行表示收到的事务，第二行表示已经执行完的事务。也就是说执行到Retrieved_Gtid_Set时候发生错误了。因此，我们直接单单跳过这个事务即可。
在从库执行修复：
step1、修补数据
（我当时这个情况是当时在主库关闭binlog然后执行了一个alter操作，但是忘记在从库执行这个alter操作，导致复制异常的。复制异常后，我在从库补了这个alter操作，但是实际上数据是否一致需要自己对比主和从在alter操作后那段时间内的binlog记录）
step2、重新配置主从
SET gtid_next='167b4197-09fa-11e7-993f-000c296a2c0d:6'; # 跳过Retrieved_Gtid_Set这个最后的事务就行了
BEGIN;
COMMIT;
SETgtid_next='automatic';
startslave;
showslave status\G
原文地址：http://www.linuxidc.com/Linux/2017-04/142691.htm
另一种方法：
前言：
gtid 复制模式下，不要使用 replicate_wild_do_table 此参数，使用此类参数，会复制异常（即状态信息正常，但从机没有复制过来）
下面进入正题：
在我们遇到复制错误时，如果复制没有特别的错误时，我们一般采用 set global sql_slave_skip_counter＝1 来跳过错误，但是，在mysql 5.6 的gtid模式下，此方法是没有作用的。我们采取如下方式：
1.查看从机的复制状态信息：（主要是以下几个值）
Retrieved_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:150-151
Executed_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-149
Retrieved_Gtid_Set项：记录了relay日志从Master获取了binlog日志的位置
Executed_Gtid_Set项：记录本机执行的binlog日志位置（如果是从机，包括Master的binlog日志位置和slave本身的binlog日志位置）
2.在从机上执行如下操作，以下所有操作，如果没有特别说明，均在从机上执行
STOP SLAVE;
reset master;
reset slave ALL;
set global gtid_purged="D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-150";
SET GLOBAL log_bin_trust_function_creators = 1;
change master to master_host='***',
master_port=***,
master_user='***',
master_password='***',
master_auto_position=1;
#BEGIN; COMMIT;
#SET SESSION GTID_NEXT = AUTOMATIC;
START SLAVE;
show slave status;
此时再查看复制状态信息，重复以上操作 set global gtid_purged='D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-150'; 此值依次往后推，直到复制正常为止