在談這個特性之前，我們先來看看mysql的複製架構衍生史。 MySQL的複製分為三種： 第一種，即普通的replication。 搭建簡單，使用非常廣泛，從mysql誕生之初，就產生了這種架構，效能非常好，可謂非常成熟。 但是這種架構資料是非同步的，所以有丟失資料庫的風險。 第二種，即mysql cluster。 搭建也簡單，本身也比較穩定，是mysql裡面對資料保護最最靠譜的架構，也是唯一一個數據完全同步的架構，絕對的零丟失。不過效能就差遠些了。 第三種，即semi-sync replication，半同步，效能，功能都介於以上兩者之間。從mysql5.5開始誕生，目的是為了折中上述兩種架構的效能以及優缺點。“我們今天談論第三種架構
我們知道，普通的replication，也即mysql的非同步複製，依靠mysql二進位制日誌也即binary log進行資料複製。比如兩臺機器，一臺主機也即master，另外一臺是從機，也即slave。
1. 正常的複製為：事務一（t1）寫入binlog buffer；dumper 執行緒通知slave有新的事務t1；binlog buffer 進行checkpoint；slave的io執行緒接收到t1並寫入到自己的的relay log；slave的sql執行緒寫入到本地資料庫。 這時，master和slave都能看到這條新的事務，即使master掛了，slave可以提升為新的master。 2. 異常的複製為：事務一（t1）寫入binlog buffer；dumper 執行緒通知slave有新的事務t1；binlog buffer 進行checkpoint；slave因為網路不穩定，一直沒有收到t1；master 掛掉，slave提升為新的master，t1丟失。
3. 很大的問題是：主機和從機事務更新的不同步，就算是沒有網路或者其他系統的異常，當業務併發上來時，slave因為要順序執行master批次事務，導致很大的延遲。
為了彌補以上幾種場景的不足，mysql從5.5開始推出了半同步。
即在master的dumper執行緒通知slave後，增加了一個ack，即是否成功收到t1的標誌碼。也就是dumper執行緒除了傳送t1到slave，還承擔了接收slave的ack工作。如果出現異常，沒有收到ack，那麼將自動降級為普通的複製，直到異常修復。
我們可以看到半同步帶來的新問題： 1. 如果異常發生，會降級為普通的複製。 那麼從機出現數據不一致的機率會減少，並不是完全消失。 2. 主機dumper執行緒承擔的工作變多了，這樣顯然會降低整個資料庫的效能。 3. 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒有收到事務，也就是還沒有寫入到relay log 之前，網路出現異常或者不穩定，此時剛好master掛了，系統切換到從機，兩邊的資料就會出現不一致。 在此情況下，slave會少一個事務的資料。
隨著MySQL 5.7版本的釋出，半同步複製技術升級為全新的Loss-less Semi-Synchronous Replication架構，其成熟度、資料一致性與執行效率得到顯著的提升。
MySQL 5.7對資料複製效率進行了改進1 主從一致性加強支援在事務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模式後，所有提交的資料已經都被複制，故障切換時資料一致性將得到提升。
2 效能提升支援傳送binlog和接受ack的非同步化
舊版本的semi sync 受限於dump thread ，原因是dump thread 承擔了兩份不同且又十分頻繁的任務：傳送binlog 給slave ，還需要等待slave反饋資訊，而且這兩個任務是序列的，dump thread 必須等待 slave 返回之後才會傳送下一個 events 事務。dump thread 已然成為整個半同步提高效能的瓶頸。在高併發業務場景下，這樣的機制會影響資料庫整體的TPS .
圖：Without ACK receiving thread
為了解決上述問題，在5.7版本的semi sync 框架中，獨立出一個 ack collector thread ，專門用於接收slave 的反饋資訊。這樣master 上有兩個執行緒獨立工作，可以同時傳送binlog 到slave ，和接收slave的反饋。
圖：With ACK receiving thread3 效能提升控制主庫接收slave 寫事務成功反饋數量
MySQL 5.7新增了rpl_semi_sync_master_wait_slave_count引數，可以用來控制主庫接受多少個slave寫事務成功反饋，給高可用架構切換提供了靈活性。
如圖所示，當count值為2時，master需等待兩個slave的ack
4 效能提升
Binlog 互斥鎖改進
舊版本半同步複製在主提交binlog的寫會話和dump thread讀binlog的操作都會對binlog新增互斥鎖，導致binlog檔案的讀寫是序列化的，存在併發度的問題。
MySQL 5.7對binlog lock進行了以下兩方面最佳化
1.移除了dump thread對binlog的互斥鎖
2.加入了安全邊際保證binlog的讀安全
5 效能提升組提交
5.7引入了新的變數slave-parallel-type，其可以配置的值有：
DATABASE （5.7之前預設值），基於庫的並行複製方式；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…..2trx2 1………….3trx3 1…………………….4trx4 2……………………….5trx5 3…………………………..6trx6 3………………………………7trx7 6………………………………..8
備庫並行規則：當分發一個事務時，其last_committed 序列號比當前正在執行的事務的最小sequence_number要小時，則允許執行。
因此，
a)trx1執行，last_commit<2的可併發，trx2, trx3可繼續分發執行
b)trx1執行完成後，last_commit < 3的可以執行， trx4可分發
c)trx2執行完成後，last_commit < 4的可以執行， trx5, trx6可分發
d)trx3、trx4、trx5完成後，last_commit < 7的可以執行，trx7可分發
綜上所述
我們認為MySQL 5.7版對Loss-Less半同步複製技術的最佳化，使得其成熟度和執行效率都得到了質的提高。我們建議在使用MySQL 5.7作為生產環境的部署時，可以使用半同步技術作為高可用與讀寫分離方案的資料複製方案。
在談這個特性之前，我們先來看看mysql的複製架構衍生史。 MySQL的複製分為三種： 第一種，即普通的replication。 搭建簡單，使用非常廣泛，從mysql誕生之初，就產生了這種架構，效能非常好，可謂非常成熟。 但是這種架構資料是非同步的，所以有丟失資料庫的風險。 第二種，即mysql cluster。 搭建也簡單，本身也比較穩定，是mysql裡面對資料保護最最靠譜的架構，也是唯一一個數據完全同步的架構，絕對的零丟失。不過效能就差遠些了。 第三種，即semi-sync replication，半同步，效能，功能都介於以上兩者之間。從mysql5.5開始誕生，目的是為了折中上述兩種架構的效能以及優缺點。“我們今天談論第三種架構
我們知道，普通的replication，也即mysql的非同步複製，依靠mysql二進位制日誌也即binary log進行資料複製。比如兩臺機器，一臺主機也即master，另外一臺是從機，也即slave。
1. 正常的複製為：事務一（t1）寫入binlog buffer；dumper 執行緒通知slave有新的事務t1；binlog buffer 進行checkpoint；slave的io執行緒接收到t1並寫入到自己的的relay log；slave的sql執行緒寫入到本地資料庫。 這時，master和slave都能看到這條新的事務，即使master掛了，slave可以提升為新的master。 2. 異常的複製為：事務一（t1）寫入binlog buffer；dumper 執行緒通知slave有新的事務t1；binlog buffer 進行checkpoint；slave因為網路不穩定，一直沒有收到t1；master 掛掉，slave提升為新的master，t1丟失。
3. 很大的問題是：主機和從機事務更新的不同步，就算是沒有網路或者其他系統的異常，當業務併發上來時，slave因為要順序執行master批次事務，導致很大的延遲。
為了彌補以上幾種場景的不足，mysql從5.5開始推出了半同步。
即在master的dumper執行緒通知slave後，增加了一個ack，即是否成功收到t1的標誌碼。也就是dumper執行緒除了傳送t1到slave，還承擔了接收slave的ack工作。如果出現異常，沒有收到ack，那麼將自動降級為普通的複製，直到異常修復。
我們可以看到半同步帶來的新問題： 1. 如果異常發生，會降級為普通的複製。 那麼從機出現數據不一致的機率會減少，並不是完全消失。 2. 主機dumper執行緒承擔的工作變多了，這樣顯然會降低整個資料庫的效能。 3. 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒有收到事務，也就是還沒有寫入到relay log 之前，網路出現異常或者不穩定，此時剛好master掛了，系統切換到從機，兩邊的資料就會出現不一致。 在此情況下，slave會少一個事務的資料。
隨著MySQL 5.7版本的釋出，半同步複製技術升級為全新的Loss-less Semi-Synchronous Replication架構，其成熟度、資料一致性與執行效率得到顯著的提升。
MySQL 5.7對資料複製效率進行了改進1 主從一致性加強支援在事務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模式後，所有提交的資料已經都被複制，故障切換時資料一致性將得到提升。
2 效能提升支援傳送binlog和接受ack的非同步化
舊版本的semi sync 受限於dump thread ，原因是dump thread 承擔了兩份不同且又十分頻繁的任務：傳送binlog 給slave ，還需要等待slave反饋資訊，而且這兩個任務是序列的，dump thread 必須等待 slave 返回之後才會傳送下一個 events 事務。dump thread 已然成為整個半同步提高效能的瓶頸。在高併發業務場景下，這樣的機制會影響資料庫整體的TPS .
圖：Without ACK receiving thread
為了解決上述問題，在5.7版本的semi sync 框架中，獨立出一個 ack collector thread ，專門用於接收slave 的反饋資訊。這樣master 上有兩個執行緒獨立工作，可以同時傳送binlog 到slave ，和接收slave的反饋。
圖：With ACK receiving thread3 效能提升控制主庫接收slave 寫事務成功反饋數量
MySQL 5.7新增了rpl_semi_sync_master_wait_slave_count引數，可以用來控制主庫接受多少個slave寫事務成功反饋，給高可用架構切換提供了靈活性。
如圖所示，當count值為2時，master需等待兩個slave的ack
4 效能提升
Binlog 互斥鎖改進
舊版本半同步複製在主提交binlog的寫會話和dump thread讀binlog的操作都會對binlog新增互斥鎖，導致binlog檔案的讀寫是序列化的，存在併發度的問題。
MySQL 5.7對binlog lock進行了以下兩方面最佳化
1.移除了dump thread對binlog的互斥鎖
2.加入了安全邊際保證binlog的讀安全
5 效能提升組提交
5.7引入了新的變數slave-parallel-type，其可以配置的值有：
DATABASE （5.7之前預設值），基於庫的並行複製方式；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…..2trx2 1………….3trx3 1…………………….4trx4 2……………………….5trx5 3…………………………..6trx6 3………………………………7trx7 6………………………………..8
備庫並行規則：當分發一個事務時，其last_committed 序列號比當前正在執行的事務的最小sequence_number要小時，則允許執行。
因此，
a)trx1執行，last_commit<2的可併發，trx2, trx3可繼續分發執行
b)trx1執行完成後，last_commit < 3的可以執行， trx4可分發
c)trx2執行完成後，last_commit < 4的可以執行， trx5, trx6可分發
d)trx3、trx4、trx5完成後，last_commit < 7的可以執行，trx7可分發
綜上所述
我們認為MySQL 5.7版對Loss-Less半同步複製技術的最佳化，使得其成熟度和執行效率都得到了質的提高。我們建議在使用MySQL 5.7作為生產環境的部署時，可以使用半同步技術作為高可用與讀寫分離方案的資料複製方案。