mysql異步複制
mysql異步複制是指，mysql主庫将事務資訊寫入binlog檔案中的時候，此時主庫會通過binlog dump線程給從庫發送這些新的binlog變化，然後并不等待從庫的響應繼續送出事務并寫入binlog，是以主庫并不保證這些事務變化的binlog資料會傳輸并應用到任何從庫。
mysql全同步複制
mysql全同步複制是指，當主庫送出事務的binlog後，所有的從庫節點必須全部收到事務并且apply并且送出這些内容之後，即io_thread和sql_thread完成所有binlog變化的接受的應用執行，主庫的線程才可以繼續進行後續操作，但是缺點是，主庫完成一個事務的時間會被拉長，性能急劇降低。
mysql半同步複制
mysql半同步複制是介于異步和全同步之間，主庫隻需要等待至少一個從節點，收到并且flush binlog到relay log檔案即可，主庫不需要等待所有從庫給主庫回報，這裡隻是一個收到的回報，而并不是從庫已經完成并送出的回報，即從庫隻應用完成io_thread内容即可無需等到sql_thread的執行完成。
半同步複制分為倆種
after commit
這個是mysql5.6的半同步參數，after commit是在主庫寫完bin log，在等待slave ack時候，雖然沒有傳回目前用戶端，但事務已經送出，其他用戶端會讀取到已送出事務。如果slave端還沒有讀到該事務的events，同時主庫發生了crash，然後切換到備庫。那麼之前讀到的事務就不見了，出現了幻讀。如下圖所示：
after sync
mysql5.7在調用binlog sync之後，engine層commit之前等待slave ack。這樣隻有在确認slave收到事務events後，事務才會送出。在commit之前等待slave ack，同時可以堆積事務，利于group commit，有利于提升性能。
上圖流程中存在着會導緻主備資料不一緻，使主備同步失敗的情形，當sync_binlog為0的時候，binlog sync磁盤由作業系統負責。當不為0的時候，其數值為定期sync磁盤的binlog commit group數。當sync_binlog值大于1的時候，sync binlog操作可能并沒有使binlog落盤。如果沒有落盤，事務在送出前，master掉電，然後恢複，那麼這個時候該事務被復原。但是slave上可能已經收到了該事務的events并且執行，這個時候就會出現slave事務比master多的情況，主備同步會失敗。是以如果要保持主備一緻，需要設定sync_binlog為1。
。