擴展
前面我們已經瞭解並配置過了mysql5.7的主從複製與基於GTID的主從複製，今天我們再來認識一種MYSQL的複製—半同步複製，又是一種複製，MYSQL到底有多少種複製呢？我們先來看看MySQL的複製架構衍生史。 MySQL的複製分爲四種：
1: 普通的replication，異步同步。 搭建簡單，使用非常廣泛，從mysql誕生之初，就產生了這種架構，性能非常好，可謂非常成熟。 但是這種架構數據是異步的，所以有丟失數據庫的風險。
2: semi-sync replication，半同步。性能，功能都介於異步和全同步中間。從mysql5.5開始誕生，目的是爲了折中上述兩種架構的性能以及優缺點。
3: sync replication，全同步。目前官方5.7基於Group replication的全同步技術處在labs版本，離正式集成已經不遠。全同步技術帶來了更多的數據一致性保障。相信是未來同步技術一個重要方向，值得期待。
4: mysql cluster。 基於NDB引擎，搭建也簡單，本身也比較穩定，是mysql裏面對數據保護最靠譜的架構，也是目前唯一一個數據完全同步的架構，數據零丟失。不過對業務比較挑剔，限制也較多。
半同步複製
我們今天就來看看這第二種架構—半同步複製，我們知道，普通的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架構，其成熟度、數據一致性與執行效率得到顯著的提升。
配置基於GTID的mysql半同步複製
實驗環境
半同步複製在異步複製（我們之前搭建號的主從複製就是異步複製）的基礎上進行，所以我們直接開啓上次做主從複製的虛擬機進行實驗，沒有做的話，先搭建號mysql的主從複製再進行mysql的半同步複製
配置
一、檢查mysql主從複製是否正確，檢查完後關閉slave
在slave中：show slave status\G;
stop slave;
二、在master中
1：安裝master插件
install plugin rpl_semi_sync_master soname ‘semisync_master.so’;
2：set global rpl_semi_sync_master_enabled=1; ##啓用master的半同步複製，也可以將此選項寫到配置文件/etc/my.cnf中
三、在slave中
1：安裝slave插件
install plugin rpl_semi_sync_slave soname ‘semisync_slave.so’;
2：set global rpl_semi_sync_slave_enabled=1; ##啓用slave半同步複製，可以寫到配置文件中
3：重啓slave上的IO線程,如果沒有重啓，則默認還是異步複製，重啓後，slave會在master上註冊爲半同步複製的slave角色。
stop slave io_thread;
start slave io_thread;
四、在master端查看配置情況
1：查看環境變量
show variables like ‘%semi%’;
1：rpl_semi_sync_master_timeout
這個參數的值爲10000，即10s,意爲等待slave傳回ack的時間，超過10s將變爲異步複製
2：rpl_semi_sync_master_wait_for_slave_count
MySQL 5.7.3引入的，該變量設置主需要等待多少個slave應答，才能返回給客戶端，默認爲1
3：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，即異步複製。
4：rpl_semi_sync_master_wait_point
該參數有兩個值：
（1）：AFTER_COMMIT（5.6默認值）
master將每個事務寫入binlog ,傳遞到slave 刷新到磁盤(relay log)，同時主庫提交事務。
master等待slave 反饋收到relay log，只有收到ACK後master纔將commit OK結果反饋給
客戶端。
（2）：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：查看狀態變量
show status like ‘%semi%’;
Rpl_semi_sync_master_clients
當前半同步複製slave的個數，如果是一主多從的架構，並不包含異步複製slave的個數。
五、在master與slave中分別查看半同步運行狀態
在master中：
show status like ‘Rpl_semi_sync_master_status’;
在slave中：
start slave;
show status like ‘Rpl_semi_sync_slave_status’;
這兩個變量常用來監控主從是否運行在半同步複製模式下。value爲ON，
所以，MySQL半同步複製搭建成功！！
事實上，半同步複製並不是嚴格意義上的半同步複製，當半同步複製發生超時時（由rpl_semi_sync_master_timeout參數控制，單位是毫秒，默認爲10000，即10s），會暫時關閉半同步複製，轉而使用異步複製。當master dump線程發送完一個事務的所有事件之後，如果在rpl_semi_sync_master_timeout內，收到了從庫的響應，則主從又重新恢復爲半同步複製。
測試
一、第一次測試
1：在master中插入數據
往user庫的usertb表中插入一條數據：
insert into user.usertb value (‘user2’,‘123’);
master的操作很快就能返回，因爲很快就會收到slave傳回的的ack
2：在slave中查看
select * from user.usertb;
二、第二次測試
1：先在slave中執行：
stop slave；
show status like ‘Rpl_semi_sync_slave_status’;
2：在master中
insert into user.usertb values(‘user3’,‘456’);
show status like ‘Rpl_semi_sync_master_status’;
insert操作需要10.08s才返回，而這與rpl_semi_sync_master_timeout參數的時間相吻合。
此時，兩個狀態的值，均爲“OFF”。
三、第三次測試
1：開啓slave，則主和從會快速恢復到半同步複製
2：在master中
show status like ‘Rpl_semi_sync_master_status’;
至此，基於GTID的mysql5.7半同步複製就配置完成了！！