日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

前言：

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

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

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

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

2.主從不一致修復方法

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

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

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

第二種情況：可能你的從庫并未設置只讀，同事因不太清楚架構，誤操作導致在從庫做了數據寫入，這種情況應該及時反饋并解決。解決方法：如果這些語句確實需要執行，則可以在主庫先執行set sqllogbin=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 > ./a1b1c1.sql

3、查看a1b1c1.sql文件，找出記錄的binlog和POS點

more a1b1c1.sql

例如MASTERLOGFILE='mysql-bin.002974', MASTERLOGPOS=55056952;

4、把a1b1c1.sql拷貝到Slave機器上，并做Change master to指向

mysql>start slave until MASTERLOGFILE='mysql-bin.002974', MASTERLOGPOS=55056952;

注：我來解釋下，這步是什么意思。保障其他表的數據不丟失，一直同步，直到同步完那個點結束，a1,b1,c1表的數據在之前的dump已經生成了一份快照，我們只需要導入進入，然后開啟同步即可。

5、在Slave機器上導入a1b1c1.sql (若從庫開啟了binlog 為使導入加快，可以先執行set sqllogbin=0)

mysql -uroot -p123456 yourdb < ./a1b1c1.sql

6、導入完畢后，從庫開啟同步即可。

mysql>start slave;

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

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

3.如何避免主從不一致

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

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

總結：

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