MySQL 5.7并行復(fù)制時(shí)代

眾所周知，MySQL的復(fù)制延遲是一直被詬病的問(wèn)題之一，然而在Inside君之前的兩篇博客中（1，2）中都已經(jīng)提到了MySQL 5.7版本已經(jīng)支持“真正”的并行復(fù)制功能，官方稱(chēng)為為enhanced multi-threaded slave（簡(jiǎn)稱(chēng)MTS），因此復(fù)制延遲問(wèn)題已經(jīng)得到了極大的改進(jìn)，甚至在Inside君所在的網(wǎng)易電商應(yīng)用中已經(jīng)完全消除了之前延遲長(zhǎng)達(dá)幾小時(shí)的問(wèn)題。然而，Inside君發(fā)現(xiàn)還是有很多小伙伴并不了解這個(gè)足以載入史冊(cè)的“偉大”的特性，故作分享。總之，5.7版本后，復(fù)制延遲問(wèn)題永不存在。

MySQL 5.6并行復(fù)制架構(gòu)

誠(chéng)然，MySQL 5.6版本也支持所謂的并行復(fù)制，但是其并行只是基于schema的，也就是基于庫(kù)的。如果用戶(hù)的MySQL數(shù)據(jù)庫(kù)實(shí)例中存在多個(gè)schema，對(duì)于從機(jī)復(fù)制的速度的確可以有比較大的幫助。MySQL 5.6并行復(fù)制的架構(gòu)如下所示：

在上圖的紅色框框部分就是實(shí)現(xiàn)并行復(fù)制的關(guān)鍵所在。在MySQL 5.6版本之前，Slave服務(wù)器上有兩個(gè)線(xiàn)程I/O線(xiàn)程和SQL線(xiàn)程。I/O線(xiàn)程負(fù)責(zé)接收二進(jìn)制日志（更準(zhǔn)確的說(shuō)是二進(jìn)制日志的event），SQL線(xiàn)程進(jìn)行回放二進(jìn)制日志。如果在MySQL 5.6版本開(kāi)啟并行復(fù)制功能，那么SQL線(xiàn)程就變?yōu)榱薱oordinator線(xiàn)程，coordinator線(xiàn)程主要負(fù)責(zé)以前兩部分的內(nèi)容：

若判斷可以并行執(zhí)行，那么選擇worker線(xiàn)程執(zhí)行事務(wù)的二進(jìn)制日志

若判斷不可以并行執(zhí)行，如該操作是DDL，亦或者是事務(wù)跨schema操作，則等待所有的worker線(xiàn)程執(zhí)行完成之后，再執(zhí)行當(dāng)前的日志 這意味著coordinator線(xiàn)程并不是僅將日志發(fā)送給worker線(xiàn)程，自己也可以回放日志，但是所有可以并行的操作交付由worker線(xiàn)程完成。coordinator線(xiàn)程與worker是典型的生產(chǎn)者與消費(fèi)者模型。

上述機(jī)制實(shí)現(xiàn)了基于schema的并行復(fù)制存在兩個(gè)問(wèn)題，首先是crash safe功能不好做，因?yàn)榭赡苤髨?zhí)行的事務(wù)由于并行復(fù)制的關(guān)系先完成執(zhí)行，那么當(dāng)發(fā)生crash的時(shí)候，這部分的處理邏輯是比較復(fù)雜的。從代碼上看，5.6這里引入了Low-Water-Mark標(biāo)記來(lái)解決該問(wèn)題，從設(shè)計(jì)上看（WL#5569），其是希望借助于日志的冪等性來(lái)解決該問(wèn)題，不過(guò)5.6的二進(jìn)制日志回放還不能實(shí)現(xiàn)冪等性。另一個(gè)最為關(guān)鍵的問(wèn)題是這樣設(shè)計(jì)的并行復(fù)制效果并不高，如果用戶(hù)實(shí)例僅有一個(gè)庫(kù)，那么就無(wú)法實(shí)現(xiàn)并行回放，甚至性能會(huì)比原來(lái)的單線(xiàn)程更差。而單庫(kù)多表是比多庫(kù)多表更為常見(jiàn)的一種情形。

MySQL 5.7并行復(fù)制原理

MySQL 5.7基于組提交的并行復(fù)制

MySQL 5.7才可稱(chēng)為真正的并行復(fù)制，這其中最為主要的原因就是slave服務(wù)器的回放與主機(jī)是一致的即master服務(wù)器上是怎么并行執(zhí)行的slave上就怎樣進(jìn)行并行回放。不再有庫(kù)的并行復(fù)制限制，對(duì)于二進(jìn)制日志格式也無(wú)特殊的要求（基于庫(kù)的并行復(fù)制也沒(méi)有要求）。

從MySQL官方來(lái)看，其并行復(fù)制的原本計(jì)劃是支持表級(jí)的并行復(fù)制和行級(jí)的并行復(fù)制，行級(jí)的并行復(fù)制通過(guò)解析ROW格式的二進(jìn)制日志的方式來(lái)完成，WL#4648。但是最終出現(xiàn)給小伙伴的確是在開(kāi)發(fā)計(jì)劃中稱(chēng)為：MTS: Prepared transactions slave parallel applier，可見(jiàn)：WL#6314。該并行復(fù)制的思想最早是由MariaDB的Kristain提出，并已在MariaDB 10中出現(xiàn)，相信很多選擇MariaDB的小伙伴最為看重的功能之一就是并行復(fù)制。

MySQL 5.7并行復(fù)制的思想簡(jiǎn)單易懂，一言以蔽之：一個(gè)組提交的事務(wù)都是可以并行回放，因?yàn)檫@些事務(wù)都已進(jìn)入到事務(wù)的prepare階段，則說(shuō)明事務(wù)之間沒(méi)有任何沖突（否則就不可能提交）。

為了兼容MySQL 5.6基于庫(kù)的并行復(fù)制，5.7引入了新的變量slave-parallel-type，其可以配置的值有：

DATABASE：默認(rèn)值，基于庫(kù)的并行復(fù)制方式

LOGICAL_CLOCK：基于組提交的并行復(fù)制方式

支持并行復(fù)制的GTID

如何知道事務(wù)是否在一組中，又是一個(gè)問(wèn)題，因?yàn)樵娴腗ySQL并沒(méi)有提供這樣的信息。在MySQL 5.7版本中，其設(shè)計(jì)方式是將組提交的信息存放在GTID中。那么如果用戶(hù)沒(méi)有開(kāi)啟GTID功能，即將參數(shù)gtid_mode設(shè)置為OFF呢？故MySQL 5.7又引入了稱(chēng)之為Anonymous_Gtid的二進(jìn)制日志event類(lèi)型，如：

mysql>SHOWBINLOGEVENTSin'mysql-bin.000006';
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------+
|Log_name|Pos|Event_type|Server_id|End_log_pos|Info|
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------+
|mysql-bin.000006|4|Format_desc|88|123|Serverver:5.7.7-rc-debug-log,Binlogver:4|
|mysql-bin.000006|123|Previous_gtids|88|194|f11232f7-ff07-11e4-8fbb-00ff55e152c6:1-2|
|mysql-bin.000006|194|Anonymous_Gtid|88|259|SET@@SESSION.GTID_NEXT='ANONYMOUS'|
|mysql-bin.000006|259|Query|88|330|BEGIN|
|mysql-bin.000006|330|Table_map|88|373|table_id:108(aaa.t)|
|mysql-bin.000006|373|Write_rows|88|413|table_id:108flags:STMT_END_F|
.....

這意味著在MySQL 5.7版本中即使不開(kāi)啟GTID，每個(gè)事務(wù)開(kāi)始前也是會(huì)存在一個(gè)Anonymous_Gtid，而這GTID中就存在著組提交的信息。

LOGICAL_CLOCK

然而，通過(guò)上述的SHOW BINLOG EVENTS，我們并沒(méi)有發(fā)現(xiàn)有關(guān)組提交的任何信息。但是通過(guò)mysqlbinlog工具，用戶(hù)就能發(fā)現(xiàn)組提交的內(nèi)部信息：

root@localhost:~#mysqlbinlogmysql-bin.0000006|greplast_committed
#1505201411serverid88end_log_pos259CRC320x4ead9ad6GTIDlast_committed=0sequence_number=1
#1505201411serverid88end_log_pos1483CRC320xdf94bc85GTIDlast_committed=0sequence_number=2
#1505201411serverid88end_log_pos2708CRC320x0914697bGTIDlast_committed=0sequence_number=3
#1505201411serverid88end_log_pos3934CRC320xd9cb4a43GTIDlast_committed=0sequence_number=4
#1505201411serverid88end_log_pos5159CRC320x06a6f531GTIDlast_committed=0sequence_number=5
#1505201411serverid88end_log_pos6386CRC320xd6cae930GTIDlast_committed=0sequence_number=6
#1505201411serverid88end_log_pos7610CRC320xa1ea531cGTIDlast_committed=6sequence_number=7
...

可以發(fā)現(xiàn)較之原來(lái)的二進(jìn)制日志內(nèi)容多了last_committed和sequence_number，last_committed表示事務(wù)提交的時(shí)候，上次事務(wù)提交的編號(hào)，如果事務(wù)具有相同的last_committed，表示這些事務(wù)都在一組內(nèi)，可以進(jìn)行并行的回放。例如上述last_committed為0的事務(wù)有6個(gè)，表示組提交時(shí)提交了6個(gè)事務(wù)，而這6個(gè)事務(wù)在從機(jī)是可以進(jìn)行并行回放的。

上述的last_committed和sequence_number代表的就是所謂的LOGICAL_CLOCK。先來(lái)看源碼中對(duì)于LOGICAL_CLOCK的定義：

classLogical_clock
{
private:
int64state;
/*
Offsetissubtractedfromtheactual"absolutetime"valueat
loggingareplicationevent.Thatistheeventholdslogical
timestampsinthe"relative"format.Theyaremeaningfulonlyin
thecontextofthecurrentbinlog.
Thememberisupdated(incremented)perbinarylogrotation.
*/
int64offset;
......

state是一個(gè)自增的值，offset在每次二進(jìn)制日志發(fā)生rotate時(shí)更新，記錄發(fā)生rotate時(shí)的state值。其實(shí)state和offset記錄的是全局的計(jì)數(shù)值，而存在二進(jìn)制日志中的僅是當(dāng)前文件的相對(duì)值。使用LOGICAL_CLOCK的場(chǎng)景如下：

classMYSQL_BIN_LOG:publicTC_LOG
{
...
public:
/*Committedtransactionstimestamp*/
Logical_clockmax_committed_transaction;
/*"Prepared"transactionstimestamp*/
Logical_clocktransaction_counter;
...

可以看到在類(lèi)MYSQL_BIN_LOG中定義了兩個(gè)Logical_clock的變量：

max_c ommitted_transaction：記錄上次組提交時(shí)的logical_clock，代表上述mysqlbinlog中的last_committed

transaction_counter：記錄當(dāng)前組提交中各事務(wù)的logcial_clock，代表上述mysqlbinlog中的sequence_number

并行復(fù)制測(cè)試

下圖顯示了開(kāi)啟MTS后，slave服務(wù)器的QPS。測(cè)試的工具是sysbench的單表全update測(cè)試，測(cè)試結(jié)果顯示在16個(gè)線(xiàn)程下的性能最好，從機(jī)的QPS可以達(dá)到25000以上，進(jìn)一步增加并行執(zhí)行的線(xiàn)程至32并沒(méi)有帶來(lái)更高的提升。而原單線(xiàn)程回放的QPS僅在4000左右，可見(jiàn)MySQL 5.7 MTS帶來(lái)的性能提升，而由于測(cè)試的是單表，所以MySQL 5.6的MTS機(jī)制則完全無(wú)能為力了。

并行復(fù)制配置與調(diào)優(yōu)

master_info_repository

開(kāi)啟MTS功能后，務(wù)必將參數(shù)master_info_repostitory設(shè)置為T(mén)ABLE，這樣性能可以有50%~80%的提升。這是因?yàn)椴⑿袕?fù)制開(kāi)啟后對(duì)于元master.info這個(gè)文件的更新將會(huì)大幅提升，資源的競(jìng)爭(zhēng)也會(huì)變大。在之前InnoSQL的版本中，添加了參數(shù)來(lái)控制刷新master.info這個(gè)文件的頻率，甚至可以不刷新這個(gè)文件。因?yàn)樗⑿逻@個(gè)文件是沒(méi)有必要的，即根據(jù)master-info.log這個(gè)文件恢復(fù)本身就是不可靠的。在MySQL 5.7中，Inside君推薦將master_info_repository設(shè)置為T(mén)ABLE，來(lái)減小這部分的開(kāi)銷(xiāo)。

slave_parallel_workers

若將slave_parallel_workers設(shè)置為0，則MySQL 5.7退化為原單線(xiàn)程復(fù)制，但將slave_parallel_workers設(shè)置為1，則SQL線(xiàn)程功能轉(zhuǎn)化為coordinator線(xiàn)程，但是只有1個(gè)worker線(xiàn)程進(jìn)行回放，也是單線(xiàn)程復(fù)制。然而，這兩種性能卻又有一些的區(qū)別，因?yàn)槎嗔艘淮蝐oordinator線(xiàn)程的轉(zhuǎn)發(fā)，因此slave_parallel_workers=1的性能反而比0還要差，在Inside君的測(cè)試下還有20%左右的性能下降，如下圖所示：

這里其中引入了另一個(gè)問(wèn)題，如果主機(jī)上的負(fù)載不大，那么組提交的效率就不高，很有可能發(fā)生每組提交的事務(wù)數(shù)量?jī)H有1個(gè)，那么在從機(jī)的回放時(shí)，雖然開(kāi)啟了并行復(fù)制，但會(huì)出現(xiàn)性能反而比原先的單線(xiàn)程還要差的現(xiàn)象，即延遲反而增大了。聰明的小伙伴們，有想過(guò)對(duì)這個(gè)進(jìn)行優(yōu)化嗎？

Enhanced Multi-Threaded Slave配置

說(shuō)了這么多，要開(kāi)啟enhanced multi-threaded slave其實(shí)很簡(jiǎn)單，只需根據(jù)如下設(shè)置：

#slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

并行復(fù)制監(jiān)控 復(fù)制的監(jiān)控依舊可以通過(guò)SHOW SLAVE STATUSG，但是MySQL 5.7在performance_schema架構(gòu)下多了以下這些元數(shù)據(jù)表，用戶(hù)可以更細(xì)力度的進(jìn)行監(jiān)控：

mysql>showtableslike'replication%';
+---------------------------------------------+
|Tables_in_performance_schema(replication%)|
+---------------------------------------------+
|replication_applier_configuration|
|replication_applier_status|
|replication_applier_status_by_coordinator|
|replication_applier_status_by_worker|
|replication_connection_configuration|
|replication_connection_status|
|replication_group_member_stats|
|replication_group_members|
+---------------------------------------------+
8rowsinset(0.00sec)

總結(jié)

MySQL 5.7推出的Enhanced Multi-Threaded Slave解決了困擾MySQL長(zhǎng)達(dá)數(shù)十年的復(fù)制延遲問(wèn)題，再次提醒一些無(wú)知的PostgreSQL用戶(hù)，不要停留在之前對(duì)于MySQL的印象，物理復(fù)制也不一定肯定比邏輯復(fù)制有優(yōu)勢(shì)，而MySQL 5.7的MTS已經(jīng)完全可以解決延遲問(wèn)題了。

審核編輯：湯梓紅