復制架構衍生史

?

在談這個特性之前，我們先來看看MySQL的復制架構衍生史。 MySQL的復制分為四種：

普通的replication，異步同步。 搭建簡單，使用非常廣泛，從mysql誕生之初，就產生了這種架構，性能非常好，可謂非常成熟。 但是這種架構數據是異步的，所以有丟失數據庫的風險。

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

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

mysql cluster。 基于NDB引擎，搭建也簡單，本身也比較穩定，是mysql里面對數據保護最靠譜的架構，也是目前唯一一個數據完全同步的架構，數據零丟失。不過對業務比較挑剔，限制也較多。

半同步復制

我們今天談論第二種架構。我們知道，普通的replication，即mysql的異步復制，依靠mysql二進制日志也即binary log進行數據復制。比如兩臺機器，一臺主機(master)，另外一臺是從機(slave)。

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

異常的復制為：事務一（t1）寫入binlog buffer；dumper 線程通知slave有新的事務t1；binlog buffer 進行checkpoint；slave因為網絡不穩定，一直沒有收到t1；master 掛掉，slave提升為新的master，t1丟失。

很大的問題是：主機和從機事務更新的不同步，就算是沒有網絡或者其他系統的異常，當業務并發上來時，slave因為要順序執行master批量事務，導致很大的延遲。

為了彌補以上幾種場景的不足，mysql從5.5開始推出了半同步。即在master的dumper線程通知slave后，增加了一個ack，即是否成功收到t1的標志碼。也就是dumper線程除了發送t1到slave，還承擔了接收slave的ack工作。如果出現異常，沒有收到ack，那么將自動降級為普通的復制，直到異常修復。

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

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

如果異常發生，會降級為普通的復制。 那么從機出現數據不一致的幾率會減少，并不是完全消失。

主機dumper線程承擔的工作變多了，這樣顯然會降低整個數據庫的性能。

在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒有收到事務，也就是還沒有寫入到relay log 之前，網絡出現異常或者不穩定，此時剛好master掛了，系統切換到從機，兩邊的數據就會出現不一致。 在此情況下，slave會少一個事務的數據。

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

MySQL 5.7數據復制效率的改進

主從一致性加強, 支持在事務commit前等待ACK

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

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

該參數有兩個值：

AFTER_COMMIT（5.6默認值）

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

AFTER_SYNC（5.7默認值，但5.6中無此模式）

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

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

性能提升, 支持發送binlog和接受ack的異步化

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

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

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

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

性能提升, Binlog 互斥鎖改進

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

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

性能提升, 組提交

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

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

MySQL5.7中增加了一種新的并行模式：為同時進入COMMIT階段的事務分配相同的序列號，這些擁有相同序列號的事務在備庫是可以并發執行的。

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

因此下面的序列中可以并發的序列為（其中前面一個數字為last_committed ，后面一個數字為sequence_number ）：

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

備庫并行規則：當分發一個事務時，其last_committed 序列號比當前正在執行的事務的最小sequence_number要小時，則允許執行。因此:
1. trx1執行，last_commit<2的可并發，trx2, trx3可繼續分發執行
2. trx1執行完成后，last_commit < 3的可以執行， trx4可分發
3. trx2執行完成后，last_commit < 4的可以執行， trx5, trx6可分發
4. trx3、trx4、trx5完成后，last_commit < 7的可以執行，trx7可分發

綜述

我們認為MySQL 5.7版對半同步復制技術的優化，使得其成熟度和執行效率都得到了質的提高。我們建議在使用MySQL 5.7作為生產環境的部署時，可以使用半同步技術作為高可用與讀寫分離方案的數據復制方案。

?

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

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。