組提交難點

一.給leader進程帶來了不公平

創(chuàng)新互聯公司堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網站設計、成都做網站、企業(yè)官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯網時代的常德網站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！

二.兼顧redo和binlog順序的對應

三.事務redo與binlog的寫流程與fsync時機（沒有引進組提交時的流程）

四.為什么要組提交？（簡單組提交下的弊病，硬件資源速度的不一致性，帶來的優(yōu)勢）

關鍵參數與流程

flush階段

• 將Binlog寫入內存,(好像沒有Binlog buffer的說法，直接寫入內存，內存寫入條帶文件)。

• binlog_max_flush_queue_time 每多少秒去寫入一次Binlog到內存（官方）。flush階段中一批事務等待的時間。類似于檢票處一次用Bodycheck牌擋住一定數量的人。默認0,這個參數已經廢棄

sync->commit階段，主要是在sync，sync(刷盤binlog)。若sync_binlog不為1，多個組應該卡在這兒。豈不是導致commit ack變慢？不對，只是加速

• binlog_group_commit_sync_delay 應該是用來控制leader進度的，也就是發(fā)車間隔時間。這個是導致leader不公平的主要原因。單位微妙。微妙級別的話，相對于刷盤的時間，leader的不公平看起來微乎其微。

• binlog_group_commit_sync_no_delay_count 最低發(fā)車座位數， 類似于定員流水發(fā)車大巴，車上的人到達一定的數量后，直接發(fā)車，不在等待一個最小發(fā)車間隔

commit階段 redo log buffer刷盤

• sync_binlog的含義就變了，假定設為1000，表示的不是1000個事務后做一次fsync，而是1000個事務組。默認1的話就是，1個事務組提交一次fsync Binlog
  也就是說，比如， 1-1000個事務，前面999個都沒有sync，默認是sync成功的。第1000個事務時進行真正的binlog sync 。若中間掛了，沒有sync成功，那么1-1000事務的binlog 都沒有被記錄

• 第一次等待的時間可能不太好理解，，應該是第一次分批限流。比方說，保證流入sync階段的都是按時間分段的，而不是離散的算是預分組吧。找不到很合適的例子說明

總結

在讀寫IO相對于內存的速度有很大差距的情況下，把單次離散寫，合并成批量連續(xù)寫。硬盤的尋道時間要比順序寫硬盤的時間要慢很多。盡量少尋道，也是一種思路

參考

阿里月報 201501
https://www.kancloud.cn/taobaomysql/monthly/67157

官方手冊
https://dev.mysql.com/doc/refman/5.7/en/replication-options-reference.html

姜承堯
《Innodb存儲引擎 P322》

延伸閱讀

fb關于組提交的文章 發(fā)布時間：2010 年 10 月 7 日 周四 02:16
https://www.facebook.com/notes/mysql-at-facebook/group-commit/438641125932/
沒有精力

其實看源碼最直接，沒有精力

另外有需要云服務器可以了解下創(chuàng)新互聯cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

網站欄目：【MySQL】組提交技術的閱讀思考-創(chuàng)新互聯
路徑分享：http://weahome.cn/article/ddhgii.html