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_Set 和Executed_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格式；
• 主从库版本最好一致，至少大版本要一致；
• 配置文件的配置也最好是一样的，有些因为机器配置不一样另算。
• 在线变更数据配置，不应直接修改，毕竟影响的后果可能是很严重的。但是我理解为，只要是主从配置一齐修改可能会现出现异常的机率很少。