解决mysql5.6 GTID同步出现The incident LOST_EVENTS occured on the master.

今天在mysql5.6生产环境上做测试，结果应该是执行了grant语句给一账户复制库的权限导致所有从库同步出现一样的错误。 执行：mysql> show slave status\G; 显示同步已经断开，报The incident LOST_EVENTS occured on the master. Message: error writing to the binary log错误！！！！ 网上搜索结果竟然是5.6才有的bug，5.5不会有这样的问题，这是什么鬼。 使用二进制日志同步可以使用以下方法解决： 1)使用sql_slave_skip_counter跳过事件，但此方法只适用于基于二进制日志原理的复制，不适用于基于GTID原理的复制。 2)使用slave_skip_errors跳过错误。 3)在从库上做change master操作，重新切换master_log_file和master_log_pos。（由于无效的grant语句执行后会创建新的二进制日志，所以可以指定主库show master status的master_log_file和master_log_pos） GTID方式同步 网上大部分说重做，如果你确认真的丢失了日志文件而无法恢复那只能重做。如果仅仅是这种需要跳过grant导致的问题，或者你基本可以忽略的同步丢失一点点数据，那就不需要重做了，只要重新设置下同步的位置即可。 首先查询以下两个参数。 Retrieved_Gtid_Set项：记录了relay日志从Master获取了binlog日志的位置 Executed_Gtid_Set项：记录本机执行的binlog日志位置（如果是从机，包括Master的binlog日志位置和slave本身的binlog日志位置） 查到Executed_Gtid_Set：6f723299-523b-11e5-a5bf-00163e0007c9:1-88703056' 错误的地方，这时候需要跳过它。gtid_purged官方文档可以知道该变量中记录的是本机上已经执行过，但是已经被purge binary logs to命令清理的gtid_set。执行的时候需要加1变成88703057 然后在mysql命令行下执行以下语句： stop slave; reset master; reset slave all; set global gtid_purged = '6f723299-523b-11e5-a5bf-00163e0007c9:1-88703057'; change master to master_host = 'x.x.x.x',master_port = 3306,master_user = 'user',master_password='pwd',master_auto_position = 1; start slave; 如果在重新同步的过程中还出现错误的话，可以使用 gtid_next来跳过错误，参数从Retrieved_Gtid_Set上获取，如88703058-88716569只要取后面的即可，不然可能出现can't无法设置的提示。 stop slave; set gtid_next="6f723299-523b-11e5-a5bf-00163e0007c9:88716569"; begin;commit; set gtid_next="AUTOMATIC"; start slave; show slave status\G; 看看是否正常了。