傳統(tǒng)單線程復(fù)制說(shuō)明

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

• I/O線程負(fù)責(zé)接收二進(jìn)制日志的Event寫入Relay Log。

• SQL線程讀取Relay Log并在數(shù)據(jù)庫(kù)中進(jìn)行回放。

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

• 1.主庫(kù)執(zhí)行大事務(wù)（如：大表結(jié)構(gòu)變更操作）。

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

• 3.ROW同步模式下，主庫(kù)大表無(wú)主鍵頻繁更新。

• 4.數(shù)據(jù)庫(kù)參數(shù)配置不合理，從節(jié)點(diǎn)性能存在瓶頸（如：從節(jié)點(diǎn)事務(wù)日志設(shè)置過(guò)小，導(dǎo)致頻繁刷盤）。

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

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

可以對(duì)以上延遲原因做個(gè)大致分類。

• 1.硬件方面問(wèn)題（包括磁盤IO、網(wǎng)絡(luò)IO等）

• 2.配置方面問(wèn)題。

• 3.數(shù)據(jù)庫(kù)設(shè)計(jì)問(wèn)題。

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

總結(jié)

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

MySQL5.6基于庫(kù)級(jí)別的并行復(fù)制

在實(shí)例中有多個(gè)數(shù)據(jù)庫(kù)的情況下，可以開啟多個(gè)線程，每個(gè)線程對(duì)應(yīng)一個(gè)數(shù)據(jù)庫(kù)。該模式下從節(jié)點(diǎn)會(huì)啟動(dòng)多個(gè)線程。線程分為兩類 Coordinator 和 WorkThread。

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

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

• 關(guān)鍵配置信息

slave-parallel-type=DATABASE

• 方案不足點(diǎn)

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

MySQL5.7基于組提交的并行復(fù)制

組提交說(shuō)明

簡(jiǎn)單來(lái)說(shuō)就是在雙1的設(shè)置下，事務(wù)提交后即刷盤的操作改為多個(gè)事務(wù)合并成一組事務(wù)再進(jìn)行統(tǒng)一刷盤，這樣處理就降低了磁盤IO的壓力。詳細(xì)資料參考關(guān)于組提交的說(shuō)明推文 http://www.dbjr.com.cn/article/253739.htm

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

• 如何判斷事務(wù)在一個(gè)組內(nèi)呢?

解析binlog可以發(fā)現(xiàn)里面多了last_committed和sequence_number兩個(gè)參數(shù)信息，其中last_committed存在重復(fù)的情況。

• sequence_number # 這個(gè)值指的是事務(wù)提交的序號(hào)，單調(diào)遞增。

• last_committed # 這個(gè)值有兩層含義，1.相同值代表這些事務(wù)是在同一個(gè)組內(nèi)，2.該值同時(shí)又是代表上一組事務(wù)的最大編號(hào)。

[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

• 數(shù)據(jù)庫(kù)配置

slave-parallel-type=LOGICAL_CLOCK

• 方案不足點(diǎn)

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

• binlog_group_commit_sync_delay # 等待延遲提交的時(shí)間，binlog提交后等待一段時(shí)間再 fsync。讓每個(gè) group 的事務(wù)更多，人為提高并行度。

• binlog_group_commit_sync_no_delay_count # 待提交的最大事務(wù)數(shù)，如果等待時(shí)間沒(méi)到，而事務(wù)數(shù)達(dá)到了，就立即 fsync。達(dá)到期望的并行度后立即提交，盡量縮小等待延遲。

MySQL8.0基于writeset的并行復(fù)制

writeset 基于事務(wù)結(jié)果沖突進(jìn)行判斷事務(wù)是否可以進(jìn)行并行回放的方法，他由binlog-transaction-dependency-tracking參數(shù)進(jìn)行控制，默認(rèn)采用WRITESET方法。

關(guān)鍵參數(shù)查看

參數(shù)配置項(xiàng)說(shuō)明

• COMMIT_ORDER # 使用 5.7 Group commit 的方式?jīng)Q定事務(wù)依賴。

• WRITESET     # 使用寫集合的方式?jīng)Q定事務(wù)依賴。

• WRITESET_SESSION # 使用寫集合，但是同一個(gè)session中的事務(wù)不會(huì)有相同的last_committed。

writeset 是一個(gè)HASH類型的數(shù)組，里面記錄著事務(wù)的更新信息，通過(guò)transaction_write_set_extraction判斷當(dāng)前事務(wù)更新的記錄與歷史事務(wù)更新的記錄是否存在沖突，判斷過(guò)后再采取對(duì)應(yīng)處理方法。writeset儲(chǔ)存的最大存儲(chǔ)值由binlog-transaction-dependency-history-size控制。

需要注意的是，當(dāng)設(shè)置成WRITESET或WRITESET_SESSION的時(shí)候，事務(wù)提交是無(wú)序狀態(tài)的，可以通過(guò)設(shè)置 slave_preserve_commit_order=1 強(qiáng)制按順序提交。

• binlog_transaction_dependency_history_size

設(shè)置保存在內(nèi)存中的行哈希數(shù)的上限，用于緩存之前事務(wù)修改的行信息。一旦達(dá)到這個(gè)哈希數(shù)，就會(huì)清除歷史記錄。

• transaction_write_set_extraction

該模式支持三種算法，默認(rèn)采用XXHASH64，當(dāng)從節(jié)點(diǎn)配置writeset復(fù)制的時(shí)候，該配置不能配置為OFF。該參數(shù)已經(jīng)在MySQL 8.0.26中被棄用，后續(xù)將會(huì)進(jìn)行刪除。

數(shù)據(jù)庫(kù)配置

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

引用資料：

• 阿里內(nèi)核月報(bào)：http://mysql.taobao.org/monthly/2018/06/04/

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

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

最新評(píng)論