前言

在復制中，有時會因為復制報錯，而中斷復制。通常是因為一個SQL語句在主庫執行時是正常的，但同步到從庫時，因為各種原因，找不到對應的數據，造成執行SQL失敗，報出復制錯誤。下面主要寫了幾個常見的錯誤。

復制中斷的情況和處理

復制中斷的情況：

• 1062錯誤：在寫入數據使，從庫已存在了。多出現自增長ID已存在。
• 1032錯誤：從庫出現少數據，update、delete時，找不到相應的記錄。
• 其他：DDL操作時報錯

對這些情況的處理：

• 遇到該問題，要想到要怎樣滿足復制，而不是跳過該事務;不建議跳過錯誤，遇到錯誤應該修正過來，再連接主庫復制，否則從庫的數據會越來越不一致!
• 手工修復操作有些慢，可以針對1062和1032錯誤，寫一個自動化監控改正腳本。
• 注意：若經常數據不一致，選擇業務低峰期，檢驗一次數據(pt-table-checksum)，查看是否數據一致，若檢查出太多的數據不一致，該從庫就不可再用了，再創建一個從庫!

常見的復制錯誤

【錯誤碼-1062】 

處理操作：

• 處理這種情況，需要和業務協商，或在公司內形成一個規定，遇到這種情況要怎樣做(在從庫將這條重復數據刪除還是補充到主庫)。
• 通常，在從庫刪除該條數據，讓復制繼續進行。
• 使用pt-slave-restart來修復問題，它會會跳過錯誤，建議先處理錯誤，才可以保證數據的一致性

具體操作：

• 定位到該事物
  • 傳統復制：Exec_Master_Log_Pos 與 last_error中的end_log_pos 中間的事務
  • GTID復制：executed_gtid_set : xxxxx:1-5 ，即第6個事務報錯了。
  • master：mysqlbinlog -vv --base64-output=decode-rows --start-position ……
• 在slave上刪除該條數據，然后連接復制
  • > set sql_log_bin=0; # 先禁止當前會話的操作記錄寫到binlog
  • > delete from xn_db.t_order_produce where id=35197;
  • > set sql_log_bin=1; # 恢復正常
  • > start slave sql_thread; # 啟動SQL線程

【錯誤碼-1032】

1032錯誤 分為： update錯誤 和 delete錯誤。

update 處理操作：

• 在主庫上獲取出來主鍵的值(不需要具體恢復出來)，只要滿足SQL執行成功即可。

update 具體操作：

• 定位到該事物
  • 傳統復制：Exec_Master_Log_Pos 與 last_error中的end_log_pos 中間的事務
  • GTID復制：executed_gtid_set : xxxxx:1-5 ，即第6個事務報錯了。
  • master：mysqlbinlog -vv --base64-output=decode-rows --start-position ……
• 將沒有的數據創建出來，只符合錯誤事務執行成功即可
  • > set sql_log_bin=0;
  • > insert into xn_db.t_mes(id) values(35592);
  • > set sql_log_bin=1;
  • > start slave sql_thread;

delete 處理操作：

• 由于從庫沒有該數據，致使刪除失敗，可以跳過該錯誤，因為跳過該刪除事務相當于不執行該delete語句，和在從庫上沒執行之前是一樣的，那些數據都不會存在于從庫中。

delete 具體操作：

• 傳統復制：
  • > stop slave;
  • > set global sql_slave_skip_counter=1; # 跳過一個事務
  • > start slave;
• GTID復制：
  • > stop slave;
  • > set gtid_net='xxxxx:6' # 跳過報錯事務6
  • > begin;commit; # 執行一個空事務，即GTID為6的事務
  • > set gtid_next='AUTOMATIC';
  • > start salve;