若何恢復MySQL主從數據分歧性。本站提示廣大學習愛好者：（若何恢復MySQL主從數據分歧性）文章只能為提供參考，不一定能成為您想要的結果。以下是若何恢復MySQL主從數據分歧性正文
比來原告知，MySQL主從數據庫的數據紛歧致，猜想備庫在同步進程中湧現了成績，因而，登上備庫，應用 mysql> show slave status\G檢查，果真，備庫在insert語句中因違背主鍵束縛，招致備庫停滯了同步。如今的成績很明白，就是若何恢復主從庫數據的分歧性。
可選計劃以下：
1、檢查Master最新的Position，將其作為Slave復制的終點。
這類思緒表現的是曩昔的紛歧致既往不咎，如今堅持同步便可。看起來，這個思緒和恢復主從庫數據的分歧性的初志有所違反，但這類辦法，簡略，高效，在測試情況，對汗青數據請求不高的場景中可以使用。
2、必需嚴厲的恢復主從庫數據的分歧性。
在這裡，也有兩種思緒：
1. 備份主庫數據，並在從庫上恢復，在汗青數據分歧性的基本上開啟同步，但這類辦法比擬費事，必需在主庫上履行鎖表操作，阻攔客戶端關於表數據的更新操作，並且在數據量年夜的情形下，備份也是個耗時的工程。其實，這類辦法在現實臨盆情況中也很罕用。
2. Skip失落相干毛病
其實，這個說活不是很嚴謹，預備的說，是跳過相干的事務。在我明天這類情形下，就是skip失落因違背主鍵束縛而掉敗的insert語句。
若何跳過相干事務
1、停滯slave辦事
2、SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
3、開啟slave辦事。
這裡跳過的是一個事務。固然，也能夠跳過量個事務，但要謹嚴，究竟，你其實不曉得跳過的是甚麼事務。
建議：可重復履行上述步調，細心檢查招致從庫不克不及同步的語句。有的時刻，阻攔從庫的事務太多，這類辦法就顯得略為低效。
可剖析主庫日記的事務，來肯定SQL_SLAVE_SKIP_COUNTER的適合值。詳細步調以下：
1、在備庫中履行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;
也可在主機情況下經由過程mysqlbinlog敕令檢查
# mysqlbinlog mysql-bin.000217 --start-position=673146776
若何查詢語句的履行情形
在從庫跳過相干事務，從新啟動Slave後，Slave_IO_Running，Slave_SQL_Running兩項均顯示“YES”，但Seconds_Behind_Master並沒有立時降低，反而遲緩上升。
這時候候，經由過程show processlist語句檢查線程的履行情形，發明第一條語句履行時光太長，“State”列顯示“Sending data”。關於“Sending data”的寄義，官方解釋以下：
可見，該語句觸及了年夜量的磁盤讀。
為了進一步剖析該語句的耗時散布，可設置profiling變量。步調以下：
1、在查詢開端之前，設置set profiling=on;
2、在語句履行終了後，經由過程show profiles檢查語句的Query_ID。
3、經由過程show profile for queryQuery_ID 檢查語句的詳細履行情形。
最初也發明，該語句在Sending data階段耗時太久。
總結：
1. 在履行stop slave的時刻，stop slave敕令被hang住了，在網上查詢了相干材料，能夠與Slave中有長SQL或Locked的SQL履行有關，在這裡，除show processlist外，最好不要履行show slave status和slave stop等slave相干敕令。那末若何處理該成績呢？期待鎖定SlaveSQL的線程停止，或許重啟數據庫。我選擇了後者。
2. 在重啟備庫的進程中，還有段小插曲，在履行start slave敕令的時刻，報以下毛病：ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository。網上許多材料都是推舉從新設置裝備擺設主從集群，如許又回到了開首的計劃選擇部門了。奇異的時，我封閉了從庫，從新啟動，又好了。而兩次啟動敕令獨一的差異就是前一次啟動應用的是mysqld，後一次啟動應用的是mysqld_safe，並且多帶了一個--user參數。
以上就是恢復MySQL主從數據分歧性的詳細完成辦法，願望對年夜家的進修有所贊助。
