Mysql5.7版本，Gtid復制出現(xiàn)不同步的情況；

問題：由于shell檢測Mysql從庫狀態(tài) ：

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

一直都為YES狀態(tài)，所以沒有收到警報；直接開發(fā)反饋說客戶上傳數(shù)據后有些能查到，有些查不到的時候，在從庫上檢查是發(fā)現(xiàn)了異常；

主庫和從庫的數(shù)據不一致；瞬間驚呆了，按照我們慣性思維，狀態(tài)一直處于正常，按理說應該沒什么問題的，但是為什么會出現(xiàn)這種情況呢？

過程說明：

系統(tǒng)：Centos6.5_x86_64

Mysql版本：5.7.9

innobackupex：2.4.4

此從庫是使用innobackupex直接熱備過來，再從庫上恢復數(shù)據，再啟用gtid復制實現(xiàn)的；也正常運行了幾個月了；所幸的是此從庫影響不大，于是停止從庫；

重新熱備一份數(shù)據，再導入從庫；【過程跟之前一樣操作】，可是結果卻是實現(xiàn)的；兩個狀態(tài)一樣是YES，而下邊的Retrieved_Gtid_Set 和Executed_Gtid_Set。

一直在刷新，但是無同實現(xiàn)致，就是說中間有間隔；很顯示就是gtid事務ID值有些未能正確同步過來；很奇怪為什么會這樣呢？日志沒有太多的異常信息，狀態(tài)也

正常，就是數(shù)據不同步過來了；我再把配置文件：my.cnf修改成一樣的，除了server_id再次上面操作，結果還是一樣；

后來聽開發(fā)說到，最近有改過事務的級別，但是這個事務級別應該不會影響啊。 于是順著這個在google、百度上找啊找，終于找到了一個讓我覺得問題可能出現(xiàn)的原因：

葉金榮老師的文章：http://imysql.com/tag/mysql%E5%A4%8D%E5%88%B6 我才想起來，之前一個月左右在線變更過binlog日志的格式從MIXED 修改成ROW了；再加上不久前被修改過的事務級別；可能就是造成的原因。

于是把主庫上的binlog日志修改成：MIXED，【此處需要注意，最好先備份一下；】因為主庫的從庫只有一個，而binlog日志影響不大，我就直接把binlog日志重置了一下：reset master; 接下來再利用innobackupex備份數(shù)據到從庫上，導入；啟動slave，很快數(shù)據就同步過來了。

總結：

造成問題的原因，在線修改binlog日志會造成原來的日志格式和后來的日志格式不一樣，但是都可以被Mysql識別；

如果只改日志格式，不修改事務級別應該不會受影響，當然還沒有測試過Statement格式；

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

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

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

總結

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

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