MySQL?Replication中的并行復(fù)制示例詳解
傳統(tǒng)單線程復(fù)制說明
眾所周知，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è)置過小，導(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.硬件方面問題（包括磁盤IO、網(wǎng)絡(luò)IO等）
2.配置方面問題。
3.數(shù)據(jù)庫(kù)設(shè)計(jì)問題。
4.主庫(kù)大批量變更，從節(jié)點(diǎn)SQL單線程處理不夠及時(shí)。
總結(jié)
分析以上原因可以看出要想降低主從延遲，除了改善硬件方面條件之外，另外就是需要DBA關(guān)注數(shù)據(jù)庫(kù)設(shè)計(jì)和配置問題，最后就是需要提高從節(jié)點(diǎn)的并發(fā)處理能力，由單線程回放改為多線程并行回放是一個(gè)比較好的方法，關(guān)鍵點(diǎn)在于如何在多線程恢復(fù)的前提下解決數(shù)據(jù)沖突和故障恢復(fù)位置點(diǎn)的確認(rè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上。通過觀察延遲可以發(fā)現(xiàn)基本上都是基于熱點(diǎn)表出現(xiàn)延遲的情況占大多數(shù)。如果能夠提供基于表的并行度是一個(gè)很好方法。
MySQL5.7基于組提交的并行復(fù)制
組提交說明
簡(jiǎn)單來說就是在雙1的設(shè)置下，事務(wù)提交后即刷盤的操作改為多個(gè)事務(wù)合并成一組事務(wù)再進(jìn)行統(tǒng)一刷盤，這樣處理就降低了磁盤IO的壓力。詳細(xì)資料參考關(guān)于組提交的說明推文 http://m.fzitv.net/article/253739.htm
一組事務(wù)同時(shí)提交也就意味著組內(nèi)事務(wù)不存在沖突，故組內(nèi)的事務(wù)在從節(jié)點(diǎn)上就可以并發(fā)執(zhí)行，問題在于如何區(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)的多線程就基本用不到，可以通過設(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í)間沒到，而事務(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ù)查看
| Command-Line Format | --binlog-transaction-dependency-tracking=value |
|---|---|
| System Variable | binlog_transaction_dependency_tracking |
| Scope | Global |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Enumeration |
| Default Value | COMMIT_ORDER |
| Valid Values | COMMIT_ORDER WRITESET WRITESET_SESSION |
參數(shù)配置項(xiàng)說明
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ù)的更新信息，通過
transaction_write_set_extraction判斷當(dāng)前事務(wù)更新的記錄與歷史事務(wù)更新的記錄是否存在沖突，判斷過后再采取對(duì)應(yīng)處理方法。writeset儲(chǔ)存的最大存儲(chǔ)值由binlog-transaction-dependency-history-size控制。
需要注意的是，當(dāng)設(shè)置成
WRITESET或WRITESET_SESSION的時(shí)候，事務(wù)提交是無(wú)序狀態(tài)的，可以通過設(shè)置slave_preserve_commit_order=1強(qiáng)制按順序提交。
binlog_transaction_dependency_history_size
設(shè)置保存在內(nèi)存中的行哈希數(shù)的上限，用于緩存之前事務(wù)修改的行信息。一旦達(dá)到這個(gè)哈希數(shù)，就會(huì)清除歷史記錄。
| Command-Line Format | --binlog-transaction-dependency-history-size=# |
|---|---|
| System Variable | binlog_transaction_dependency_history_size |
| Scope | Global |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Integer |
| Default Value | 25000 |
| Minimum Value | 1 |
| Minimum Value | 1000000 |
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)行刪除。
| Command-Line Format | --transaction-write-set-extraction[=value] |
|---|---|
| Deprecated | 8.0.26 |
| System Variable | binlog_transaction_dependency_history_size |
| Scope | Global, Session |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Enumeration |
| Default Value | XXHASH64 |
| Valid Values | OFF MURMUR32 XXHASH64 |
數(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)文章希望大家以后多多支持腳本之家！
相關(guān)文章
MySQL的鎖機(jī)制之全局鎖和表鎖的實(shí)現(xiàn)
本文主要介紹了MySQL的鎖機(jī)制之全局鎖和表鎖的實(shí)現(xiàn)，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-01-01
DBeaver如何將mysql表結(jié)構(gòu)以表格形式導(dǎo)出
DBeaver是一款多功能數(shù)據(jù)庫(kù)工具,支持包括MySQL在內(nèi)的多種數(shù)據(jù)庫(kù),本文介紹如何使用DBeaver將MySQL的表結(jié)構(gòu)以表格形式導(dǎo)出,為數(shù)據(jù)庫(kù)管理和文檔整理提供便利,這種方法簡(jiǎn)潔有效,適合需要文檔化數(shù)據(jù)庫(kù)結(jié)構(gòu)的開發(fā)者和數(shù)據(jù)庫(kù)管理員2024-10-10
最近在做mysql的性能憂化，做到多表連接查詢，比較頭疼，看了一些join的資料，終于搞定，這里分享出來！2009-12-12
Centos7下使用yum安裝mysql數(shù)據(jù)庫(kù)的詳細(xì)教程(增強(qiáng)版)
這篇文章主要介紹了Centos7下使用yum安裝mysql數(shù)據(jù)庫(kù)的詳細(xì)教程(增強(qiáng)版),非常不錯(cuò)，具有參考借鑒價(jià)值，需要的朋友可以參考下2016-12-12
MySQL隱式類型轉(zhuǎn)換導(dǎo)致索引失效的解決
本文主要介紹了MySQL隱式類型轉(zhuǎn)換導(dǎo)致索引失效的解決，文中通過示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-08-08
這篇文章主要介紹了MySQL 5.7.17壓縮版安裝筆記，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-02-02
MySQL針對(duì)Discuz論壇程序的基本優(yōu)化教程
這篇文章主要介紹了MySQL針對(duì)Discuz論壇程序的基本優(yōu)化教程,包括在緩存和索引等方面的優(yōu)化方法,需要的朋友可以參考下2015-11-11
MySQL主從復(fù)制是一個(gè)異步的復(fù)制過程，就是有兩個(gè)數(shù)據(jù)庫(kù)服務(wù)器,一個(gè)是主(master)數(shù)據(jù)庫(kù)服務(wù)器,另一個(gè)是從(slave)數(shù)據(jù)庫(kù)服務(wù)器。2022-09-09
數(shù)據(jù)結(jié)構(gòu)-樹（三）：多路搜索樹B樹、B+樹
這篇文章主要介紹了多路搜索樹B樹、B+樹，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-04-04
Mysql大表全表查詢的全過程(分析底層的數(shù)據(jù)流轉(zhuǎn)過程)
這篇文章主要介紹了Mysql大表全表查詢的全過程(分析底層的數(shù)據(jù)流轉(zhuǎn)過程),具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-08-08