揭秘MySQL主從數據不一致-創新互聯

前言：

成都創新互聯是一家專業提供西雙版納企業網站建設,專注與成都網站設計、成都網站建設、HTML5建站、小程序制作等業務。10年已為西雙版納眾多企業、政府機構等服務。創新互聯專業網站設計公司優惠進行中。

目前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。
• 從庫開啟只讀，不允許人為寫入。
• 定期進行主從一致性檢驗。

總結：

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

另外有需要云服務器可以了解下創新互聯cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前名稱：揭秘MySQL主從數據不一致-創新互聯
分享網址：http://m.kartarina.com/article8/ccghip.html

成都網站建設公司_創新互聯，為您提供電子商務、手機網站建設、網站設計公司、網站導航、建站公司、網站設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯