6.1 外在因素
網絡
主從硬件差異較大
版本差異
參數因素
6.2 主庫
(1) 二進制日志寫入不及時 [rep]>select @@sync_binlog; (2) CR(傳統)的主從復制中,binlog_dump線程,事件為單元,串行傳送二進制日志(5.6 5.5) 1. 主庫並發事務量大,主庫可以並行,傳送時是串行 2. 主庫發生了大事務,由於是串行傳送,會產生阻塞后續的事務.
3. 主庫本身就及其繁忙,如慢語句, 鎖等待, 從庫個數比較多 解決方案: 1. 5.6 開始,開啟GTID,實現了GC(group commit)機制,可以並行傳輸日志給從庫IO線程,這個還需要配合雙一標准來實現 2. 5.7 開始,不開啟GTID,會自動維護匿名的GTID,也能實現GC,我們建議還是認為開啟GTID 3. 大事務拆成多個小事務,可以有效的減少主從延時.
6.3 從庫
SQL線程導致的主從延時 在CR(傳統)復制情況下: 從庫默認情況下只有一個SQL線程,只能串行回放事務SQL 1. 主庫如果並發事務量較大,從庫只能串行回放 2. 主庫發生了大事務,會阻塞后續的所有的事務的運行 解決方案: 1. 5.6 版本開啟GTID之后,加入了SQL多線程的特性,但是只能針對不同庫(database)下的事務進行並發回放. 2. 5.7 版本開始GTID之后,在SQL線程方面,提供了基於邏輯時鍾(logical_clock),binlog方面加入了seq_no機制(同線程下的序列號), 真正實現了基於事務級別的並發回放,這種技術我們把它稱之為MTS(enhanced multi-threaded slave).
總結: 5.6基於庫級別的並發sql線程; 5.7基於事務級別的並發sql線程. 3. 大事務拆成多個小事務,可以有效的減少主從延時. [https://dev.mysql.com/worklog/task/?id=6314]
6.3.1 如何確定sql線程執行了多少io線程拿來的日志呢?
1. 可以直接查看relay-log.info文件, 該文件中記錄了relay-log和master-log之間的對應關系. 2. show relaylog events in '192-relay-bin.000005'; 66.
1. 到數據路徑, cat relay-log.info 這里記錄有relay-log的pos對應read_master_log的pos號.
2. show slave status中還有個 Exec_Master_Log_Pos
參數值中明確指出執行到master_log_file中的哪個pos號.
總結: 排查主從延遲思路,先排除主庫,可以從以下方面考慮
1. show maste status; 查看主庫的position號記錄到多少了.
2. 從庫中執行show slave status; 查看從庫現在獲取到哪個position號了.
3. 如果主從庫的postion號一致,則表示主庫沒有問題.
4. 如果從庫的postion號遠小於主庫的position號,則表示主庫dump線程傳送二進制出問題了.
5. 如果是主庫的原因, 參考上面6.2的解決辦法.
6. 如果是從庫的原因, 參考上面6.3的解決辦法.