MySQL 的 MTS

IT那活兒發(fā)布于2023-01-11 13:19 / 369人閱讀

MySQL 的 MTS

點(diǎn)擊上方“IT那活兒”公眾號(hào)，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！！！

Mysql的并行復(fù)制技術(shù)演變，mysql并行復(fù)制enhanced multi-threaded slave， 5.6是基于schema并行，到5.7的group commit在這之前redo log和binlog串行刷盤很影響性能，group commit出現(xiàn)將事務(wù)分組，組內(nèi)的binlog刷盤動(dòng)作交給一個(gè)事務(wù)進(jìn)行，實(shí)現(xiàn)組提交目的，通過redo log和binlog的組提交解決磁盤IO的性能。

MTS based on schema

涉及不同 schema 的 DML 操作，在 slave 端可以按 schema 粒度并行回放，弱點(diǎn)也很明顯，如果實(shí)例中的 schema 較少，并行回放效果并不理想。其優(yōu)化方式也比較簡單 slave_parallel_workers 小于等于 master 的 schema 數(shù)量。

LOGICAL_CLOCK并行復(fù)制

參數(shù) slave-parallel-type 來控制并行復(fù)制策略，配置為 LOGICAL_CLOCK。

原理：redo log組提交（group commit）策略，為同一組一起提交的事務(wù)維護(hù)一個(gè)commit_id,并寫入binlog日志。日志傳到備庫后，coordinator會(huì)以輪詢的方式將相同commit_id的事務(wù)分發(fā)到多個(gè)worker執(zhí)行，待一組執(zhí)行完成后，再取下一批。

在 binlog 中每個(gè)事務(wù)會(huì)有多出兩個(gè)標(biāo)簽：

sequence_number：隨每個(gè)事務(wù)遞增的自增 ID，每次新的 binlog 會(huì)從 1 開始；
last_committed：當(dāng)前事務(wù)所依賴的上次事務(wù)的 sequence_number，每次新的 binlog 會(huì)從 0 開始。

last_committed 相同值的事務(wù)代表同時(shí)提交的，可以并行回放。

#180105 20:08:33 ... last_committed=7201 sequence_number=7203
#180105 20:08:33 ... last_committed=7203 sequence_number=7204
#180105 20:08:33 ... last_committed=7203 sequence_number=7205
#180105 20:08:33 ... last_committed=7203 sequence_number=7206
#180105 20:08:33 ... last_committed=7205 sequence_number=7207

7203 事務(wù)依賴 7201；
7204、7205、7206 事務(wù)依賴 7203，可以并行提交；
7207 事務(wù)依賴 7205，由于 7205 依賴 7203，那么在 7205 執(zhí)行完后，7207 可以和 7206 并行執(zhí)行。

優(yōu)化方式通過調(diào)整 master group commit size 和 slave 的并行 work 線程數(shù)，提升并行效率。

master group commit size 和并發(fā)壓力，master group commit size主要跟下面兩個(gè)參數(shù)相關(guān)：

binlog_group_commit_sync_delay
表示 binlog 提交事務(wù)前等待多少微秒；
binlog_group_commit_sync_no_delay_count
表示同步隊(duì)列最大允許的事務(wù)數(shù)，當(dāng)?shù)却峤坏木€程達(dá)到多少時(shí), 就不在等待，在 master 低并發(fā)的負(fù)載下，并行回放效果就不好了，如果想要提高并行度，需要增加 binlog_group_commit_sync_delay，積累較多的分組大小，副作用是拉低 master 吞吐量。

Write set

上述基于組提交的并行存在一些問題，組提交的理論依據(jù)是如果多個(gè)事務(wù)他們能在同一時(shí)間內(nèi)提交，這個(gè)就間接說明了這個(gè)幾個(gè)事務(wù)鎖上是沒有沖突的，也是就說他們各自持有不同的鎖，互不影響；邏輯上可以把這幾個(gè)事務(wù)看成一個(gè)組，在slave以“組”為單位分配給sql線程執(zhí)行，這樣多個(gè)sql線程就可以并行跑了。所以它要求庫上要有一定的并發(fā)度，不然就有可能變成每個(gè)組里面只有一個(gè)事務(wù)，這樣就有串行沒什么區(qū)別了。

writeset就解決了上述的問題，如果兩次修改的數(shù)據(jù)沒有沖突，就會(huì)打包到一個(gè)組里面并行回放，WriteSet通過檢測(cè)兩個(gè)事務(wù)是否更新了相同的記錄來判斷事務(wù)能否并行回放的，因此需要在運(yùn)行時(shí)保存已經(jīng)提交的事務(wù)信息以記錄歷史事務(wù)更新了哪些行。記錄歷史事務(wù)的參數(shù)為binlog_transaction_dependency_history_size。該值越大可以記錄更多的已經(jīng)提交的事務(wù)信息，不過需要注意的是，這個(gè)值并非指事務(wù)大小，而是指追蹤的事務(wù)更新信息的數(shù)量。

開啟writeset：

binlog_format=row
開啟 transaction_write_set_extraction=XXHASH64
更新表必須有主鍵，如果更新事務(wù)包含外鍵，則退回 commit_order 方式
binlog_transaction_dependency_tracking = [COMMIT_ORDER | WRITESET | WRITESET_SESSION]

slave 上開啟 slave_parallel_workers。