大家好，我是anyux。本文介紹MySQL主從複製高級進階。
延時從庫
介紹及配置
SQL線程延時：數據已經寫入relaylog中了，SQL線程稍後執行。一般企業建議3-6小時，具體看公司運維人員對於故障的反應時間
執行之前在需要先stop slave，否則會報錯，無法執行；
stop slave;
設置master_delay並重新開啟複製start slave後,，MySQL從庫會清空原有的relay log，並根據上一次的應用位置，重新從主庫拉取二進位日誌。所以如果從庫原本已經是延遲從庫了，需要重新設置延遲數值時，重啟從庫複製以後，會發現原有的relay log被清空了，並重新生成了序號從1開始的relay log。但不用擔心複製會被影響，因重新生成的relay log,是根據上一次從庫停止時所應用到的主庫log pos重新從主庫拉取binlog的。
在5.7版本中，設置master_delay後，可以只停止sql_thread線程。即stop slave sql_thread，這樣從庫就不會清空relay log並重新拉取主庫binlog了。這樣可以節省一些網絡流量和IO資源。
可以在從庫設置master_delay參數，單位為秒
change master to master_delay=300;
開啟從庫
start slave;
查看延時狀態
show slave status\G
顯示結果如下
SQL_Delay: 300 SQL_Remaining_Delay: NULL
SQL_Remaining_Delay: 整數表明延遲時間,NULL表明現在沒有延時情況
延時從庫處理邏輯故障
延時從庫的恢復思路
1.監控到資料庫邏輯故障
2.停止從庫sql_thread，記錄已經回放的位置點
stop slave sql_thread;
查看信息如下
show slave status \G
顯示結果如下
Relay_Log_File: db01-relay-bin.000009 Relay_Log_Pos: 403
3.截取relaylog
起點：
show slave status \G
顯示結果如下
Relay_Log_File: db01-relay-bin.000009 Relay_Log_Pos: 403
終點：
找到drop之前的位置點，然後進行截取
show relaylog events in 'db01-relay-bin.000009';
截取命令
mysqlbinlog --start-position='403' --stop-position='xxx' db01-relay-bin.000009 > /tmp/slave.sql
4.模擬sql線程回話日誌
從庫中執行
source /tmp/slave.sql;
5.恢復業務
情況一：從庫替代主庫工作
情況二：從庫導出故障庫，還原到主庫中