如何恢復MySQL主從數據一致性

更新時間：2016年04月20日 14:57:52 作者：iVictor

MySQL主從數據一致性怎么恢復，MySQL主從數據庫的數據不一致，猜測備庫在同步過程中出現了問題，現在的問題很明確，就是如何恢復主從庫數據的一致性，下文為大家分享解決方法，感興趣的小伙伴們可以參考一下

最近被告知，MySQL主從數據庫的數據不一致，猜測備庫在同步過程中出現了問題，于是，登上備庫，使用 mysql> show slave status\G查看，果然，備庫在insert語句中因違反主鍵約束，導致備庫停止了同步?，F在的問題很明確，就是如何恢復主從庫數據的一致性。

可選方案如下：

一、查看Master最新的Position，將其作為Slave復制的起點。

這種思路體現的是過去的不一致既往不咎，現在保持同步即可?？雌饋?，這個思路和恢復主從庫數據的一致性的初衷有所違背，但這種方法，簡單，高效，在測試環(huán)境，對歷史數據要求不高的場景中可使用。

二、必須嚴格的恢復主從庫數據的一致性。

在這里，也有兩種思路：

1. 備份主庫數據，并在從庫上恢復，在歷史數據一致性的基礎上開啟同步，但這種方法比較麻煩，必須在主庫上執(zhí)行鎖表操作，阻止客戶端對于表數據的更新操作，而且在數據量大的情況下，備份也是個耗時的工程。其實，這種方法在實際生產環(huán)境中也很少用。

2. Skip掉相關錯誤

其實，這個說活不是很嚴謹，準備的說，是跳過相關的事務。在我今天這種情況下，就是skip掉因違反主鍵約束而失敗的insert語句。

如何跳過相關事務

一、停止slave服務

二、SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

三、開啟slave服務。

這里跳過的是一個事務。當然，也可以跳過多個事務，但要謹慎，畢竟，你并不知道跳過的是什么事務。

建議：可反復執(zhí)行上述步驟，仔細查看導致從庫不能同步的語句。有的時候，阻止從庫的事務太多，這種方法就顯得略為低效。

可分析主庫日志的事務，來確定SQL_SLAVE_SKIP_COUNTER的合適值。具體步驟如下：

1、在備庫中執(zhí)行show slave status\G，確認以下兩個參數

根據上述兩個參數的值，在主庫中查看當前阻礙從庫復制的事務以及之后的事務。

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000217' from 673146776;

這個是查看日志文件mysql-bin.000217中事務ID為673146776后的所有事務。

當然，SHOW BINLOG EVENTS的用法還是相當靈活的，下述方式均可。

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000217' from 673146776\G

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000217' from 673146776 limit 10;

也可在主機環(huán)境下通過mysqlbinlog命令查看

復制代碼代碼如下:

# mysqlbinlog mysql-bin.000217 --start-position=673146776

如何查詢語句的執(zhí)行情況

在從庫跳過相關事務，重新啟動Slave后，Slave_IO_Running，Slave_SQL_Running兩項均顯示“YES”，但Seconds_Behind_Master并沒有馬上下降，反而緩慢上升。

這時候，通過show processlist語句查看線程的執(zhí)行情況，發(fā)現第一條語句執(zhí)行時間太長，“State”列顯示“Sending data”。關于“Sending data”的含義，官方說明如下：

可見，該語句涉及了大量的磁盤讀。

為了進一步分析該語句的耗時分布，可設置profiling變量。步驟如下：

一、在查詢開始之前，設置set profiling=on;

二、在語句執(zhí)行完畢后，通過show profiles查看語句的Query_ID。

三、通過show profile for queryQuery_ID 查看語句的具體執(zhí)行情況。

最后也發(fā)現，該語句在Sending data階段耗時過久。

總結：

1. 在執(zhí)行stop slave的時候，stop slave命令被hang住了，在網上查詢了相關資料，可能與Slave中有長SQL或Locked的SQL執(zhí)行有關，在這里，除show processlist外，最好不要執(zhí)行show slave status以及slave stop等slave相關命令。那么如何解決該問題呢？等待鎖定SlaveSQL的線程結束，或者重啟數據庫。我選擇了后者。

2. 在重啟備庫的過程中，還有段小插曲，在執(zhí)行start slave命令的時候，報如下錯誤：ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository。網上很多資料都是推薦重新配置主從集群，這樣又回到了開頭的方案選擇部分了。奇怪的時，我關閉了從庫，重新啟動，又好了。而兩次啟動命令唯一的差別就是前一次啟動使用的是mysqld，后一次啟動使用的是mysqld_safe，而且多帶了一個--user參數。

以上就是恢復MySQL主從數據一致性的具體實現方法，希望對大家的學習有所幫助。

您可能感興趣的文章: