揭祕MySQL主從數據不一致

前言：

目前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兩個工具，主要用於檢測主從是否一致以及修復數據不一致狀況。這種方案優勢是修復速度快，不須要中止主從輔助，缺點是須要知識積累，若是你原來不太會用這個工具，可能須要時間去學習，去測試，特別是在生產環境，仍是要當心使用的。
  關於使用方法，能夠參考下面連接：
  http://www.javashuo.com/article/p-ncqagtxb-bc.html

• 手動重建不一致的表。

  好比咱們在從庫發現某幾張表與主庫數據不一致，而這幾張表數據量也比較大，手工比對數據不現實，而且重作整個庫也比較慢，這個時候能夠只重作這幾張表來修復主從不一致。例如：a1 b1 c1這三張表主從數據不一致，那麼咱們能夠這麼作：

  一、從庫中止Slave複製
  mysql>stop slave;

  二、在主庫上dump這三張表，並記錄下同步的binlog和POS點
  mysqldump -uroot -p123456 -q --single-transaction --master-data=2 yourdb a1 b1 c1 > ./a1_b1_c1.sql

  三、查看a1_b1_c1.sql文件，找出記錄的binlog和POS點
  more a1_b1_c1.sql
  例如MASTER_LOG_FILE='mysql-bin.002974', MASTER_LOG_POS=55056952;

  四、把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已經生成了一份快照，咱們只須要導入進入，而後開啓同步便可。

  五、在Slave機器上導入a1_b1_c1.sql (若從庫開啓了binlog 爲使導入加快，能夠先執行set sql_log_bin=0)
  mysql -uroot -p123456 yourdb < ./a1_b1_c1.sql

  六、導入完畢後，從庫開啓同步便可。
  mysql>start slave;

  這樣咱們就恢復了3張表，而且同步也修復了。這種方案缺點是在執行導入期間須要中止從庫複製，不過也是能夠接受的。

可能還有其餘修復方法，好比用Navicat等工具進行比對同步，不過這類工具只適用於小數據量，當有上千萬數據時，再用這種方法就不現實了。你有沒有相似經驗呢，也能夠留言分享下。

3.如何避免主從不一致

經過上面的介紹，可能你也大概知道了修復並不容易，因此咱們要從源頭上避免，那麼咱們該如何避免主從不一致的狀況呢，下面給出幾個建議，但願對你有用。

• 主庫binlog採用ROW格式。
• 主從實例數據庫版本保持一致。
• 主庫作好帳號權限把控，不能夠執行set sql_log_bin=0。
• 從庫開啓只讀，不容許人爲寫入。
• 按期進行主從一致性檢驗。

總結：

本篇文章詳細介紹了形成主從不一致的緣由，修復不一致的方法及如何避免主從不一致。特別是不一致修復方法，可能還有其餘方案，這個要考慮實際狀況選擇合適的方法修復。原創不易，但願你們多多支持。