從MySQL5.5開始，MySQL以插件的形式支援半同步複制。如何了解半同步呢？首先我們來看看異步，全同步的概念
異步複制（Asynchronous replication）
MySQL預設的複制即是異步的，主庫在執行完用戶端送出的事務後會立即将結果返給給用戶端，并不關心從庫是否已經接收并處理，這樣就會有一個問題，主如果crash掉了，此時主上已經送出的事務可能并沒有傳到從上，如果此時，強行将從提升為主，可能導緻新主上的資料不完整。
全同步複制（Fully synchronous replication）
指當主庫執行完一個事務，所有的從庫都執行了該事務才傳回給用戶端。因為需要等待所有從庫執行完該事務才能傳回，是以全同步複制的性能必然會收到嚴重的影響。
半同步複制（Semisynchronous replication）
介于異步複制和全同步複制之間，主庫在執行完用戶端送出的事務後不是立刻傳回給用戶端，而是等待至少一個從庫接收到并寫到relay log中才傳回給用戶端。相對于異步複制，半同步複制提高了資料的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。是以，半同步複制最好在低延時的網絡中使用。
下面來看看半同步複制的原理圖：
半同步複制的潛在問題
用戶端事務在存儲引擎層送出後，在得到從庫确認的過程中，主庫當機了，此時，可能的情況有兩種
事務還沒發送到從庫上
此時，用戶端會收到事務送出失敗的資訊，用戶端會重新送出該事務到新的主上，當當機的主庫重新啟動後，以從庫的身份重新加入到該主從結構中，會發現，該事務在從庫中被送出了兩次，一次是之前作為主的時候，一次是被新主同步過來的。
事務已經發送到從庫上
此時，從庫已經收到并應用了該事務，但是用戶端仍然會收到事務送出失敗的資訊，重新送出該事務到新的主上。
無資料丢失的半同步複制
針對上述潛在問題，MySQL 5.7引入了一種新的半同步方案：Loss-Less半同步複制。
針對上面這個圖，“Waiting Slave dump”被調整到“Storage Commit”之前。
當然，之前的半同步方案同樣支援，MySQL 5.7.2引入了一個新的參數進行控制-rpl_semi_sync_master_wait_point
rpl_semi_sync_master_wait_point有兩種取值
AFTER_SYNC
這個即新的半同步方案，Waiting Slave dump在Storage Commit之前。
AFTER_COMMIT
老的半同步方案，如圖所示。
半同步複制的安裝部署
要想使用半同步複制，必須滿足以下幾個條件：
1. MySQL 5.5及以上版本
2. 變量have_dynamic_loading為YES
3. 異步複制已經存在
首先加載插件
因使用者需執行INSTALL PLUGIN, SET GLOBAL, STOP SLAVE和START SLAVE操作，是以使用者需有SUPER權限。
主：
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
從：
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
檢視插件是否加載成功
有兩種方式
1.
mysql> show plugins;
rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL 2.
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
+----------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE |
+----------------------+---------------+
1 row in set (0.00 sec) 啟動半同步複制
在安裝完插件後，半同步複制預設是關閉的，這時需設定參數來開啟半同步
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;
以上的啟動方式是在指令行操作，也可寫在配置檔案中。
plugin-load=rpl_semi_sync_master=semisync_master.so
rpl_semi_sync_master_enabled=1 plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=1 在有的高可用架構下，master和slave需同時啟動，以便在切換後能繼續使用半同步複制
plugin-load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
rpl-semi-sync-master-enabled = 1
rpl-semi-sync-slave-enabled = 1 重新開機從上的IO線程
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;
如果沒有重新開機，則預設還是異步複制，重新開機後，slave會在master上注冊為半同步複制的slave角色。
這時候，主的error.log中會列印如下資訊：
2016-08-05T10:03:40.104327Z 5 [Note] While initializing dump thread for slave with UUID <ce9aaf22-5af6-11e6-850b-000c2988bad2>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(4).
2016-08-05T10:03:40.111175Z 4 [Note] Stop asynchronous binlog_dump to slave (server_id: 2)
2016-08-05T10:03:40.119037Z 5 [Note] Start binlog_dump to master_thread_id(5) slave_server(2), pos(mysql-bin.000003, 621)
2016-08-05T10:03:40.119099Z 5 [Note] Start semi-sync binlog_dump to slave (server_id: 2), pos(mysql-bin.000003, 621) 檢視半同步是否在運作
mysql> show status like 'Rpl_semi_sync_master_status';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | ON |
+-----------------------------+-------+
1 row in set (0.00 sec) mysql> show status like 'Rpl_semi_sync_slave_status';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Rpl_semi_sync_slave_status | ON |
+----------------------------+-------+
1 row in set (0.20 sec) 這兩個變量常用來監控主從是否運作在半同步複制模式下。
至此，MySQL半同步複制搭建完畢~
事實上，半同步複制并不是嚴格意義上的半同步複制
當半同步複制發生逾時時（由rpl_semi_sync_master_timeout參數控制，機關是毫秒，預設為10000，即10s），會暫時關閉半同步複制，轉而使用異步複制。當master dump線程發送完一個事務的所有事件之後，如果在rpl_semi_sync_master_timeout内，收到了從庫的響應，則主從又重新恢複為半同步複制。
下面來測試一下
該驗證分為三個階段
1. 在Slave執行stop slave之前，主的insert操作很快就能傳回。
2. 在Slave執行stop slave後，主的insert操作需要10.01s才傳回，而這與rpl_semi_sync_master_timeout參數的時間相吻合。
這時，檢視兩個狀态的值，均為“OFF”了。
同時，主的error.log中列印如下資訊：
2016-08-05T11:51:49.855452Z 6 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000003, pos: 1447), semi-sync up to file mysql-bin.000003, position 1196.
2016-08-05T11:51:49.855742Z 6 [Note] Semi-sync replication switched OFF. 3. 在Slave執行start slave後，主的insert操作很快就能傳回，此時，兩個狀态的值也變為“ON”了。
同時，主的error.log中會列印如下資訊：
2016-08-05T11:52:40.477098Z 7 [Note] Start binlog_dump to master_thread_id(7) slave_server(2), pos(mysql-bin.000003, 1196)
2016-08-05T11:52:40.477168Z 7 [Note] Start semi-sync binlog_dump to slave (server_id: 2), pos(mysql-bin.000003, 1196)
2016-08-05T11:52:40.523475Z 0 [Note] Semi-sync replication switched ON at (mysql-bin.000003, 1447) 其它變量
環境變量
mysql> show variables like '%Rpl%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
| rpl_stop_slave_timeout | 31536000 |
+-------------------------------------------+------------+
7 rows in set (0.30 sec) rpl_semi_sync_master_wait_for_slave_count
MySQL 5.7.3引入的，該變量設定主需要等待多少個slave應答，才能傳回給用戶端，預設為1。
rpl_semi_sync_master_wait_no_slave
ON
預設值，當狀态變量Rpl_semi_sync_master_clients中的值小于rpl_semi_sync_master_wait_for_slave_count時，Rpl_semi_sync_master_status依舊顯示為ON。
OFF
當狀态變量Rpl_semi_sync_master_clients中的值于rpl_semi_sync_master_wait_for_slave_count時，Rpl_semi_sync_master_status立即顯示為OFF，即異步複制。
說得直白一點，如果我的架構是1主2從，2個從都采用了半同步複制，且設定的是rpl_semi_sync_master_wait_for_slave_count=2，如果其中一個挂掉了，對于rpl_semi_sync_master_wait_no_slave設定為ON的情況，此時顯示的仍然是半同步複制，如果rpl_semi_sync_master_wait_no_slave設定為OFF，則會立刻變成異步複制。
狀态變量
mysql> show status like '%Rpl_semi%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_net_avg_wait_time | 0 |
| Rpl_semi_sync_master_net_wait_time | 0 |
| Rpl_semi_sync_master_net_waits | 6 |
| Rpl_semi_sync_master_no_times | 1 |
| Rpl_semi_sync_master_no_tx | 1 |
| Rpl_semi_sync_master_status | ON |
| Rpl_semi_sync_master_timefunc_failures | 0 |
| Rpl_semi_sync_master_tx_avg_wait_time | 1120 |
| Rpl_semi_sync_master_tx_wait_time | 4483 |
| Rpl_semi_sync_master_tx_waits | 4 |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0 |
| Rpl_semi_sync_master_wait_sessions | 0 |
| Rpl_semi_sync_master_yes_tx | 4 |
+--------------------------------------------+-------+
14 rows in set (0.00 sec) 上述狀态變量中，比較重要的有以下幾個
Rpl_semi_sync_master_clients
目前半同步複制從的個數，如果是一主多從的架構，并不包含異步複制從的個數。
Rpl_semi_sync_master_no_tx
The number of commits that were not acknowledged successfully by a slave.
具體到上面的測試中，指的是insert into test.test values(2)這個事務。
Rpl_semi_sync_master_yes_tx
The number of commits that were acknowledged successfully by a slave.
具體到上面的測試中，指的是以下四個事務
create database test;
create table test.test(id int);
insert into test.test values(1);
insert into test.test values(3);
總結
1. 在一主多從的架構中，如果要開啟半同步複制，并不要求所有的從都是半同步複制。
2. MySQL 5.7極大的提升了半同步複制的性能。
5.6版本的半同步複制，dump thread 承擔了兩份不同且又十分頻繁的任務：傳送binlog 給slave ，還需要等待slave回報資訊，而且這兩個任務是串行的，dump thread 必須等待 slave 傳回之後才會傳送下一個 events 事務。dump thread 已然成為整個半同步提高性能的瓶頸。在高并發業務場景下，這樣的機制會影響資料庫整體的TPS 。
5.7版本的半同步複制中，獨立出一個 ack collector thread ，專門用于接收slave 的回報資訊。這樣master 上有兩個線程獨立工作，可以同時發送binlog 到slave ，和接收slave的回報。
參考
1. MariaDB原理與實作
2. http://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html
3. http://sanwen8.cn/p/105GRDe.html
4. 知數堂《MySQL 5.7 Replication新特性》分享
![内網滲透 day22-橫向移動[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)