作者：洪斌

愛可生南區(qū)負(fù)責(zé)人兼技術(shù)服務(wù)總監(jiān)，MySQL ACE，擅長數(shù)據(jù)庫架構(gòu)規(guī)劃、故障診斷、性能優(yōu)化分析，實(shí)踐經(jīng)驗(yàn)豐富，幫助各行業(yè)客戶解決 MySQL 技術(shù)問題，為金融、運(yùn)營商、互聯(lián)網(wǎng)等行業(yè)客戶提供 MySQL 整體解決方案。

本文來源：轉(zhuǎn)載自公眾號(hào)-玩轉(zhuǎn)MySQL

*愛可生開源社區(qū)出品，原創(chuàng)內(nèi)容未經(jīng)授權(quán)不得隨意使用，轉(zhuǎn)載請(qǐng)聯(lián)系小編并注明來源。

MySQL 并行回放在一路改進(jìn)，從 5.6 的 schema 并行，到 5.7 的 group commit，再到 8.0 的 write set。

MTS based on schema

這種方式不用多說，涉及不同 schema 的 DML 操作，在 slave 端可以按 schema 粒度并行回放，弱點(diǎn)也很明顯，如果實(shí)例中的 schema 較少，并行回放效果并不理想。

其優(yōu)化方式也比較簡單 slave_parallel_workers 小于等于 master 的 schema 數(shù)量。

LOGICAL_CLOCK

MySQL 5.7 增加了基于 group commit 的并行回放策略，使得 slave 可以接近 master 同樣并發(fā)回放事務(wù)，master 并發(fā)越高，slave 并行回放效果越明顯。

在 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

1. 7203 事務(wù)依賴 7201

2. 7204、7205、7206 事務(wù)依賴 7203，可以并行提交

3. 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ā)壓力，以及下面兩個(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

MySQL 8.0.1 & 5.7.22 在 group commit 基礎(chǔ)上進(jìn)一步改善了并行復(fù)制效率，增加了新的跟蹤事務(wù)依賴關(guān)系的機(jī)制。相對(duì)于基于事務(wù) commit timestamp，即使 master 低并發(fā)場景下也能使 slave 根據(jù)事務(wù)依賴關(guān)系并行重放，充分利用硬件資源，不需要像 MySQL 5.7 增加 binlog_group_commit_sync_delay 延遲的方式，增加可并行的事務(wù)，降低復(fù)制延遲。

在 master 上滿足以下條件：

1. binlog_format=row

2. 開啟 transaction_write_set_extraction=XXHASH64

3. 更新表必須有主鍵，如果更新事務(wù)包含外鍵，則退回 commit_order 方式

4. binlog_transaction_dependency_tracking = [COMMIT_ORDER | WRITESET | WRITESET_SESSION]

slave 上開啟 slave_parallel_workers

COMMIT_ORDER 基于 commit timestamp

不同會(huì)話在相同時(shí)間執(zhí)行可以并行回放

WRITESET 變更不同行的操作都可以并行無主鍵 退回 commit_order 模式

hongbin@MBP ~/w/s/msb_8_0_3> mysqlbinlog data/MBP-bin.000013 |grep last_ |sed -e 's/server id.*last/[...] last/' -e 's/.rbr_only.*/ [...]/'

#180105 21:19:31 [...] last_committed=0 sequence_number=1 [...] create table t1 (id);

#180105 21:19:50 [...] last_committed=1 sequence_number=2 [...] insert t1 value(1);

#180105 21:19:52 [...] last_committed=2 sequence_number=3 [...] insert t1 value(2);

#180105 21:19:54 [...] last_committed=3 sequence_number=4 [...] insert t1 value(3);有主鍵 單個(gè)會(huì)話也可以并行

#180105 21:23:58 [...] last_committed=4 sequence_number=5 [...] create table t2 (id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, str VARCHAR(80) NOT NULL UNIQUE);

#180105 21:24:19 [...] last_committed=5 sequence_number=6 [...] session1: insert t2(str) value('a');

#180105 21:24:21 [...] last_committed=5 sequence_number=7 [...] session1: insert t2(str) value('b');

#180105 21:24:25 [...] last_committed=5 sequence_number=8 [...] session1: insert t2(str) value('c');

WRITESET_SESSION 相同會(huì)話不會(huì)被重新排序，不同會(huì)話可并行

在相同會(huì)話中執(zhí)行

#180106 13:15:26 [...] last_committed=0 sequence_number=1 [...] session1：insert t2(str) value('h');

#180106 13:15:31 [...] last_committed=1 sequence_number=2 [...] session1：insert t2(str) value('l');

在不同會(huì)話中執(zhí)行

#180106 13:17:08 [...] last_committed=1 sequence_number=3 [...] session1: insert t2(str) value('q');

#180106 13:17:09 [...] last_committed=1 sequence_number=4 [...] session2: insert t2(str) value('w');

如何觀測并行回放

如何評(píng)估 slave_parallel_workers 設(shè)置多少合適？如果設(shè)置小了，任務(wù)會(huì)有積壓，如果設(shè)置大了，多余的線程是空閑的。

計(jì)算機(jī)領(lǐng)域有這么個(gè)公式專門來研究系統(tǒng)資源分配公平性。

出自論文《A Quantitative Measure Of Fairness And Discrimination For Resource Allocation In Shared Computer Systems》引用數(shù) 4000+

這個(gè)公式稱為 jain's index 計(jì)算一系統(tǒng)共享資源分配公平性的指數(shù)，指數(shù)值在 0

借用此公式是不是可以來計(jì)算回放線程任務(wù)分配的公平性，如果 slave_parallel_workers 設(shè)置過大，反應(yīng)任務(wù)分配公平性較差。找到合適的 slave_parallel_workers。

這里需要啟用 performance_schema 的 transaction 級(jí)的 instrument，搜集線程事務(wù)提交信息。

call sys.ps_setup_enable_consumer('events_transactions%');

call sys.ps_setup_enable_instrument('transaction');

將公式轉(zhuǎn)換為 SQL 語句如下

select ROUND(POWER(SUM(trx_summary.COUNT_STAR), 2) /

(@@GLOBAL.slave_parallel_workers * SUM(POWER(trx_summary.COUNT_STAR, 2))), 2) AS replica_jain_index

from performance_schema.events_transactions_summary_by_thread_by_event_name as trx_summary join performance_schema.replication_applier_status_by_worker as applier

on trx_summary.THREAD_ID = applier.THREAD_ID

在 slave 上觀測，如果該指數(shù)值越接近 0 說明當(dāng)前 applier 線程越空閑率高，如果該指數(shù)值越接近 1 說明當(dāng)前 applier 線程空閑率越低。動(dòng)手試試吧！

參考：

總結(jié)

以上是生活随笔為你收集整理的mysql mts_技术分享 | 回顾 MySQL 的 MTS的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。