主備延遲最直接的表現是，備庫消費中轉日志（relay log）的速度，比主庫生產 binlog 的速度要慢。

備庫所在機器的性能要比主庫所在的機器性能差。這種部署現在比較少了。因為主備可能發生切換，備庫隨時可能變成主庫，所以主備庫選 用相同規格的機器，并且做對稱部署，是現在比較常見的情況。

備庫的壓力大。一般的想法是，主庫既然提供了寫能力，那么備 庫可以提供一些讀能力。或者一些運營后臺需要的分析語句，不能影響正常業務，所以只能在備庫上跑。

大事務。因為主庫上必須等事務執行完成才會寫入 binlog，再傳給備庫。所 以，如果一個主庫上的語句執行 10 分鐘，那這個事務很可能就會導致從庫延遲 10 分鐘。所以不要一次性刪除大量數據。

備庫沒有并行復制能力。下面是其解決方法。

把上圖中只有一個線程的 sql_thread，拆成多個線程。

coordinator 就是原來的 sql_thread, 不過現在它不再直接更新數據了，只負責讀取中 轉日志和分發事務。真正更新日志的，變成了 worker 線程。而 work 線程的個數，就是由參數 slave_parallel_workers 決定的。把這個值設置為 8~16 之間最好（32 核物理 機的情況），畢竟備庫還有可能要提供讀查詢，不能把 CPU 都吃光了。

?

總結

以上是生活随笔為你收集整理的什么原因可能导致主备延迟？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。