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格式；

主從庫版本最好一致，至少大版本要一致；

配置文件的配置也最好是一樣的，有些因為機器配置不一樣另算。

在線變更數據配置，不應直接修改，畢竟影響的后果可能是很嚴重的。但是我理解為，只要是主從配置一齊修改可能會現出現異常的機率很少。

總結

以上是生活随笔為你收集整理的mysql gitd 数据结构同步失败_Mysql5.7版本Gtid复制出现不同步的情况的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。