【MySQL】半同步與增強半同步復制
首先要明白事務提交的三個階段，這里不再贅述。
半同步復制：主上已經提交了，但是日志還沒來得及傳到備庫，這時候宕機了，在半同步看來，主庫其他會話看來是透明的，看到的是他提交了的數據，但是如果這時候切換到slave，slave上又沒有提交，沒有看到這部分數據，這就矛盾了。而增強版同步，alter_sync，日志沒有傳輸到備庫，主庫這時候也沒有提交，這時候服務掛掉了，主庫其他會話看到的是未提交的數據，並且也沒有傳輸到備庫，所以數據不存在丟失一說。
無損復制，已經寫了二進制，但是沒有提交掛掉了，但是主從數據一致，因為雖然沒有提交，但是已經寫了二進制，並且已經傳到slave。
半同步復制的搭建，半同步復制是需要安裝插件的：
可以在參數文件中，指定每次啟動都加載plugin_load，也可以直接安裝插件。
手動：
install plugin rpl_semi_sync_master SONAME 'semisync_master.so';
install plugin rpl_semi_sync_slave SONAME 'semisync_slave.so';
配置文件：
loose_rpl_semi_sync_master_enabled=1 #表示開啟
loose_rpl_semi_sync_slave_enabled=1 #表示開啟
loose_表示沒有這個參數就忽略掉。
當半自動復制的延遲超過5秒就變成異步復制，備庫的IO線程追到5秒內，就自動又變成半同步復制。wait ACK表示IO線程接收到，並不是SQL線程應用完。
可以增加超時時間提高數據安全性，保證數據完全不丟失，但是這也帶來了應用響應的問題，也就是強制半同步復制。
5.7增強半同步
rpl_semi_sync_master_wait_point=AFTER_SYNC 開啟無損復制
rpl_semi_sync_master_wait_for_slave_count=1 至少有1個從庫收到說的就是這個參數。
MTS multi- threaded slave（ 並行復制 ）5.7建議必須使用：
slave-parallel-type=LOGICAL_CLOCK
【DATABASE】DATABASE的並行復制，每個Coordinator線程對應一個數據庫。DATABASE不再建議使用，【LOGICAL_CLOCK 】主庫上怎么並行的從庫上也是怎么並行。那么有一個問題主庫group commit那么從庫也能通過並行復制也能完成組提交嗎？是的，因為組提交的事務之間互相不沖突，
slave-parallel-workers=32或者16
MTS仍然為一個IO線程接收 state為 Waiting for master to send event ； SQL線程應用時候是System lock，等待時state為waiting for an event from Coordinator
在IO bond的情況下，開啟MTS性能提升非常明顯，純OLTP環境下開啟16或者32並行數，主庫性能提升5倍左右。