揭秘MySQL主從數據不一致

2024-07-24 12:36:18

字體：大中小

來源：轉載

供稿：網友

　　前言：

　　目前MySQL數據庫最常用的是主從架構，大多數高可用架構也是通過主從架構演變而來。但是主從架構運行時間長久后容易出現數據不一致的情況，比如因從庫可寫造成的誤操作或者復制bug等，本篇文章將會詳細探究出現主從不一致及如何解決這種問題。

　　1.造成主從不一致的原因
　　造成主從不一致的可能原因有很多，下面簡單列舉幾條：

　　主庫binlog格式為Statement，同步到從庫執行后可能造成主從不一致。
　　主庫執行更改前有執行set sql_log_bin=0，會使主庫不記錄binlog，從庫也無法變更這部分數據。
　　從節點未設置只讀，誤操作寫入數據。
　　主庫或從庫意外宕機，宕機可能會造成binlog或者relaylog文件出現損壞，導致主從不一致。
　　主從實例版本不一致，特別是高版本是主，低版本為從的情況下，主數據庫上面支持的功能，從數據庫上面可能不支持該功能。
　　MySQL自身bug導致。
　　2.主從不一致修復方法
　　下面介紹下主從不一致的修復方法，注意，這里講的是修復主從不一致而不是修復主從同步錯誤。

　　想要修復主從不一致，我們首先要發現主從不一致，下面將根據不同情形給出合適的修復方法。

　　第一種情況：比如說執行腳本時，為了更快的執行完，在腳本里增加了set sql_log_bin=0。那么這個腳本的所有數據變更將無法應用到從庫，這個時候主從數據就不一致了，解決的方法是先停掉主從復制，然后手動在從庫執行下這個腳本，最后開啟主從復制即可。

　　第二種情況：可能你的從庫并未設置只讀，同事因不太清楚架構，誤操作導致在從庫做了數據寫入，這種情況應該及時反饋并解決。解決方法：如果這些語句確實需要執行，則可以在主庫先執行set sql_log_bin=0，然后再執行語句；如果不需要執行這些語句，則需要在從庫上回滾掉先前的誤操作。

　　不過有時候情況并不是那么簡單，可能遇到比較多的情況是：主從兩個實例已經運行很久了，某日進行一致性檢驗發現主從不一致了，很難找到具體發生不一致的原因及時間。那么這個時候應該怎么辦呢，有人說，從庫重做一遍，雖然這也是一種解決方法，但是這個方案恢復時間比較慢，而且有時候從庫也是承擔一部分的查詢操作的，不能貿然重建。下面重點講下這種情況下的修復方法。

　　使用percona-toolkit工具輔助。
　　PT工具包中包含pt-table-checksum和pt-table-sync兩個工具，主要用于檢測主從是否一致以及修復數據不一致情況。這種方案優點是修復速度快，不需要停止主從輔助，缺點是需要知識積累，如果你原來不太會用這個工具，可能需要時間去學習，去測試，特別是在生產環境，還是要小心使用的。
　　關于使用方法，可以參考下面鏈接：
　　https://www.cnblogs.com/feiren/p/7777218.html
　　手動重建不一致的表。
　　比如我們在從庫發現某幾張表與主庫數據不一致，而這幾張表數據量也比較大，手工比對數據不現實，并且重做整個庫也比較慢，這個時候可以只重做這幾張表來修復主從不一致。例如：a1 b1 c1這三張表主從數據不一致，那么我們可以這么做： 1、從庫停止Slave復制
　　mysql>stop slave; 2、在主庫上dump這三張表，并記錄下同步的binlog和POS點
　　mysqldump -uroot -p123456 -q --single-transaction --master-data=2 yourdb a1 b1 c1 > ./a1_b1_c1.sql 3、查看a1_b1_c1.sql文件，找出記錄的binlog和POS點
　　more a1_b1_c1.sql
　　例如MASTER_LOG_FILE='mysql-bin.002974', MASTER_LOG_POS=55056952; 4、把a1_b1_c1.sql拷貝到Slave機器上，并做Change master to指向
　　mysql>start slave until MASTER_LOG_FILE='mysql-bin.002974', MASTER_LOG_POS=55056952;
　　注：我來解釋下，這步是什么意思。保障其他表的數據不丟失，一直同步，直到同步完那個點結束，a1,b1,c1表的數據在之前的dump已經生成了一份快照，我們只需要導入進入，然后開啟同步即可。 5、在Slave機器上導入a1_b1_c1.sql (若從庫開啟了binlog 為使導入加快，可以先執行set sql_log_bin=0)
　　mysql -uroot -p123456 yourdb < ./a1_b1_c1.sql 6、導入完畢后，從庫開啟同步即可。
　　mysql>start slave; 這樣我們就恢復了3張表，并且同步也修復了。這種方案缺點是在執行導入期間需要停止從庫復制，不過也是可以接受的。
　　可能還有其他修復方法，比如用Navicat等工具進行比對同步，不過這類工具只適用于小數據量，當有上千萬數據時，再用這種方法就不現實了。你有沒有類似經驗呢，也可以留言分享下。

　　3.如何避免主從不一致
　　通過上面的介紹，可能你也大概知道了修復并不容易，所以我們要從源頭上避免，那么我們該如何避免主從不一致的情況呢，下面給出幾個建議，希望對你有用。

　　主庫binlog采用ROW格式。
　　主從實例數據庫版本保持一致。
　　主庫做好賬號權限把控，不可以執行set sql_log_bin=0。
　　從庫開啟只讀，不允許人為寫入。
　　定期進行主從一致性檢驗。
　　總結：

　　本篇文章詳細介紹了造成主從不一致的原因，修復不一致的方法及如何避免主從不一致。特別是不一致修復方法，可能還有其他方案，這個要考慮實際情況選擇合適的方法修復。原創不易，希望大家多多支持。

（編輯：武林網）

上一篇：使用Maxscale實現mysql讀寫分離

下一篇：MySQL第三課函數以及時間相關問題