在談這個(gè)特性之前，我們先來(lái)看看mysql的復(fù)制架構(gòu)衍生史。 MySQL的復(fù)制分為三種： 第一種，即普通的replication。 搭建簡(jiǎn)單，使用非常廣泛，從mysql誕生之初，就產(chǎn)生了這種架構(gòu)，性能非常好，可謂非常成熟。 但是這種架構(gòu)數(shù)據(jù)是異步的，所以有丟失數(shù)據(jù)庫(kù)的風(fēng)險(xiǎn)。 第二種，即mysql cluster。 搭建也簡(jiǎn)單，本身也比較穩(wěn)定，是mysql里面對(duì)數(shù)據(jù)保護(hù)最最靠譜的架構(gòu)，也是唯一一個(gè)數(shù)據(jù)完全同步的架構(gòu)，絕對(duì)的零丟失。不過(guò)性能就差遠(yuǎn)些了。 第三種，即semi-sync replication，半同步，性能，功能都介于以上兩者之間。從mysql5.5開(kāi)始誕生，目的是為了折中上述兩種架構(gòu)的性能以及優(yōu)缺點(diǎn)。“我們今天談?wù)摰谌N架構(gòu)

我們知道，普通的replication，也即mysql的異步復(fù)制，依靠mysql二進(jìn)制日志也即binary log進(jìn)行數(shù)據(jù)復(fù)制。比如兩臺(tái)機(jī)器，一臺(tái)主機(jī)也即master，另外一臺(tái)是從機(jī)，也即slave。

1. 正常的復(fù)制為：事務(wù)一（t1）寫(xiě)入binlog buffer；dumper 線程通知slave有新的事務(wù)t1；binlog buffer 進(jìn)行checkpoint；slave的io線程接收到t1并寫(xiě)入到自己的的relay log；slave的sql線程寫(xiě)入到本地?cái)?shù)據(jù)庫(kù)。 這時(shí)，master和slave都能看到這條新的事務(wù)，即使master掛了，slave可以提升為新的master。 2. 異常的復(fù)制為：事務(wù)一（t1）寫(xiě)入binlog buffer；dumper 線程通知slave有新的事務(wù)t1；binlog buffer 進(jìn)行checkpoint；slave因?yàn)榫W(wǎng)絡(luò)不穩(wěn)定，一直沒(méi)有收到t1；master 掛掉，slave提升為新的master，t1丟失。

3. 很大的問(wèn)題是：主機(jī)和從機(jī)事務(wù)更新的不同步，就算是沒(méi)有網(wǎng)絡(luò)或者其他系統(tǒng)的異常，當(dāng)業(yè)務(wù)并發(fā)上來(lái)時(shí)，slave因?yàn)橐樞驁?zhí)行master批量事務(wù)，導(dǎo)致很大的延遲。

為了彌補(bǔ)以上幾種場(chǎng)景的不足，mysql從5.5開(kāi)始推出了半同步。

即在master的dumper線程通知slave后，增加了一個(gè)ack，即是否成功收到t1的標(biāo)志碼。也就是dumper線程除了發(fā)送t1到slave，還承擔(dān)了接收slave的ack工作。如果出現(xiàn)異常，沒(méi)有收到ack，那么將自動(dòng)降級(jí)為普通的復(fù)制，直到異常修復(fù)。

我們可以看到半同步帶來(lái)的新問(wèn)題： 1. 如果異常發(fā)生，會(huì)降級(jí)為普通的復(fù)制。 那么從機(jī)出現(xiàn)數(shù)據(jù)不一致的幾率會(huì)減少，并不是完全消失。 2. 主機(jī)dumper線程承擔(dān)的工作變多了，這樣顯然會(huì)降低整個(gè)數(shù)據(jù)庫(kù)的性能。 3. 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒(méi)有收到事務(wù)，也就是還沒(méi)有寫(xiě)入到relay log 之前，網(wǎng)絡(luò)出現(xiàn)異常或者不穩(wěn)定，此時(shí)剛好master掛了，系統(tǒng)切換到從機(jī)，兩邊的數(shù)據(jù)就會(huì)出現(xiàn)不一致。 在此情況下，slave會(huì)少一個(gè)事務(wù)的數(shù)據(jù)。

隨著MySQL 5.7版本的發(fā)布，半同步復(fù)制技術(shù)升級(jí)為全新的Loss-less Semi-Synchronous Replication架構(gòu)，其成熟度、數(shù)據(jù)一致性與執(zhí)行效率得到顯著的提升。

MySQL 5.7對(duì)數(shù)據(jù)復(fù)制效率進(jìn)行了改進(jìn)1 主從一致性加強(qiáng)支持在事務(wù)commit前等待ACK

新版本的semi sync 增加了rpl_semi_sync_master_wait_point參數(shù) 來(lái)控制半同步模式下 主庫(kù)在返回給會(huì)話事務(wù)成功之前提交事務(wù)的方式。

該參數(shù)有兩個(gè)值：

AFTER_COMMIT（5.6默認(rèn)值）

master將每個(gè)事務(wù)寫(xiě)入binlog ,傳遞到slave 刷新到磁盤(pán)(relay log)，同時(shí)主庫(kù)提交事務(wù)。master等待slave 反饋收到relay log，只有收到ACK后master才將commit OK結(jié)果反饋給客戶端。

AFTER_SYNC（5.7默認(rèn)值，但5.6中無(wú)此模式）

master 將每個(gè)事務(wù)寫(xiě)入binlog , 傳遞到slave 刷新到磁盤(pán)(relay log)。master等待slave 反饋接收到relay log的ack之后，再提交事務(wù)并且返回commit OK結(jié)果給客戶端。 即使主庫(kù)crash，所有在主庫(kù)上已經(jīng)提交的事務(wù)都能保證已經(jīng)同步到slave的relay log中。

因此5.7引入了after_sync模式，帶來(lái)的主要收益是解決after_commit導(dǎo)致的master crash主從間數(shù)據(jù)不一致問(wèn)題，因此在引入after_sync模式后，所有提交的數(shù)據(jù)已經(jīng)都被復(fù)制，故障切換時(shí)數(shù)據(jù)一致性將得到提升。

2 性能提升支持發(fā)送binlog和接受ack的異步化

舊版本的semi sync 受限于dump thread ，原因是dump thread 承擔(dān)了兩份不同且又十分頻繁的任務(wù)：傳送binlog 給slave ，還需要等待slave反饋信息，而且這兩個(gè)任務(wù)是串行的，dump thread 必須等待 slave 返回之后才會(huì)傳送下一個(gè) events 事務(wù)。dump thread 已然成為整個(gè)半同步提高性能的瓶頸。在高并發(fā)業(yè)務(wù)場(chǎng)景下，這樣的機(jī)制會(huì)影響數(shù)據(jù)庫(kù)整體的TPS .

圖：Without ACK receiving thread

為了解決上述問(wèn)題，在5.7版本的semi sync 框架中，獨(dú)立出一個(gè) ack collector thread ，專(zhuān)門(mén)用于接收slave 的反饋信息。這樣master 上有兩個(gè)線程獨(dú)立工作，可以同時(shí)發(fā)送binlog 到slave ，和接收slave的反饋。

圖：With ACK receiving thread3 性能提升控制主庫(kù)接收slave 寫(xiě)事務(wù)成功反饋數(shù)量

MySQL 5.7新增了rpl_semi_sync_master_wait_slave_count參數(shù)，可以用來(lái)控制主庫(kù)接受多少個(gè)slave寫(xiě)事務(wù)成功反饋，給高可用架構(gòu)切換提供了靈活性。

如圖所示，當(dāng)count值為2時(shí)，master需等待兩個(gè)slave的ack

4 性能提升

Binlog 互斥鎖改進(jìn)

舊版本半同步復(fù)制在主提交binlog的寫(xiě)會(huì)話和dump thread讀binlog的操作都會(huì)對(duì)binlog添加互斥鎖，導(dǎo)致binlog文件的讀寫(xiě)是串行化的，存在并發(fā)度的問(wèn)題。

MySQL 5.7對(duì)binlog lock進(jìn)行了以下兩方面優(yōu)化

1.移除了dump thread對(duì)binlog的互斥鎖

2.加入了安全邊際保證binlog的讀安全

5 性能提升組提交

5.7引入了新的變量slave-parallel-type，其可以配置的值有：

DATABASE （5.7之前默認(rèn)值），基于庫(kù)的并行復(fù)制方式；LOGICAL_CLOCK （5.7新增值），基于組提交的并行復(fù)制方式；

MySQL 5.6版本也支持所謂的并行復(fù)制，但是其并行只是基于DATABASE的，也就是基于庫(kù)的。如果用戶的MySQL數(shù)據(jù)庫(kù)實(shí)例中存在多個(gè)DATABASE ，對(duì)于從機(jī)復(fù)制的速度的確可以有比較大的幫助，如果用戶實(shí)例僅有一個(gè)庫(kù)，那么就無(wú)法實(shí)現(xiàn)并行回放，甚至性能會(huì)比原來(lái)的單線程更差。

MySQL5.7中增加了一種新的并行模式：為同時(shí)進(jìn)入COMMIT階段的事務(wù)分配相同的序列號(hào)，這些擁有相同序列號(hào)的事務(wù)在備庫(kù)是可以并發(fā)執(zhí)行的。

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

因此下面的序列中可以并發(fā)的序列為（其中前面一個(gè)數(shù)字為last_committed ，后面一個(gè)數(shù)字為sequence_number ）：

trx1 1…..2trx2 1………….3trx3 1…………………….4trx4 2……………………….5trx5 3…………………………..6trx6 3………………………………7trx7 6………………………………..8

備庫(kù)并行規(guī)則：當(dāng)分發(fā)一個(gè)事務(wù)時(shí)，其last_committed 序列號(hào)比當(dāng)前正在執(zhí)行的事務(wù)的最小sequence_number要小時(shí)，則允許執(zhí)行。

因此，

a)trx1執(zhí)行，last_commit<2的可并發(fā)，trx2, trx3可繼續(xù)分發(fā)執(zhí)行

b)trx1執(zhí)行完成后，last_commit < 3的可以執(zhí)行， trx4可分發(fā)

c)trx2執(zhí)行完成后，last_commit < 4的可以執(zhí)行， trx5, trx6可分發(fā)

d)trx3、trx4、trx5完成后，last_commit < 7的可以執(zhí)行，trx7可分發(fā)

綜上所述

我們認(rèn)為MySQL 5.7版對(duì)Loss-Less半同步復(fù)制技術(shù)的優(yōu)化，使得其成熟度和執(zhí)行效率都得到了質(zhì)的提高。我們建議在使用MySQL 5.7作為生產(chǎn)環(huán)境的部署時(shí)，可以使用半同步技術(shù)作為高可用與讀寫(xiě)分離方案的數(shù)據(jù)復(fù)制方案。