chang 刪除 數據導入 展示 需要 fff amp lis 修改

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

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

（B庫processlist信息-圖2）

（B庫檢查進程-圖3）

處理問題過程
1、kill掉B庫系統上的備份腳本進程
2、A庫全備份傳輸到B庫，從做A庫到B庫的復制

（A庫作全備份並傳到B庫-圖4）
3、B庫導入A庫的備份文件，過程中會有報錯，因為備份文件含有GTID信息，需要登錄到B庫執行reset master清除GTID信息，導入備份文件時重新生成GTID，再次導入A庫的備份文件時就可以成功導入。

（B庫導入A庫備份-圖5）
4、從做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)

5、檢查B庫向A庫的復制狀態，由於B庫執行了reset master清除了B庫的GTID信息，所以A庫復制報錯1236找不到master的binary log。

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

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

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

MySQL雙主環境復制延時故障處理