【MySQL】半同步與增強半同步復制

首先要明白事務提交的三個階段，這里不再贅述。

    半同步復制：主上已經提交了，但是日志還沒來得及傳到備庫，這時候宕機了，在半同步看來，主庫其他會話看來是透明的，看到的是他提交了的數(shù)據，但是如果這時候切換到slave，slave上又沒有提交，沒有看到這部分數(shù)據，這就矛盾了。而增強版同步，alter_sync，日志沒有傳輸?shù)絺鋷?，主庫這時候也沒有提交，這時候服務掛掉了，主庫其他會話看到的是未提交的數(shù)據，并且也沒有傳輸?shù)絺鋷?，所以?shù)據不存在丟失一說。
無損復制，已經寫了二進制，但是沒有提交掛掉了，但是主從數(shù)據一致，因為雖然沒有提交，但是已經寫了二進制，并且已經傳到slave。 半同步復制的搭建，半同步復制是需要安裝插件的：

可以在參數(shù)文件中，指定每次啟動都加載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_表示沒有這個參數(shù)就忽略掉。

當半自動復制的延遲超過5秒就變成異步復制，備庫的IO線程追到5秒內，就自動又變成半同步復制。wait ACK表示IO線程接收到，并不是SQL線程應用完。
可以增加超時時間提高數(shù)據安全性，保證數(shù)據完全不丟失，但是這也帶來了應用響應的問題，也就是強制半同步復制。

5.7增強半同步
rpl_semi_sync_master_wait_point=AFTER_SYNC 開啟無損復制
rpl_semi_sync_master_wait_for_slave_count=1  至少有1個從庫收到說的就是這個參數(shù)。

MTS multi- threaded  slave（ 并行復制 ）5.7建議必須使用：

    slave-parallel-type=LOGICAL_CLOCK 

【DATABASE】DATABASE的并行復制，每個Coordinator線程對應一個數(shù)據庫。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環(huán)境下開啟16或者32并行數(shù)，主庫性能提升5倍左右。