封尘网

让学习成为一种习惯!

Mysql5.7版本Gtid复制出现不同步的情况

Mysql5.7版本,Gtid复制出现不同步的情况;

问题:由于shell检测Mysql从库状态 :
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

一直都为YES状态,所以没有收到警报;直接开发反馈说客户上传数据后有些能查到,有些查不到的时候,在从库上检查是发现了异常;

主库和从库的数据不一致;瞬间惊呆了,按照我们惯性思维,状态一直处于正常,按理说应该没什么问题的,但是为什么会出现这种情况呢?

过程说明:
系统:Centos6.5_x86_64
Mysql版本:5.7.9
innobackupex:2.4.4

此从库是使用innobackupex直接热备过来,再从库上恢复数据,再启用gtid复制实现的;也正常运行了几个月了;所幸的是此从库影响不大,于是停止从库;

重新热备一份数据,再导入从库;【过程跟之前一样操作】,可是结果却是实现的;两个状态一样是YES,而下边的Retrieved_Gtid_SetExecuted_Gtid_Set

一直在刷新,但是无同实现致,就是说中间有间隔;很显示就是gtid事务ID值有些未能正确同步过来;很奇怪为什么会这样呢?日志没有太多的异常信息,状态也

正常,就是数据不同步过来了;我再把配置文件:my.cnf修改成一样的,除了server_id再次上面操作,结果还是一样;

后来听开发说到,最近有改过事务的级别,但是这个事务级别应该不会影响啊。 于是顺着这个在google、百度上找啊找,终于找到了一个让我觉得问题可能出现的原因:

叶金荣老师的文章:http://imysql.com/tag/mysql%E5%A4%8D%E5%88%B6 我才想起来,之前一个月左右在线变更过binlog日志的格式从MIXED 修改成ROW了;再加上不久前被修改过的事务级别;可能就是造成的原因。

于是把主库上的binlog日志修改成:MIXED,【此处需要注意,最好先备份一下;】因为主库的从库只有一个,而binlog日志影响不大,我就直接把binlog日志重置了一下:reset master; 接下来再利用innobackupex备份数据到从库上,导入;启动slave,很快数据就同步过来了。

总结:

  • 造成问题的原因,在线修改binlog日志会造成原来的日志格式和后来的日志格式不一样,但是都可以被Mysql识别;
  • 如果只改日志格式,不修改事务级别应该不会受影响,当然还没有测试过Statement格式;
  • 主从库版本最好一致,至少大版本要一致;
  • 配置文件的配置也最好是一样的,有些因为机器配置不一样另算。
  • 在线变更数据配置,不应直接修改,毕竟影响的后果可能是很严重的。但是我理解为,只要是主从配置一齐修改可能会现出现异常的机率很少。

提醒:本文最后更新于 891 天前,文中所描述的信息可能已发生改变,请谨慎使用。