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

今天在

执行：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;

看看是否正常了。