複製架構衍生史
在談這個特性之前，我們先來看看MySQL的複製架構衍生史。
在2000年，MySQL 3.23.15版本引入了Replication。Replication作爲一種準實時同步方式，得到廣泛應用。這個時候的Replicaton的實現涉及到兩個線程，一個在Master，一個在Slave。Slave的I/O和SQL功能是作爲一個線程，從Master獲取到event後直接apply，沒有relay log。這種方式使得讀取event的速度會被Slave replay速度拖慢，當主備存在較大延遲時候，會導致大量binary log沒有備份到Slave端。
在2002年，MySQL 4.0.2版本將Slave端event讀取和執行獨立成兩個線程（IO線程和SQL線程），同時引入了relay log。IO線程讀取event後寫入relay log，SQL線程從relay log中讀取event然後執行。這樣即使SQL線程執行慢，Master的binary log也會儘可能的同步到Slave。當Master宕機，切換到Slave，不會出現大量數據丟失。
在2010年MySQL 5.5版本之前，一直採用的是這種異步複製的方式。主庫的事務執行不會管備庫的同步進度，如果備庫落後，主庫不幸crash，那麼就會導致數據丟失。於是在MySQL在5.5中就順其自然地引入了半同步複製，主庫在應答客戶端提交的事務前需要保證至少一個從庫接收並寫到relay log中。那麼半同步複製是否可以做到不丟失數據呢？下面分析。
在2016年，MySQL在5.7.17中引入了一個全新的技術，稱之爲InnoDB Group Replication。目前官方MySQL 5.7.17基於Group replication的全同步技術已經問世，全同步技術帶來了更多的數據一致性保障。相信是未來同步技術一個重要方向，值得期待。MySQL 5.7 Group Replication
根據上面提到的這幾種複製協議，分別對應MySQL幾種複製類型，分別是異步、半同步、全同步。
- 對於異步複製，主庫將事務Binlog事件寫入到Binlog文件中，此時主庫只會通知一下Dump線程發送這些新的Binlog，然後主庫就會繼續處理提交操作，而此時不會保證這些Binlog傳到任何一個從庫節點上。
- 對於全同步複製，當主庫提交事務之後，所有的從庫節點必須收到，APPLY並且提交這些事務，然後主庫線程才能繼續做後續操作。這裏面有一個很明顯的缺點就是，主庫完成一個事務的時間被拉長，性能降低。
- 對於半同步複製，是介於全同步複製和異步複製之間的一種，主庫只需要等待至少一個從庫節點收到並且Flush Binlog到Relay Log文件即可，主庫不需要等待所有從庫給主庫反饋。同時，這裏只是一個收到的反饋，而不是已經完全執行並且提交的反饋，這樣就節省了很多時間。