異步：主庫將事務Binlog事件寫入到Binlog文件中，此時主庫只會通知一下Dump線程發送這些新的Binlog，然後主庫就會繼續處理提交操作，而此時不會保證這些Binlog傳到任何一個從庫節點上。主庫的事務執行不會管備庫的同步進度，如果備庫落後，主庫不幸crash，那麽就會導致數據丟失。

半同步：是介於全同步復制和異步復制之間的一種，主庫只需要等待至少一個從庫節點收到並且Flush Binlog到Relay Log文件即可，主庫不需要等待所有從庫給主庫反饋。同時，這裏只是一個收到的反饋，而不是已經完全執行並且提交的反饋，這樣就節省了很多時間。數據丟失的風險，當一個事物commit之後，如果主節點此時宕機了，切換到從庫，那麽從庫還沒有接到之前event，那麽在主庫成功提交的數據，在從庫也就看不到了，此時就是數據丟失的情況；

全同步機制：當主庫提交事務之後，所有的從庫節點必須收到，APPLY並且提交這些事務，然後主庫線程才能繼續做後續操作。這裏面有一個很明顯的缺點就是，主庫完成一個事務的時間被拉長，性能降低。

無損復制：基於半同步的一種優化，半同步是將事物首先commit之後再等待slave端的ACK，這樣會導致數據的幻讀，然而無損復制是等ACK應答之後再去commit事務。同樣上面的問題，如果主節點宕機了，切換到了從節點，但是主節點的event事件依舊沒有去提交，此時兩邊都沒有這個事務，所以從某種意義來說不會有數據丟失。但是也同樣存在一個問題，如果主庫數據傳輸到Slave後，Slave進行ack確認時主庫宕機，那麽當主庫重新啟動後由於redo和binlog都有事務信息，所以這個或這組事務必然會提交成功，那麽主從數據一致，皆大歡喜。那麽如果說主庫數據在傳輸到從庫的過程中宕機，那麽從庫必然沒有最新binlog，當主庫重啟後同樣會提交最後這個或這組事務，此時就意味著主從數據不一致。如果你想讓老的主庫做新主庫的從庫，就需要人工幹預處理了。這也是基於無損復制做高可用需要考慮的。

參考鏈接
http://www.ywnds.com/?p=7023

MariaDB 幾種熱備同步方式比較