Group Replication 是一種新的復(fù)制模式羔挡，它徹底顛覆了傳統(tǒng)的復(fù)制模式签财，雖然還是異步復(fù)制（或者可稱其為同步復(fù)制敬鬓，異步應(yīng)用）淹朋，但能夠?qū)崿F(xiàn)強最終一致性，并且完全實現(xiàn)了無人干預(yù)式高可用钉答，必將成為未來的主流础芍。本文不詳細介紹Group Replication的實現(xiàn)原理，網(wǎng)上有許多資料数尿，這里主要對如何優(yōu)化Group Replication集群進行分析探討仑性。
首先我們分析下影響GR性能的主要因素。
影響GR性能主要因素：
- 網(wǎng)絡(luò)帶寬
在寫節(jié)點上產(chǎn)生的事務(wù)砌创，在最終被commit前虏缸，需要發(fā)送到復(fù)制組中做沖突校驗，這需要消耗網(wǎng)絡(luò)帶寬嫩实，并給事務(wù)的延遲至少增加一個RTT(Round Trip Time,TCP數(shù)據(jù)包旅行一個回路的時間)刽辙。 - 校驗吞吐量
事務(wù)會被按照相同的順序發(fā)送到各節(jié)點做沖突校驗，校驗通過后會被遠端節(jié)點寫入relay-log甲献，這個寫入是由一個單線程負責(zé)宰缤。當校驗的速率很高，磁盤吞吐量（relay-log寫入）將會成為瓶頸晃洒。 - 讀節(jié)點applier線程應(yīng)用效率
讀節(jié)點的applier線程的應(yīng)用不及時會觸發(fā)writer節(jié)點flow-control慨灭，對于多主模式架構(gòu)，applier線程的低效可能會造成校驗失敗率升高球及。
GR性能瓶頸主要存在上面三個方面氧骤，有些是需要提升物理硬件，有些則是參數(shù)調(diào)整吃引。我們來分析下針對每一個方面的優(yōu)化措施筹陵。
網(wǎng)絡(luò)因素：
使用高帶寬低延遲網(wǎng)絡(luò)刽锤，使所有節(jié)點都處于同一網(wǎng)關(guān)
-
減少帶寬消耗，如采取啟用壓縮,盡量縮小binlog等措施
group_replication_compression_threshold=1000000 # default in mysql8.0.11 binlog_row_image=MINIMALgroup_replication_compression_threshold 當復(fù)制組間通信的event超過這一閾值時朦佩，啟用LZ4壓縮并思，以減小通信量。
binlog_row_image默認是full,即將某行數(shù)據(jù)的改變前(before)和改變后(after)的數(shù)據(jù)都寫入binlog.實際上只有update才會產(chǎn)生改變前和改變后兩個數(shù)據(jù)鏡像语稠，而對于insert只會有改變后的數(shù)據(jù)鏡像宋彼，delete只會有改變前的數(shù)據(jù)鏡像。如果每個表都有primary key(表定義在主從架構(gòu)中完全相同仙畦，group replication要求表必須有主鍵),完全可以在binlog中的before鏡像中記入主鍵值（它已經(jīng)能唯一標識數(shù)據(jù)改變的行了）输涕，而在after鏡像中只記錄所改變的字段的值，而不是所有的字段的值议泵。這樣binlog就大大縮小占贫，網(wǎng)絡(luò)間通信量也就大大減少了。只是在從節(jié)點應(yīng)用這樣的binlog event時先口，效率會有點低。
-
通過頻繁等待瞳收，減少group replication線程睡眠次數(shù)
SET GLOBAL group_replication_poll_spin_loops= 10000; # default 0這樣可使GCT(Group Comunitcatoin Thread)積極地在消息隊列處等待碉京，一旦隊列中有新消息可以更快地響應(yīng)。同時也降低了操作系統(tǒng)對其上下文切換頻率螟深。
校驗速率：
- 可以使用single-primary模式谐宙，因為正常情況下，這種模式是不需要校驗的（有一種情況除外界弧，就是新master正在應(yīng)用從之前的primary復(fù)制來的binlog凡蜻，這種情況下是需要校驗的），但這種模式下垢箕，一旦primary宕機划栓，需要選舉一個新的master,多了一個選舉的過程。
- 將relay-log条获，tmpdir 置于高性能硬盤, 校驗通過后非local_transaction要寫入relay log忠荞，對于大事務(wù)writeset的抽取可能會需要寫入磁盤臨時文件，如果relay log/臨時文件讀寫性能很差帅掘，將會大大增加事務(wù)的延時委煤。在這兩個地方可能產(chǎn)生物理IO瓶頸。
- 對于多主架構(gòu)減少校驗的復(fù)雜度
事務(wù)在節(jié)點執(zhí)行完成修档，commit前發(fā)送到GR做校驗碧绞。校驗成功后，GR會給此事務(wù)分配一個GTID（如果該事務(wù)沒有GTID）吱窝。GR會給每個節(jié)點預(yù)留一個范圍的GTID讥邻，（GTID是由server_uuid+數(shù)字組成寓免，gr中GTID中的UUID部分都是一樣的，數(shù)字部分則為各節(jié)點分配一個范圍段计维，用完了再分配一個新的范圍段）袜香。這個范圍段的大小就是有g(shù)roup_replication_gtid_assignment_block_size變量控制，默認是1000000鲫惶。這個數(shù)字范圍如果很大的話蜈首，gtid_executed就不能及時合并,許多GTID interval 會使校驗算法變得復(fù)雜。group_replication_gtid_assignment_block_size=1000000 # default
Applier應(yīng)用線程
- 啟用MTS多線程應(yīng)用
set global slave_parallel_type=LOGICAL_CLOCK;
set global slave_parallel_workers=8/16/32/+;
set global slave_preserve_commit_order=ON;
- 啟用基于寫集依賴的多線程應(yīng)用欠母，使并發(fā)效率更高
# for mysql8
binlog_transaction_dependency_tracking=WRITESET
Applier線程的高效應(yīng)用對提升集群性能非常重要欢策。因為Applier 線程應(yīng)用不及時可能會觸發(fā)writer節(jié)點啟用flow control,直接影響性能。除此之外赏淌，它對校驗也會有重要的影響踩寇。因為Applier 的及時應(yīng)用可以使transaction_commit_on_all_memebers及時跟進，stable set 更加接近最新的事務(wù)六水。這會使校驗集合（Certification_info）中的無用的快照版本被及時垃圾回收俺孙，從而降低了校驗的復(fù)雜度，提高了整體性能的吞吐量掷贾。這是一個很重要的優(yōu)化策略睛榄！
總結(jié)
根據(jù)group replication的實現(xiàn)原理，其瓶頸主要產(chǎn)生于三點：
- 復(fù)制組間通信（高帶寬網(wǎng)絡(luò)）
- 事務(wù)在各節(jié)點的校驗
- Applier應(yīng)用效率
優(yōu)化的思路也是主要集中在這三個方向想帅。每次調(diào)整參數(shù)都應(yīng)壓測對比效果场靴，確保理論符合實際。盲目根據(jù)理論調(diào)優(yōu)而不壓測對比是不可取的港准。一套優(yōu)化方案旨剥，都是經(jīng)過反復(fù)調(diào)參反復(fù)壓測而得出的最終結(jié)果。
參考資料：
之前讀過一篇文章浅缸，寫的很好轨帜，現(xiàn)在找不到了，很抱歉疗杉！
