MySQL 5.7加強版Semisync Replication機能優化。本站提示廣大學習愛好者：（MySQL 5.7加強版Semisync Replication機能優化）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL 5.7加強版Semisync Replication機能優化正文
一 媒介
前文 引見了5.5/5.6 版本的MySQL semi sync 基本道理和設置裝備擺設，跟著MySQL 5.7 的宣布，新版本的MySQL修復了semi sync 的一些bug 而且加強了功效。
支撐發送binlog和接收ack的異步化;
支撐在事務commit前期待ACK;
在server層斷定備庫能否請求半同步以削減Plugin鎖抵觸;
消除binlog dump線程和lock_log的抵觸等等。
本文重點剖析 第1,2個改良項，由於本來的形式切實其實會影響體系的tps，新的異步形式可以進步半同步形式下的體系事務處置才能。
二 優化
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;
新版本的semi sync 增長了rpl_semi_sync_master_wait_point參數 來掌握半同步形式下 主庫在前往給會話事務勝利之條件交事務的方法。
該參數有兩個值：
AFTER_SYNC (默許值):master 將每一個事務寫入binlog ,傳遞到slave，而且刷新到磁盤。master期待slave 反應吸收到事務並刷新到磁盤。一旦接到slave反應，master在主庫提交事務而且前往成果給會話。 在AFTER_SYNC形式下，一切的客戶端在統一時辰檢查曾經提交的數據。假設產生主庫crash，一切在主庫上曾經提交的事務曾經同步到slave並記載到relay log。此時切換到從庫，可以保證最小的數據喪失。
AFTER_COMMIT: master 將每一個事務寫入binlog ,傳遞到slave 刷新到磁盤(relay log)，然後在主庫提交事務。master在提交事務後期待slave 反應吸收到事務並刷新到磁盤。一旦接到slave反應，master將成果反應給客戶端。
在AFTER_COMMIT形式下,假如slave 沒有運用日記,此時master crash，體系failover到slave，app將發明數據湧現紛歧致，在master提交而slave 沒有運用。
