如何解決MySQL主從複製太慢的問題

導讀	總結一下，MySQL 並行複製策略主要是有三種思想：按照庫的級別粒度並行執行，用於決定分發策略的 hash 表裡，key 就是資料庫名。按照行級別，根據id、唯一索引、value、庫名這些來計算hash值，做分組標示根據redo log 持久化原理，同一個commit組 或者 同時進入prepare或者commit表示可以同步執行。

導致備庫延遲的原因主要有如下幾種：

• 通常備庫所在機器的效能要比主庫所在的機器效能差，執行備份自然會更慢。
• 備庫的讀壓力大。在備庫過多的執行繁重的查詢任務。
• 大事務。因為主庫上必須等事務執行完成才會寫入 binlog，再傳給備庫。一次性地用 delete 語句刪除太多資料、表 DDL都可能造成延遲。
• 主庫是多執行緒操作，而從庫卻只有一個執行緒在執行復制。
主從同步延遲解決方案

解決方案：

• 提升從庫物理機的配置，效能差異不要太大。
• 業務的持久化層的實現採用分庫架構，mysql服務可平行擴充套件，分散壓力。
• 採用讀寫分離，分散主庫壓力。
• 加入快取如Redis等，降低mysql的讀壓力。
• 避免執行大事務等費時的操作，可以將事務內容拆開執行。
• 使用同步並行複製方案MTS
並行複製

從MySQL5.6開始支援並行複製，這就解決了之前複製速度緩慢的問題。coordinator 就是原來的 sql_thread, 他負責讀取中轉日誌和分發事務。真正更新日誌的，變成了 worker 執行緒。work 執行緒的個數由引數 slave_parallel_workers 決定的。既然是並行就一定會有資料一致性的問題，兩個不同的事務如果在不同的work中同時執行，順序的影響也會造成結果不同。



所以在 coordinator 分發任務的時候，要滿足以下這兩個基本要求：

不能造成更新覆蓋。這就要求更新同一行的兩個事務，必須被分發到同一個 worker 中。
同一個事務不能被拆開，必須放到同一個 worker 中。
各個版本的多執行緒複製，都遵循了這兩條基本原則。

MySQL 5.6版本策略

官方 MySQL5.6 版本，支援了並行複製，只是支援的粒度是按庫並行。用於決定分發策略的 hash 表裡，key 就是資料庫名，同一個資料庫需要在同一個worker中序列執行，這就避免了事務之間相互影響的問題。

MariaDB 策略

MariaDB 的並行複製策略利用redo log 組提交 (group commit) 最佳化的特性：能夠在同一組裡提交的事務，一定不會修改同一行。所以可以按照食物的 commit—_id來分組。

在實現上，MariaDB 是這麼做的：

在一組裡面一起提交的事務，有一個相同的 commit_id，下一組就是 commit_id+1；
commit_id 直接寫到 binlog 裡面；傳到備庫應用的時候，相同 commit_id 的事務分發到多個 worker 執行；
這一組全部執行完成後，coordinator 再去取下一批。

MySQL 5.7策略

MySQL5.7中對 MariaDB 多策略進行了最佳化。因為同時處於 prepare 狀態的事務，在備庫執行時是可以並行的，此時的redolog已經經過了並行驗證，所以從庫也可以執行。具體步驟不做贅述，參考MariaDB策略。

MySQL 5.7.22 的並行複製策略

在 2018 年 4 月份釋出的 MySQL 5.7.22 版本里（最新5.7.37），MySQL 增加了一個新的並行複製策略，基於 WRITESET 的並行複製。相應地，新增了一個引數 binlog-transaction-dependency-tracking，用來控制是否啟用這個新策略。這個引數的可選值有以下三種。

• COMMIT_ORDER，表示的就是前面介紹的，根據同時進入 prepare 和 commit 來判斷是否可以並行的策略。
• WRITESET，表示的是對於事務涉及更新的每一行，計算出這一行的 hash 值，組成集合 writeset。如果兩個事務沒有操作相同的行，也就是說它們的 writeset 沒有交集，就可以並行。
• WRITESET_SESSION，是在 WRITESET 的基礎上多了一個約束，即在主庫上同一個執行緒先後執行的兩個事務，在備庫執行的時候，要保證相同的先後順序。

當然為了唯一標識，這個 hash 值是透過“庫名 + 表名 + 索引名 + 值”計算出來的。如果一個表上除了有主鍵索引外，還有其他唯一索引，那麼對於每個唯一索引，insert 語句對應的 writeset 就要多增加一個 hash 值。

總結

總結一下，MySQL 並行複製策略主要是有三種思想：

按照庫的級別粒度並行執行，用於決定分發策略的 hash 表裡，key 就是資料庫名。

按照行級別，根據id、唯一索引、value、庫名這些來計算hash值，做分組標示

根據redo log 持久化原理，同一個commit組 或者 同時進入prepare或者commit表示可以同步執行。

原文來自：