[MySQL複製] SQL_ERROR 1032解決辦法（non-gtid env）

1、原因：

　　在主主同步的測試環境，因爲業務側沒有遵循同一時間只寫一個點的原則，形成A庫上刪除了一條數據，B庫上在同時更新這條數據。

因爲異步和網絡延時，B的更新event先到達A端執行，形成A端找不到這條記錄，故SQL_THREAD報錯1032，主從同步中止。

 

2、錯誤說明：

　　MySQL主從同步的1032錯誤，通常是指要更改的數據不存在，SQL_THREAD提取的日誌沒法應用故報錯，形成同步失敗

（Update、Delete、Insert一條已經delete的數據）。

　　1032的錯誤自己對數據一致性沒什麼影響，影響最大的是形成了同步失敗、同步中止。

　　若是主主（主從）有同步失敗，要第一時間查看並着手解決。由於不一樣步，會形成讀取數據的不一致。應在第一時間恢復同步，

儘可能減小對業務的影響。而後再具體分析不一樣步的緣由，手動或者自動修復數據，並作pt-table-checksum數據一致性檢查。

　　目前業務通常是作主主同步，主主同步因爲是異步更新，存在更新衝突的問題，且很容易引發SQL ERROR 1032錯誤。這個應該在業務側解決，

保證同一時間只更新數據庫的一個點，相似單點寫入。咱們的解決辦法是:寫一個底層數據庫調用庫，可能涉及到更新衝突的操做，都調用這個庫。

在配置文件裏，配2個點的數據庫A、B，保證一直都更新A庫，若是A庫不可用，就去更新B庫。

　　另外，若是是對數據一致性要求較高的場景，好比涉及到錢，建議用PXC（強一致性、真正同步複製）。

 

3、解決辦法：

　　MySQL5.6.30版本，binlog模式爲ROW。

　　show slave status\G,能夠看到以下報錯：

 

Slave_SQL_Running: NO
Last_SQL_Errno: 1032
Last_SQL_Error: Worker 3 failed executing transaction '' at master log mysql-bin.000003, end_log_pos 440267874;
　　　　　　　　  Could not execute Delete_rows event on table db_test.tbuservcbgolog; Can't find record in 'tbuservcbgolog', Error_code: 1032;
 　　　　　　　　 handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000003, end_log_pos 440267874

 

 

　　從上能夠看出，是SQL_THREAD線程出錯，錯誤號碼1032。是在應用delete db_test.tbuservcbgolog 表中一行數據的事件時，因爲這條數據

不存在而出錯。此事件在主服務器Master binlog中的位置是 mysql-bin.000003, end_log_pos 440267874。（固然能夠在從服務器Slave的Relay

log中查找，具體方法見最後） 

 

方法1：跳過錯誤Event

先跳過這一條錯誤(event),讓主從同步恢復正常。（或者N條event，一條一條跳過）

　　stop slave;

　　set global sql_slave_skip_counter=1;

　　start slave;

 

方法2：跳過全部1032錯誤

更改my.cnf文件，在Replication settings下添加：

　　slave-skip-errors　＝　1032

並重啓數據庫，而後start salve。

注意：由於要重啓數據庫，不推薦，除非錯誤事件太多。

 

方法3：還原被刪除的數據

根據錯誤提示信息，用mysqlbinlog找到該條數據event SQL並逆向手動執行。如delete 改爲insert。

本例中，此事件在主服務器Master binlog中的位置是 mysql-bin.000003, end_log_pos 440267874。

1）利用mysqlbinlog工具找出440267874的事件

/usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 |grep -A 20 '440267874'

或者/usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 --stop-position=440267874 | tail -20

或者usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 > decode.log 

（ 或者加上參數-d, --database=name 來進一步過濾）

 

#160923 20:01:27 server id 1223307  end_log_pos 440267874 CRC32 0x134b2cbc      Delete_rows: table id 319 flags: STMT_END_F
### DELETE FROM `db_99ducj`.`tbuservcbgolog`
### WHERE
###   @1=10561502 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1683955 /* INT meta=0 nullable=0 is_null=0 */
###   @3=90003 /* INT meta=0 nullable=0 is_null=0 */
###   @4=0 /* INT meta=0 nullable=0 is_null=0 */
###   @5='2016-09-23 17:02:24' /* DATETIME(0) meta=0 nullable=1 is_null=0 */
###   @6=NULL /* DATETIME(0) meta=0 nullable=1 is_null=1 */
# at 440267874

 

 

以上爲檢索出來的結果，事務語句爲：delete from db_99ducj.tbuservcbgolog where @1=10561502 and @2=1683955 ...

其中@1 @2 @3...分別對應表tbuservcbgolog的列名，填補上便可。

咱們能夠逆向此SQL 將deleter 變成Insert,手動在從庫上執行此Insert SQL,以後restart slave就行了。