MySQL5.7版本 Semisync Replication 增強
來自： http://blog.csdn.net//jiao_fuyou/article/details/46301345
原文地址：http://blog.itpub.net/22664653/viewspace-1183057/
一 前言
- 支持發送binlog和接受ack的異步化;
- 支持在事務commit前等待ACK;
- 在server層判斷備庫是否要求半同步以減少Plugin鎖沖突;
- 解除binlog dump線程和lock_log的沖突等等。
</div> </div>
二 優化
1 支持發送binlog和接受ack的異步化
通過前面的介紹，我們知道Semisynchronous Replication模式下,app在主庫上提交一個事務/event，MySQL將每個事務寫入binary并且同步到到slave ，master會等待至少一個slave通知:slave 已經接收到傳過來的events并寫入relay log，才返回給回話層 寫入成功，或者直到傳送日志發生超時,系統自動將為異步復制模式。
整體流程的邏輯圖
5.5 版本semi sync 設計的缺點：
從原理以及上圖來看，舊版本的semi sync 受限于dump thread ，原因是dump thread 承擔了兩份不同且又十分頻繁的任務：傳送binlog 給slave ，還需要等待slave反饋信息，而且這兩個任務是串行的，dump thread 必須等待 slave 返回之后才會傳送下一個 events 事務。dump thread 已然成為整個半同步提高性能的瓶頸在高并發業務場景下，這樣的機制會影響數據庫整體的TPS .
為了解決上述問題，在5.7.4版本的semi sync 框架中，獨立出一個 ack collector thread ，專門用于接收slave 的反饋信息。這樣master 上有兩個進程獨立工作，可以同時發送binlog 到slave ，和接收slave的反饋。整體流程的邏輯圖
大體的實現思路是:
備庫IO線程使用TCP協議和主庫交互,讀寫socket可以同時進行,在開啟主庫semisync時,啟動一個后臺線程,使用select監聽備庫連接socket;
dump線程不再等待備庫ACK;在ack reciver線程等待ACK時,dump線程還能繼續發送下一組group commit的binlog,進而提升TPS.
2 支持在事務commit前等待ACK;
該參數有兩個值：
AFTER_SYNC (默認值):master 將每個事務寫入binlog ,傳遞到slave，并且刷新到磁盤。master等待slave 反饋接收到事務并刷新到磁盤。一旦接到slave反饋，master在主庫提交事務并且返回結果給會話。</span> 在AFTER_SYNC模式下，所有的客戶端在同一時刻查看已經提交的數據。假如發生主庫crash，所有在主庫上已經提交的事務已經同步到slave并記錄到relay log。 此時切換到從庫，可以保障最小的數據損失。
AFTER_COMMIT: master 將每個事務寫入binlog ,傳遞到slave 刷新到磁盤(relay log)，然后在主庫提交事務。master在提交事務后等待slave 反饋接收到事務并刷新到磁盤。一旦接到slave反饋，master將結果反饋給客戶端。</span>
在AFTER_COMMIT模式下,如果slave 沒有應用日志,此時master crash，系統failover到slave，app將發現數據出現不一致，在master提交而slave 沒有應用。
</div>
</div>
三 推薦閱讀
[1] 5.7 Semisynchronous Replication
[3] enforced-semi-synchronous-replication
MySQL 5.7 半同步增強，增加 rpl_semi_sync_master_wait_slave_count 參數控制主庫接收多少個slave 寫事務成功反饋 才返回 成功給客戶端 。
[4] faster-semisync-replication
修改原來有dump thread 發送event和接收slave ack 模式，獨立出 單獨 接收slave 返回 ack的進程，提高半同步模式的tps 。