解决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;

看看是否正常了。

此条目发表在服务器分类目录,贴了标签。将固定链接加入收藏夹。

发表回复