MySQL 基礎知識梳理學習（五）----半同步復制
1.半同步復制的特征
（1）從庫會在連接到主庫時告訴主庫，它是不是配置了半同步。
（2）如果半同步復制在主庫端是開啟了的，並且至少有一個半同步復制的從節點，那麽此時主庫的事務線程在提交時會被阻塞並等待，結果有兩種可能，要麽至少一個從庫節點通知它已經收到了所有這個事務的Binlog事件，要麽一直等待直到超過配置的某一個時間點為止，而此時，半同步復制將自動關閉，轉換為異步復制。
（3）從庫節點只有在接收到某一個事務的所有Binlog，將其寫入並Flush到Relay Log文件之後，才會通知對應主庫上面的等待線程。
（4）主庫如果在等待的過程中，等待時間已經超過了配置的超時時間，沒有任何一個從節點通知當前事務，那麽此時主庫會自動轉換為異步復制，當至少一個半同步從節點趕上來時，主庫便會自動轉換為半同步方式的復制。
（5）半同步復制必須是在主庫和從庫兩端都開啟時才行，如果在主庫上沒打開，或者在主庫上開啟了而在從庫上沒有開啟，主庫都會使用異步方式復制。
2.半同步的實質
在主庫被阻塞的過程中（等待從庫返回消息），主庫處理線程不會返回處理當前事務。當阻塞被激活之後，系統才會把控制權交給當前線程，然後繼續處理當前事務余下的事情。處理完成之後，此時主庫的事務已經提交，同時至少會有一個從庫也已經收到了這個事務的Binlog，這樣就盡可能地保證了主庫和從庫的一致性。
3.同步方式的區別
| 同步方式 | 不同點 |
| 異步復制 | 主庫將事務Binlog事件寫入到Binlog文件中，此時主庫只會通知一下Dump線程發送這些新的Binlog，然後主庫就會繼續處理提交操作，而此時不會保證這些Binlog傳到任何一個從庫節點上。 |
| 全同步復制 | 當主庫提交事務之後，所有的從庫節點必須收到、APPLY並且提交這些事務，然後主線程才能繼續做後續操作。這裏面一個很明顯的缺點就是，主庫完成一個事務的時間變長了，性能降低了。 |
| 半同步復制 | 介於全同步復制和全異步復制之間的一種，主庫只需要等待至少一個從庫節點收到並且Flush Binlog到Relay Log文件即可，主庫不需要等待所有從庫給主庫反饋。同時，這裏只是一個收到的反饋，而不是已經完全執行並且提交的反饋，這樣就節省了很多時間。 |
相比異步復制，半同步復制提升了數據完整性，可以保證在一個事務提交成功之後，這個事務就至少會存在於兩個地方。
4.註意
半同步復制對集群整體的性能會有一些影響，因為事務提交操作由於對從庫節點反饋的等待而變慢了，這也是對提高數據完整性的一種權衡。變慢時間的長短至少是TCP/IP的一次發送和接受所用的時間，因為它需要首先將Binlog發送出去，然後再等待從庫給主庫反饋消息。這也意味著，半同步復制在網絡狀況良好且主從節點的距離較近的情況下，工作效果會更好。
-----主要內容參考梳理於網絡知識，此短文僅為學習筆記，在此原創作者感謝！
MySQL 基礎知識梳理學習（五）----半同步復制