某業務數據庫報表查詢延時, 使用平臺工具檢測發現SQL THREAD數據應用進程處于not running狀態，初步分析報錯error 1062，是數據冗余引起的，是存在唯一鍵的列進行插入失敗了，然后經過一系列操作，最終通過幾個方法解決了這個問題，下面由我詳細和大家分享一下，由于涉及到一些原理性操作，咱們先從技術本身原理分析一下。

先上一張主從原理圖：

前提是使用行模式并且innodb引擎的情況，用戶的插入、更新等操作會記錄到binlog，在我們的從庫會發起一個連接到主庫，主庫的binlog dump thread會把binlog發送到從庫，從庫的IO線程會接收這個主庫日志寫入到中繼日志，再則從庫的SQL應用線程從這個relay log讀取內容寫入到從庫，大概就這么一回事，至于為什么從庫會分IO線和SQL線程，我這里就不詳細解說了，我們知道原理后，本次的事件就容易下手分析了。

在MYSQL里我們使用show slave statusG 來查主從當前的讀取情況 ，從IO傳輸進程看Slave_IO_Running: Yes,從SQL應用進程看Slave_SQL_Running: No， 而且錯誤也很明顯Could not execute Write_rows event on table skdata_2021.pj_zzspdz_fpmx; Duplicate entry 043002000111-01278925 for key ak_key_2, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the events master log master-bin.000403, end_log_pos 333202176。

那我們嘗試第一個方法，就是在從庫看看這個數據是否存在,我們根據唯一的KEY，在從庫不斷刪除這個舊記錄，刪除記錄之前一定要備份，分三個步驟：備份記錄，刪除重復記錄，啟動進程，不過可惜，這種方式又引來了第二個報錯UPDATE報錯：

Could not execute Update_rows event on table skdata_2021.qrtz_scheduler_state; Cant find record in qrtz_scheduler_state,

Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the events master log master-bin.000403, end_log_pos 333327330

那此時是發現記錄不存在，我們嘗試用mysqlbinlog工具把對應的前記錄數據行查詢出來

使用mysqlbinlog主庫操作：

mysqlbinlog --no-defaults --base64-output=decode-rows --verbose  --start-position=333326998 --stop-position=333327330 master-bin.000403

把更新前記錄找出，并在從庫插入執行，再啟動slave sql進程。

至此，該錯誤解決，但又出現數據冗余錯誤，沒辦法了，要放大招才行，記得在新特性有這樣的一個參數：slave_exec_mode，通過下面的操作：

從庫操作：

show variables like %slave_exec_mode%;

set global slave_exec_mode=IDEMPOTENT;

stop slave;

start slave;

確認主從無延遲及確認數據一致 操作完后，修改回去

最后，通過幾次嘗試和分析，放大招后，數據恢復正常，  再后面通過查詢從庫當前狀態，

開始會有延時，畢竟停了一段段時間，經過半個小時，追數據后，同步恢復正常，從庫報表查詢也相應恢復，各業務也恢復正常，本次事件到此告一段落。

就本次問題，我得出一個個人的看法，在我們日常運維過程中, 出現問題時，要先從數據庫本身原理進行分析，再根據錯誤進行嘗試，但是必須要做相應的備份，備份重于一切，同時要不斷的學習數據庫的新特性，不斷提高自己這方面的能力， 在處理完后，要進行故障復盤，進行故障總結，寫好相應的故障處理步驟，像這種問題已經出現過多次，都能通過這個方法解決。

END

更多精彩干貨分享

點擊下方名片關注

IT那活兒