MySQL Replication中的並行複製範例詳解

傳統單執行緒複製說明

眾所周知，MySQL在5.6版本之前，主從複製的從節點上有兩個執行緒，分別是I/O執行緒和SQL執行緒。

• I/O執行緒負責接收二進位制紀錄檔的Event寫入Relay Log。

• SQL執行緒讀取Relay Log並在資料庫中進行回放。

以上方式偶爾會造成延遲，那麼可能造成主從節點延遲的情況有哪些?

• 1.主庫執行大事務（如：大表結構變更操作）。

• 2.主庫大批次變更（如：大量插入、更新、刪除操作）。

• 3.ROW同步模式下，主庫大表無主鍵頻繁更新。

• 4.資料庫引數設定不合理，從節點效能存在瓶頸（如：從節點事務紀錄檔設定過小，導致頻繁刷盤）。

• 5.網路環境不穩定，從節點IO執行緒讀取binlog存在延遲、重連情況。

• 6.主從硬體設定差異，從節點的硬體資源使用達到上限。(比如：主節點SSD槽，從節點SAS盤)

可以對以上延遲原因做個大致分類。

• 1.硬體方面問題（包括磁碟IO、網路IO等）

• 2.設定方面問題。

• 3.資料庫設計問題。

• 4.主庫大批次變更，從節點SQL單執行緒處理不夠及時。

總結

分析以上原因可以看出要想降低主從延遲，除了改善硬體方面條件之外，另外就是需要DBA關注資料庫設計和設定問題，最後就是需要提高從節點的並行處理能力，由單執行緒回放改為多執行緒並行回放是一個比較好的方法，關鍵點在於如何在多執行緒恢復的前提下解決資料衝突和故障恢復位置點的確認問題。

MySQL5.6基於庫級別的並行複製

在範例中有多個資料庫的情況下，可以開啟多個執行緒，每個執行緒對應一個資料庫。該模式下從節點會啟動多個執行緒。執行緒分為兩類 Coordinator 和 WorkThread。

• 執行緒分工執行邏輯

Coordinator執行緒負責判斷事務是否可以並行執行，如果可以並行就把事務分發給WorkThread執行緒執行，如果判斷不能執行，如DDL，跨庫操作等，就等待所有的worker執行緒執行完成之後，再由Coordinator執行。

• 關鍵設定資訊

slave-parallel-type=DATABASE

• 方案不足點

這種並行複製的模式,只有在範例中有多個DB且DB的事務都相對繁忙的情況下才會有較高的並行度，但是日常維護中其實單個範例的的事務處理相對集中在一個DB上。通過觀察延遲可以發現基本上都是基於熱點表出現延遲的情況佔大多數。如果能夠提供基於表的並行度是一個很好方法。

MySQL5.7基於組提交的並行複製

組提交說明

簡單來說就是在雙1的設定下，事務提交後即刷盤的操作改為多個事務合併成一組事務再進行統一刷盤，這樣處理就降低了磁碟IO的壓力。詳細資料參考關於組提交的說明推文 https://www.jb51.net/article/253739.htm

一組事務同時提交也就意味著組內事務不存在衝突，故組內的事務在從節點上就可以並行執行，問題在於如何區分事務是否在同一組中的，於是在binlog中出現了兩個新的引數資訊last_committed 和 sequence_number

• 如何判斷事務在一個組內呢?

解析binlog可以發現裡面多了last_committed和sequence_number兩個引數資訊，其中last_committed存在重複的情況。

• sequence_number # 這個值指的是事務提交的序號，單調遞增。

• last_committed # 這個值有兩層含義，1.相同值代表這些事務是在同一個組內，2.該值同時又是代表上一組事務的最大編號。

[root@mgr2 GreatSQL]# mysqlbinlog mysql-bin.0000002 | grep last_committed
GTID last_committed=0 sequence_number=1
GTID last_committed=0 sequence_number=2
GTID last_committed=2 sequence_number=3
GTID last_committed=2 sequence_number=4
GTID last_committed=2 sequence_number=5
GTID last_committed=2 sequence_number=6
GTID last_committed=6 sequence_number=7
GTID last_committed=6 sequence_number=8

• 資料庫設定

slave-parallel-type=LOGICAL_CLOCK

• 方案不足點

基於組提交的同步有個不足點，就是當主節點的事務繁忙度較低的時候，導致時間段內組提交fsync刷盤的事務量較少，於是導致從庫回放的並行度並不高，甚至可能一組裡面只有一個事務，這樣從節點的多執行緒就基本用不到，可以通過設定下面兩個引數，讓主節點延遲提交。

• binlog_group_commit_sync_delay # 等待延遲提交的時間，binlog提交後等待一段時間再 fsync。讓每個 group 的事務更多，人為提高並行度。

• binlog_group_commit_sync_no_delay_count # 待提交的最大事務數，如果等待時間沒到，而事務數達到了，就立即 fsync。達到期望的並行度後立即提交，儘量縮小等待延遲。

MySQL8.0基於writeset的並行複製

writeset 基於事務結果衝突進行判斷事務是否可以進行並行回放的方法，他由binlog-transaction-dependency-tracking引數進行控制，預設採用WRITESET方法。

關鍵引數檢視

引數設定項說明

• COMMIT_ORDER # 使用 5.7 Group commit 的方式決定事務依賴。

• WRITESET     # 使用寫集合的方式決定事務依賴。

• WRITESET_SESSION # 使用寫集合，但是同一個session中的事務不會有相同的last_committed。

writeset 是一個HASH型別的陣列，裡面記錄著事務的更新資訊，通過transaction_write_set_extraction判斷當前事務更新的記錄與歷史事務更新的記錄是否存在衝突，判斷過後再採取對應處理方法。writeset儲存的最大儲存值由binlog-transaction-dependency-history-size控制。

需要注意的是，當設定成WRITESET或WRITESET_SESSION的時候，事務提交是無序狀態的，可以通過設定 slave_preserve_commit_order=1 強制按順序提交。

• binlog_transaction_dependency_history_size

設定儲存在記憶體中的行雜湊數的上限，用於快取之前事務修改的行資訊。一旦達到這個雜湊數，就會清除歷史記錄。

• transaction_write_set_extraction

該模式支援三種演演算法，預設採用XXHASH64，當從節點設定writeset複製的時候，該設定不能設定為OFF。該引數已經在MySQL 8.0.26中被棄用，後續將會進行刪除。

資料庫設定

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
binlog_transaction_dependency_tracking = WRITESET
slave_preserve_commit_order = 1

參照資料：

• 阿里核心月報：http://mysql.taobao.org/monthly/2018/06/04/

• 官方檔案：https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html

到此這篇關於MySQL Replication之並行複製的文章就介紹到這了,更多相關MySQL 並行複製內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！