MySQL雙主環境複製延時故障處理

故障現象
生產中的一組MySQL雙主（主庫A和主庫B）+Keepalived高可用單寫（主庫A），出現B庫高延時問題。檢查B庫複製狀態以下圖1：

（B庫的複製狀態—圖1）
問題分析
一、和開發人員確認，這組MySQL雙主天天有批量的數據導入操做，業務是網站展現前一天股票大盤指數，數據是由腳本批量導入，從而產生了複製延時。
二、經過對導數據腳本分析，導數據是對一個表先進行delete後進行insert操做；股指大盤展現數據只保留一天數據，所以確認不須要保留前一天數據，修改腳本先truncate表後insert數據，這樣能夠加快數據導入的速度，避免複製的延時。
三、檢看錶結構，表沒有主鍵，沒有主鍵會影響主從複製。
四、檢查B庫show full processlist（圖2），有批量的查詢操做，user是dm，host是localhost鏈接是本地執行的，接下來排查系統是否有定時任務。
五、查看進程（圖3），有批量備份腳本執行，天天的備份腳本沒有完成，而且不停的執行。

（B庫processlist信息-圖2）

（B庫檢查進程-圖3）

處理問題過程
一、kill掉B庫系統上的備份腳本進程
二、A庫全備份傳輸到B庫，從作A庫到B庫的複製

（A庫做全備份並傳到B庫-圖4）
三、B庫導入A庫的備份文件，過程當中會有報錯，由於備份文件含有GTID信息，須要登陸到B庫執行reset master清除GTID信息，導入備份文件時從新生成GTID，再次導入A庫的備份文件時就能夠成功導入。

（B庫導入A庫備份-圖5）
四、從作A庫到B庫的複製
1）reset slave all; 清除B庫複製信息
2）Change master to 從作配置A庫到B庫的複製
3）Start slave；開啓複製
4）Show slave status\G 檢查複製狀態已是雙YES（圖6）
5）查看Master_Log_File=relay_master_log_file &&read_master_log_pos=exec_master_log_pos（圖7）

（B庫複製狀態-圖6）

(B庫複製狀態-圖7)

五、檢查B庫向A庫的複製狀態，因爲B庫執行了reset master清除了B庫的GTID信息，因此A庫複製報錯1236找不到master的binary log。

（A庫複製狀態-圖8）
六、恢復B庫到A庫的複製，執行change master後檢查A庫複製狀態。

（A庫複製狀態-圖9 ）
七、雙主環境的雙向複製狀態都恢復正常。

總結
這次雙主環境產生複製延時的緣由，主要是B庫的備份腳本不停的執行，形成B庫有批量的慢查詢，備份腳本在B庫不停執行的同時A庫導數據腳本在刪除數據和插入數據，A庫在刪除數據使用delete數據影響刪除效率，形成複製延時。另外A庫導數據所涉及的表沒有主鍵也影響了B庫複製數據重放速度，產生了複製延時。爲了不故障再次發生，須要給表添加主鍵，增長複製重放數據的執行效率，優化導數據腳本和備份腳本，來防止再次出現複製產生大量的延時的問題。