大家好，我是anyux。本文介紹MySQL主從複製高級進階。
延時從庫
介紹及配置
SQL線程延時：數據已經寫入relaylog中了，SQL線程稍後執行。一般企業建議3-6小時，具體看公司運維人員對於故障的反應時間
執行之前在需要先stop slave，否則會報錯，無法執行；
<code> stop slave;/<code>
設置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參數，單位為秒
<code> change master to master_delay=300;/<code>
開啟從庫
<code> start slave;/<code>
查看延時狀態
<code> show slave status\\G/<code>
顯示結果如下
<code> SQL_Delay: 300
SQL_Remaining_Delay: NULL/<code>
SQL_Remaining_Delay: 整數表明延遲時間,NULL表明現在沒有延時情況
延時從庫處理邏輯故障
延時從庫的恢復思路
1.監控到數據庫邏輯故障
2.停止從庫sql_thread，記錄已經回放的位置點
<code> stop slave sql_thread;/<code>
查看信息如下
<code> show slave status \\G/<code>
顯示結果如下
<code> Relay_Log_File: db01-relay-bin.000009
Relay_Log_Pos: 403/<code>
3.截取relaylog
起點：
<code> show slave status \\G/<code>
顯示結果如下
<code> Relay_Log_File: db01-relay-bin.000009
Relay_Log_Pos: 403/<code>
終點：
找到drop之前的位置點，然後進行截取
<code> show relaylog events in 'db01-relay-bin.000009';/<code>
截取命令
<code> mysqlbinlog --start-position='403' --stop-position='xxx' db01-relay-bin.000009 > /tmp/slave.sql/<code>
4.模擬sql線程回話日誌
從庫中執行
<code> source /tmp/slave.sql;/<code>
5.恢復業務
情況一：從庫替代主庫工作
情況二：從庫導出故障庫，還原到主庫中
分享到:
閱讀更多 anyux1 的文章
