今天在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;
看看是否正常了。
