Mysql的複製分為4種：

1、非同步複製replication

2、Semi-sync replication  半同步複製 效能基於非同步和全同步之間

3、Sync replication 全同步

4、Mysql cluster 基於NDB引擎

普通非同步複製理解：

正常的複製為：事務一（t1）寫入binlog buffer；dumper 執行緒通知slave有新的事務t1；binlog buffer 進行checkpoint；slave的io執行緒接收到t1並寫入到自己的的relay log；slave的sql執行緒寫入到本地資料庫。 這時，master和slave都能看到這條新的事務，即使master掛了，slave可以提升為新的master。

但是會出現問題：

當事務t1寫入binlog  buffer，dumper執行緒通知slave有了新的事務t1，binlog buffer進行checkpoint，slave因為網路不穩定，沒有收到t1事務，這個時候正好master又掛掉了，slave提升為主庫 ，t1事務就丟失了

還有一個性能問題：

當主庫業務的併發量上來，或者進行大事務的DML操作，slave因為要序列執行master上的併發操作，會導致很大延遲，不過下面的半同步可以解決這個問題

半同步基本原理：

在master的dumper執行緒通知slave後，增加了一個ack（ack作為一個標記），即是否成功收到事務t1的標誌碼。也就是dumper執行緒除了傳送t1到slave，還承擔了接收slave的ack工作。

半同步的問題：

1、如果異常發生，會降級為普通的複製。 那麼從機出現數據不一致的機率會減少，並不是完全消失。

2、主機dumper執行緒承擔的工作變多了，這樣顯然會降低整個資料庫的效能。

3、在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒有收到事務，也就是還沒有寫入到relay log 之前，網路出現異常或者不穩定，此時剛好master掛了，系統切換到從機，兩邊的資料就會出現不一致。 在此情況下，slave會少一個事務的資料。

什麼是after_commit(5.6預設值)和after_sync模式（5.7預設值，5.6沒有）?

After_commit

Master將事務寫進binlog日誌中，傳遞到slave重新整理到relay_log，同時master提交事務。Master等待slave反饋寫入了relay log，只有收到sck包後master才會將commit ok結果反饋給客戶端

After_sync

master將事務寫進binlog中，傳到slave重新整理到磁碟relay log。Master等待slave收到ack包之後，再提交事務並且返回commit ok結果給客戶端，這樣即使主庫宕機了，也可以保證所有主庫上的書屋都已經同步到了slave的relay log上去

5.7的半同步複製效能也得到大幅度提升，支援傳送binlog和接收ack包非同步化，似的dumper執行緒壓力減少，不再是同步的瓶頸。

rpl_semi_sync_master_wait_slave_count引數，可以控制接收多少個slave寫事務成功反饋

個人認為5.7複製特性裡面比較重要的點來了

Replication的組提交

MySQL5.7有個新的變數 slave_parallel_type 他有2個引數

1、database 基於庫的並行複製方式

2、Logical——clock 基於組的並行複製方式

Mysql5.6也支援並且複製（暫且可以叫他偽並行複製），但是其並行只是基於DATABASE的，也就是基於庫的。如果使用者的MySQL資料庫例項中存在多個DATABASE ，對於從機複製的速度的確可以有比較大的幫助，如果使用者例項僅有一個庫，那麼就無法實現並行回放，甚至效能會比原來的單執行緒更差。

MySQL5.7的話會為同時進入commit階段的事務分配相同的序列號，相同序列號的事務在slave中是可以併發執行的。真正實現了並行複製，最重要的原因是slave的回放和主機是一致的，不會再有庫的並行複製限制，對binlog日誌的格式也沒有特殊的要求。

總結：

Mysql5.7在半同步複製技術上使得資料庫執行效率得到了質的飛躍。