mysql半同步復制跟無損半同步區別
阿新 • • 發佈：2019-03-13
semi sync 5.7 幻讀 sof binlog 模式 inno strong microsoft
2) 主從數據一致性
- 半同步復制意味著在Master節點上，這個剛剛提交的事物對數據庫的修改，對其他事物是可見的。因此，如果在等待Slave ACK的時候crash了，那麽會對其他事務出現幻讀，數據丟失。
- 無損復制在write binlog完成後就傳輸binlog，但還沒有去寫commit log，意味著當前這個事物對數據庫的修改，其他事物也是不可見的。因此，不會出現幻讀，數據丟失風險。
因此5.7引入了無損復制（after_sync）模式，帶來的主要收益是解決after_commit導致的master crash後數據丟失問題，因此在引入after_sync模式後，所有提交的數據已經都被復制，故障切換時數據一致性將得到提升。
mysql半同步復制跟無損半同步復制的區別：
無損復制其實就是對semi sync增加了rpl_semi_sync_master_wait_point參數，來控制半同步模式下主庫在返回給會話事務成功之前提交事務的方式。rpl_semi_sync_master_wait_point該參數有兩個值：AFTER_COMMIT和AFTER_SYNC
第一個值：AFTER_COMMIT（5.6默認值）
master將每個事務寫入binlog（sync_binlog=1），傳遞到slave刷新到磁盤(sync_relay=1)，同時主庫提交事務。master等待slave反饋收到relay log，只有收到ACK後master才將commit OK結果反饋給客戶端。
第二個值：AFTER_SYNC（5.7默認值，但5.6中無此模式）
master將每個事務寫入binlog , 傳遞到slave刷新到磁盤(relay log)。master等待slave反饋接收到relay log的ack之後，再提交事務並且返回commit OK結果給客戶端。 即使主庫crash，所有在主庫上已經提交的事務都能保證已經同步到slave的relay log中。
半同步復制與無損復制的對比
1) ACK的時間點不同
- 半同步復制在InnoDB層的Commit Log後等待ACK，主從切換會有數據丟失風險。
- 無損復制在MySQL Server層的Write binlog後等待ACK，主從切換會有數據變多風險。
2) 主從數據一致性
- 半同步復制意味著在Master節點上，這個剛剛提交的事物對數據庫的修改，對其他事物是可見的。因此，如果在等待Slave ACK的時候crash了，那麽會對其他事務出現幻讀，數據丟失。
- 無損復制在write binlog完成後就傳輸binlog，但還沒有去寫commit log，意味著當前這個事物對數據庫的修改，其他事物也是不可見的。因此，不會出現幻讀，數據丟失風險。
因此5.7引入了無損復制（after_sync）模式，帶來的主要收益是解決after_commit導致的master crash後數據丟失問題，因此在引入after_sync模式後，所有提交的數據已經都被復制，故障切換時數據一致性將得到提升。
mysql半同步復制跟無損半同步區別