MySQL高可用（二）主備延時如何解決？

從上篇文章咱們知道主備同步是依賴於 binlog，主庫負責生產 binlog，備庫負責消費 binlog，從而實現主備同步。

今天咱們來學習一下主備同步裏的一個重點的問題：主備延時。

主備延時，簡單來講，就是主庫和備庫的數據一致出現必定的時間差，好比備庫的此刻的數據快照是主備5分鐘前的數據快照，那就說明主備延時有5分鐘。

主備延遲是怎麼產生的

產生主備延遲的根本緣由是備庫上消費 binlog 的速度趕不上主庫產生 binlog 的速度。好比：

• 大事務，例如一次性delete不少數據；
• 大表的DDL；
• 備庫壓力大。例若有些像運維、訂單等統計分析在備機上跑；
• 主備庫的服務器的配置不一樣，主庫的服務器配置好，備庫的服務器配置差。

主備延遲的排查之路

網絡

網絡可能致使主備延遲的問題，好比主庫或者備庫的帶寬滿負載、主備之間網絡延遲很大，有可能會致使主庫的 binlog 沒有全量傳輸到備庫，形成延遲。

機器性能

備庫 使用了爛機器？ 好比主庫使用了 SSD，而備庫使用的是 SATA。

備庫 高負載？ 可能在備庫上作統計分析，致使備庫的負載很高。可以使用 top 命令進行排查。

備庫 磁盤有問題？ 磁盤、raid卡、調度策略有問題的狀況下，有的時候會出現單個IO延遲很高的狀況。可以使用 iostat 查看 IO 運行狀況。

大事務

是否常常有大事務？ 好比在 RBR 模式下，執行帶有大量的 delete 操做，或者一個表的 alter 操做等，都會致使延時狀況的發生。可經過 processlist 命令查看相關信息，或者使用 mysqlbinlog 查看 binlog 中的 SQL 就能快速確認。

鎖

鎖衝突問題也可能致使備庫的 SQL 線程執行慢。好比一些 select ... for update 的 SQL。可經過 processlist 和 查看 information_schema 下面與鎖和事務相關的表來查看分析。

參數

若是使用的是 InnoDB 引擎，能夠調整 innodb_flush_log_at_trx_commit、sync_binlog 參數來提高複製速度。

sync_binlog 的默認值是 0，MySQL 不會將 binlog 同步到磁盤，其值表示每寫多少 binlog 同步一次磁盤。

innodb_flush_log_at_trx_commit 其值表示每一次事務提交或事務外的指令須要把日誌 flush 到磁盤。

注：這種調整可能會影響數據的安全性，須要結合業務來考慮。

多線程

在 MySQL 5.6 版本以前，MySQL採用單線程複製，而從 5.6 開始，正式支持多線程複製。

若是是單線程同步，單個線程存在寫入瓶頸，致使主備延遲，那就先調整爲多線程試試效果。

能夠經過 show processlist 查看是否有多個同步線程，也能夠查看參數的方式查看是否使用多線程（show variables like '%備庫_parallel%'）

當你看到是上圖這種結果的時候，恭喜你，你使用的是單線程。使用下面那行命令改形成多線程複製：

STOP 備庫 SQL_THREAD;SET GLOBAL 備庫_parallel_type='LOGICAL_CLOCK';SET GLOBAL 備庫_parallel_workers=8;START 備庫 SQL_THREAD;

改造後以下圖所示：

參考資料

• 完全終結MySQL同步延遲問題
• MySQL的主從延遲怎麼解決
• 25 | MySQL是怎麼保證高可用的？