某業(yè)務(wù)數(shù)據(jù)庫(kù)報(bào)表查詢延時(shí), 使用平臺(tái)工具檢測(cè)發(fā)現(xiàn)SQL THREAD數(shù)據(jù)應(yīng)用進(jìn)程處于not running狀態(tài)，初步分析報(bào)錯(cuò)error 1062，是數(shù)據(jù)冗余引起的，是存在唯一鍵的列進(jìn)行插入失敗了，然后經(jīng)過(guò)一系列操作，最終通過(guò)幾個(gè)方法解決了這個(gè)問題，下面由我詳細(xì)和大家分享一下，由于涉及到一些原理性操作，咱們先從技術(shù)本身原理分析一下。

先上一張主從原理圖：

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

在MYSQL里我們使用show slave statusG 來(lái)查主從當(dāng)前的讀取情況 ，從IO傳輸進(jìn)程看Slave_IO_Running: Yes,從SQL應(yīng)用進(jìn)程看Slave_SQL_Running: No， 而且錯(cuò)誤也很明顯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。

那我們嘗試第一個(gè)方法，就是在從庫(kù)看看這個(gè)數(shù)據(jù)是否存在,我們根據(jù)唯一的KEY，在從庫(kù)不斷刪除這個(gè)舊記錄，刪除記錄之前一定要備份，分三個(gè)步驟：備份記錄，刪除重復(fù)記錄，啟動(dòng)進(jìn)程，不過(guò)可惜，這種方式又引來(lái)了第二個(gè)報(bào)錯(cuò)UPDATE報(bào)錯(cuò)：

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

那此時(shí)是發(fā)現(xiàn)記錄不存在，我們嘗試用mysqlbinlog工具把對(duì)應(yīng)的前記錄數(shù)據(jù)行查詢出來(lái)

使用mysqlbinlog主庫(kù)操作：

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

把更新前記錄找出，并在從庫(kù)插入執(zhí)行，再啟動(dòng)slave sql進(jìn)程。

至此，該錯(cuò)誤解決，但又出現(xiàn)數(shù)據(jù)冗余錯(cuò)誤，沒辦法了，要放大招才行，記得在新特性有這樣的一個(gè)參數(shù)：slave_exec_mode，通過(guò)下面的操作：

從庫(kù)操作：

show variables like %slave_exec_mode%;

set global slave_exec_mode=IDEMPOTENT;

stop slave;

start slave;

確認(rèn)主從無(wú)延遲及確認(rèn)數(shù)據(jù)一致 操作完后，修改回去

最后，通過(guò)幾次嘗試和分析，放大招后，數(shù)據(jù)恢復(fù)正常，  再后面通過(guò)查詢從庫(kù)當(dāng)前狀態(tài)，

開始會(huì)有延時(shí)，畢竟停了一段段時(shí)間，經(jīng)過(guò)半個(gè)小時(shí)，追數(shù)據(jù)后，同步恢復(fù)正常，從庫(kù)報(bào)表查詢也相應(yīng)恢復(fù)，各業(yè)務(wù)也恢復(fù)正常，本次事件到此告一段落。

就本次問題，我得出一個(gè)個(gè)人的看法，在我們?nèi)粘＿\(yùn)維過(guò)程中, 出現(xiàn)問題時(shí)，要先從數(shù)據(jù)庫(kù)本身原理進(jìn)行分析，再根據(jù)錯(cuò)誤進(jìn)行嘗試，但是必須要做相應(yīng)的備份，備份重于一切，同時(shí)要不斷的學(xué)習(xí)數(shù)據(jù)庫(kù)的新特性，不斷提高自己這方面的能力， 在處理完后，要進(jìn)行故障復(fù)盤，進(jìn)行故障總結(jié)，寫好相應(yīng)的故障處理步驟，像這種問題已經(jīng)出現(xiàn)過(guò)多次，都能通過(guò)這個(gè)方法解決。

END

更多精彩干貨分享

點(diǎn)擊下方名片關(guān)注

IT那活兒