復(fù)制架構(gòu)衍生史

?

在談這個(gè)特性之前，我們先來看看MySQL的復(fù)制架構(gòu)衍生史。 MySQL的復(fù)制分為四種：

普通的replication，異步同步。 搭建簡單，使用非常廣泛，從mysql誕生之初，就產(chǎn)生了這種架構(gòu)，性能非常好，可謂非常成熟。 但是這種架構(gòu)數(shù)據(jù)是異步的，所以有丟失數(shù)據(jù)庫的風(fēng)險(xiǎn)。

semi-sync replication，半同步。性能，功能都介于異步和全同步中間。從mysql5.5開始誕生，目的是為了折中上述兩種架構(gòu)的性能以及優(yōu)缺點(diǎn)。

sync replication，全同步。目前官方5.7基于Group replication的全同步技術(shù)處在labs版本，離正式集成已經(jīng)不遠(yuǎn)。全同步技術(shù)帶來了更多的數(shù)據(jù)一致性保障。相信是未來同步技術(shù)一個(gè)重要方向，值得期待。

mysql cluster。 基于NDB引擎，搭建也簡單，本身也比較穩(wěn)定，是mysql里面對(duì)數(shù)據(jù)保護(hù)最靠譜的架構(gòu)，也是目前唯一一個(gè)數(shù)據(jù)完全同步的架構(gòu)，數(shù)據(jù)零丟失。不過對(duì)業(yè)務(wù)比較挑剔，限制也較多。

半同步復(fù)制

我們今天談?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)。

正常的復(fù)制為：事務(wù)一（t1）寫入binlog buffer；dumper 線程通知slave有新的事務(wù)t1；binlog buffer 進(jìn)行checkpoint；slave的io線程接收到t1并寫入到自己的的relay log；slave的sql線程寫入到本地?cái)?shù)據(jù)庫。 這時(shí)，master和slave都能看到這條新的事務(wù)，即使master掛了，slave可以提升為新的master。

異常的復(fù)制為：事務(wù)一（t1）寫入binlog buffer；dumper 線程通知slave有新的事務(wù)t1；binlog buffer 進(jìn)行checkpoint；slave因?yàn)榫W(wǎng)絡(luò)不穩(wěn)定，一直沒有收到t1；master 掛掉，slave提升為新的master，t1丟失。

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

為了彌補(bǔ)以上幾種場(chǎng)景的不足，mysql從5.5開始推出了半同步。即在master的dumper線程通知slave后，增加了一個(gè)ack，即是否成功收到t1的標(biāo)志碼。也就是dumper線程除了發(fā)送t1到slave，還承擔(dān)了接收slave的ack工作。如果出現(xiàn)異常，沒有收到ack，那么將自動(dòng)降級(jí)為普通的復(fù)制，直到異常修復(fù)。

（加：）半同步復(fù)制模式可以確保從服務(wù)器接收完主服務(wù)器發(fā)送的binlog日志文件并寫入自己的中繼日志relay log里，然后會(huì)給主服務(wù)器一個(gè)反饋，告訴對(duì)方已經(jīng)接收完畢，這時(shí)主庫線程才返回給當(dāng)前session告知操作完成。當(dāng)出現(xiàn)超時(shí)情況時(shí)，源主服務(wù)器會(huì)暫時(shí)切換到異步復(fù)制模式，直到至少有一臺(tái)設(shè)置為半同步復(fù)制模式的從服務(wù)器及時(shí)收到信息為止。

我們可以看到半同步帶來的新問題：

如果異常發(fā)生，會(huì)降級(jí)為普通的復(fù)制。 那么從機(jī)出現(xiàn)數(shù)據(jù)不一致的幾率會(huì)減少，并不是完全消失。

主機(jī)dumper線程承擔(dān)的工作變多了，這樣顯然會(huì)降低整個(gè)數(shù)據(jù)庫的性能。

在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒有收到事務(wù)，也就是還沒有寫入到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數(shù)據(jù)復(fù)制效率的改進(jìn)

主從一致性加強(qiáng), 支持在事務(wù)commit前等待ACK

(mysql5.5版本的半同步復(fù)制與5.7的區(qū)別是commit后等待ACK)

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

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

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

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

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

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

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

性能提升, 支持發(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ù)庫整體的TPS 。

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

性能提升, 控制主庫接收slave 寫事務(wù)成功反饋數(shù)量

MySQL 5.7 新增了rpl_semi_sync_master_wait_slave_count參數(shù)，可以用來控制主庫接受多少個(gè)slave寫事務(wù)成功反饋，給高可用架構(gòu)切換提供了靈活性。
如圖所示，當(dāng)count值為2時(shí)，master需等待兩個(gè)slave的ack。

性能提升, Binlog 互斥鎖改進(jìn)

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

MySQL 5.7 對(duì)binlog lock進(jìn)行了以下兩方面優(yōu)化:
1. 移除了dump thread對(duì)binlog的互斥鎖
2. 加入了安全邊際保證binlog的讀安全

性能提升, 組提交

MySQL 5.7 引入了新的變量slave-parallel-type，其可以配置的值有：
1. DATABASE （5.7之前默認(rèn)值），基于庫的并行復(fù)制方式；
2. LOGICAL_CLOCK （5.7新增值），基于組提交的并行復(fù)制方式；

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

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

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

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

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

備庫并行規(guī)則：當(dāng)分發(fā)一個(gè)事務(wù)時(shí)，其last_committed 序列號(hào)比當(dāng)前正在執(zhí)行的事務(wù)的最小sequence_number要小時(shí)，則允許執(zhí)行。因此:
1. trx1執(zhí)行，last_commit<2的可并發(fā)，trx2, trx3可繼續(xù)分發(fā)執(zhí)行
2. trx1執(zhí)行完成后，last_commit < 3的可以執(zhí)行， trx4可分發(fā)
3. trx2執(zhí)行完成后，last_commit < 4的可以執(zhí)行， trx5, trx6可分發(fā)
4. trx3、trx4、trx5完成后，last_commit < 7的可以執(zhí)行，trx7可分發(fā)

綜述

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

?

參考資料：http://www.actionsky.com/docs/archives/129

?

總結(jié)

以上是生活随笔為你收集整理的MySQL 5.7 深度解析: 半同步复制技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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