亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

MySQL?Replication中的并行復制示例詳解

 更新時間：2022年07月01日 10:16:04   作者：老葉茶館  
MySQL在5.6版本之前，主從復制的從節(jié)點上有兩個線程，分別是I/O線程和SQL線程，今天通過本文給大家介紹MySQL?Replication中的并行復制示例詳解，感興趣的朋友一起看看吧

傳統(tǒng)單線程復制說明

眾所周知，MySQL在5.6版本之前，主從復制的從節(jié)點上有兩個線程，分別是I/O線程和SQL線程。

  • I/O線程負責接收二進制日志的Event寫入Relay Log。

  • SQL線程讀取Relay Log并在數據庫中進行回放。

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

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

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

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

  • 4.數據庫參數配置不合理，從節(jié)點性能存在瓶頸（如：從節(jié)點事務日志設置過小，導致頻繁刷盤）。

  • 5.網絡環(huán)境不穩(wěn)定，從節(jié)點IO線程讀取binlog存在延遲、重連情況。

  • 6.主從硬件配置差異，從節(jié)點的硬件資源使用達到上限。(比如：主節(jié)點SSD盤，從節(jié)點SAS盤)

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

  • 1.硬件方面問題（包括磁盤IO、網絡IO等）

  • 2.配置方面問題。

  • 3.數據庫設計問題。

  • 4.主庫大批量變更，從節(jié)點SQL單線程處理不夠及時。

總結

分析以上原因可以看出要想降低主從延遲，除了改善硬件方面條件之外，另外就是需要DBA關注數據庫設計和配置問題，最后就是需要提高從節(jié)點的并發(fā)處理能力，由單線程回放改為多線程并行回放是一個比較好的方法，關鍵點在于如何在多線程恢復的前提下解決數據沖突和故障恢復位置點的確認問題。

MySQL5.6基于庫級別的并行復制

在實例中有多個數據庫的情況下，可以開啟多個線程，每個線程對應一個數據庫。該模式下從節(jié)點會啟動多個線程。線程分為兩類 Coordinator 和 WorkThread。

  • 線程分工執(zhí)行邏輯

Coordinator線程負責判斷事務是否可以并行執(zhí)行，如果可以并行就把事務分發(fā)給WorkThread線程執(zhí)行，如果判斷不能執(zhí)行，如DDL，跨庫操作等，就等待所有的worker線程執(zhí)行完成之后，再由Coordinator執(zhí)行。

  • 關鍵配置信息

slave-parallel-type=DATABASE

  • 方案不足點

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

MySQL5.7基于組提交的并行復制

組提交說明

簡單來說就是在雙1的設置下，事務提交后即刷盤的操作改為多個事務合并成一組事務再進行統(tǒng)一刷盤，這樣處理就降低了磁盤IO的壓力。詳細資料參考關于組提交的說明推文 http://chabaoo.cn/article/253739.htm

一組事務同時提交也就意味著組內事務不存在沖突，故組內的事務在從節(jié)點上就可以并發(fā)執(zhí)行，問題在于如何區(qū)分事務是否在同一組中的，于是在binlog中出現了兩個新的參數信息last_committed 和 sequence_number

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

解析binlog可以發(fā)現里面多了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

  • 方案不足點

基于組提交的同步有個不足點，就是當主節(jié)點的事務繁忙度較低的時候，導致時間段內組提交fsync刷盤的事務量較少，于是導致從庫回放的并行度并不高，甚至可能一組里面只有一個事務，這樣從節(jié)點的多線程就基本用不到，可以通過設置下面兩個參數，讓主節(jié)點延遲提交。

  • 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方法。

關鍵參數查看

Command-Line Format--binlog-transaction-dependency-tracking=value
System Variablebinlog_transaction_dependency_tracking
ScopeGlobal
DynamicYes
SET_VAR Hint AppliesNo
TypeEnumeration
Default ValueCOMMIT_ORDER
Valid ValuesCOMMIT_ORDER
WRITESET
WRITESET_SESSION

參數配置項說明

  • 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的時候，事務提交是無序狀態(tài)的，可以通過設置 slave_preserve_commit_order=1 強制按順序提交。

  • binlog_transaction_dependency_history_size

設置保存在內存中的行哈希數的上限，用于緩存之前事務修改的行信息。一旦達到這個哈希數，就會清除歷史記錄。

Command-Line Format--binlog-transaction-dependency-history-size=#
System Variablebinlog_transaction_dependency_history_size
ScopeGlobal
DynamicYes
SET_VAR Hint AppliesNo
TypeInteger
Default Value25000
Minimum Value1
Minimum Value1000000

  • transaction_write_set_extraction

該模式支持三種算法，默認采用XXHASH64，當從節(jié)點配置writeset復制的時候，該配置不能配置為OFF。該參數已經在MySQL 8.0.26中被棄用，后續(xù)將會進行刪除。

Command-Line Format--transaction-write-set-extraction[=value]
Deprecated8.0.26
System Variablebinlog_transaction_dependency_history_size
ScopeGlobal, Session
DynamicYes
SET_VAR Hint AppliesNo
TypeEnumeration
Default ValueXXHASH64
Valid ValuesOFF
MURMUR32
XXHASH64

數據庫配置

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

引用資料：

到此這篇關于MySQL Replication之并行復制的文章就介紹到這了,更多相關MySQL 并行復制內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

相關文章

最新評論