揭秘MySQL主從數(shù)據(jù)不一致

前言：

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

1.造成主從不一致的原因

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

• 主庫binlog格式為Statement，同步到從庫執(zhí)行后可能造成主從不一致。
• 主庫執(zhí)行更改前有執(zhí)行set sql_log_bin=0，會使主庫不記錄binlog，從庫也無法變更這部分?jǐn)?shù)據(jù)。
• 從節(jié)點未設(shè)置只讀，誤操作寫入數(shù)據(jù)。
• 主庫或從庫意外宕機，宕機可能會造成binlog或者relaylog文件出現(xiàn)損壞，導(dǎo)致主從不一致。
• 主從實例版本不一致，特別是高版本是主，低版本為從的情況下，主數(shù)據(jù)庫上面支持的功能，從數(shù)據(jù)庫上面可能不支持該功能。
• MySQL自身bug導(dǎo)致。

2.主從不一致修復(fù)方法

下面介紹下主從不一致的修復(fù)方法，注意，這里講的是修復(fù)主從不一致而不是修復(fù)主從同步錯誤。

想要修復(fù)主從不一致，我們首先要發(fā)現(xiàn)主從不一致，下面將根據(jù)不同情形給出合適的修復(fù)方法。

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

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

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

• 使用percona-toolkit工具輔助。

  PT工具包中包含pt-table-checksum和pt-table-sync兩個工具，主要用于檢測主從是否一致以及修復(fù)數(shù)據(jù)不一致情況。這種方案優(yōu)點是修復(fù)速度快，不需要停止主從輔助，缺點是需要知識積累，如果你原來不太會用這個工具，可能需要時間去學(xué)習(xí)，去測試，特別是在生產(chǎn)環(huán)境，還是要小心使用的。
  關(guān)于使用方法，可以參考下面鏈接：
  https://www.cnblogs.com/feiren/p/7777218.html

• 手動重建不一致的表。

  比如我們在從庫發(fā)現(xiàn)某幾張表與主庫數(shù)據(jù)不一致，而這幾張表數(shù)據(jù)量也比較大，手工比對數(shù)據(jù)不現(xiàn)實，并且重做整個庫也比較慢，這個時候可以只重做這幾張表來修復(fù)主從不一致。例如：a1 b1 c1這三張表主從數(shù)據(jù)不一致，那么我們可以這么做：

  1、從庫停止Slave復(fù)制
  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;
  注：我來解釋下，這步是什么意思。保障其他表的數(shù)據(jù)不丟失，一直同步，直到同步完那個點結(jié)束，a1,b1,c1表的數(shù)據(jù)在之前的dump已經(jīng)生成了一份快照，我們只需要導(dǎo)入進(jìn)入，然后開啟同步即可。

  5、在Slave機器上導(dǎo)入a1_b1_c1.sql (若從庫開啟了binlog 為使導(dǎo)入加快，可以先執(zhí)行set sql_log_bin=0)
  mysql -uroot -p123456 yourdb < ./a1_b1_c1.sql

  6、導(dǎo)入完畢后，從庫開啟同步即可。
  mysql>start slave;

  這樣我們就恢復(fù)了3張表，并且同步也修復(fù)了。這種方案缺點是在執(zhí)行導(dǎo)入期間需要停止從庫復(fù)制，不過也是可以接受的。

可能還有其他修復(fù)方法，比如用Navicat等工具進(jìn)行比對同步，不過這類工具只適用于小數(shù)據(jù)量，當(dāng)有上千萬數(shù)據(jù)時，再用這種方法就不現(xiàn)實了。你有沒有類似經(jīng)驗?zāi)?，也可以留言分享下?/p>

3.如何避免主從不一致

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

• 主庫binlog采用ROW格式。
• 主從實例數(shù)據(jù)庫版本保持一致。
• 主庫做好賬號權(quán)限把控，不可以執(zhí)行set sql_log_bin=0。
• 從庫開啟只讀，不允許人為寫入。
• 定期進(jìn)行主從一致性檢驗。

總結(jié)：

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