Group Replication 是一種新的復制模式，它徹底顛覆了傳統(tǒng)的復制模式，雖然還是異步復制（或者可稱其為同步復制，異步應用），但能夠實現強最終一致性，并且完全實現了無人干預式高可用，必將成為未來的主流。本文不詳細介紹Group Replication的實現原理，網上有許多資料，這里主要對如何優(yōu)化Group Replication集群進行分析探討。
首先我們分析下影響GR性能的主要因素。
影響GR性能主要因素：
- 網絡帶寬
在寫節(jié)點上產生的事務，在最終被commit前，需要發(fā)送到復制組中做沖突校驗，這需要消耗網絡帶寬，并給事務的延遲至少增加一個RTT(Round Trip Time,TCP數據包旅行一個回路的時間)。 - 校驗吞吐量
事務會被按照相同的順序發(fā)送到各節(jié)點做沖突校驗，校驗通過后會被遠端節(jié)點寫入relay-log，這個寫入是由一個單線程負責。當校驗的速率很高，磁盤吞吐量（relay-log寫入）將會成為瓶頸。 - 讀節(jié)點applier線程應用效率
讀節(jié)點的applier線程的應用不及時會觸發(fā)writer節(jié)點flow-control，對于多主模式架構，applier線程的低效可能會造成校驗失敗率升高。
GR性能瓶頸主要存在上面三個方面，有些是需要提升物理硬件，有些則是參數調整。我們來分析下針對每一個方面的優(yōu)化措施。
網絡因素：
使用高帶寬低延遲網絡，使所有節(jié)點都處于同一網關
-
減少帶寬消耗，如采取啟用壓縮,盡量縮小binlog等措施
group_replication_compression_threshold=1000000 # default in mysql8.0.11 binlog_row_image=MINIMALgroup_replication_compression_threshold 當復制組間通信的event超過這一閾值時，啟用LZ4壓縮，以減小通信量。
binlog_row_image默認是full,即將某行數據的改變前(before)和改變后(after)的數據都寫入binlog.實際上只有update才會產生改變前和改變后兩個數據鏡像，而對于insert只會有改變后的數據鏡像，delete只會有改變前的數據鏡像。如果每個表都有primary key(表定義在主從架構中完全相同，group replication要求表必須有主鍵),完全可以在binlog中的before鏡像中記入主鍵值（它已經能唯一標識數據改變的行了），而在after鏡像中只記錄所改變的字段的值，而不是所有的字段的值。這樣binlog就大大縮小，網絡間通信量也就大大減少了。只是在從節(jié)點應用這樣的binlog event時，效率會有點低。
-
通過頻繁等待，減少group replication線程睡眠次數
SET GLOBAL group_replication_poll_spin_loops= 10000; # default 0這樣可使GCT(Group Comunitcatoin Thread)積極地在消息隊列處等待，一旦隊列中有新消息可以更快地響應。同時也降低了操作系統(tǒng)對其上下文切換頻率。
校驗速率：
- 可以使用single-primary模式，因為正常情況下，這種模式是不需要校驗的（有一種情況除外，就是新master正在應用從之前的primary復制來的binlog，這種情況下是需要校驗的），但這種模式下，一旦primary宕機，需要選舉一個新的master,多了一個選舉的過程。
- 將relay-log，tmpdir 置于高性能硬盤, 校驗通過后非local_transaction要寫入relay log，對于大事務writeset的抽取可能會需要寫入磁盤臨時文件，如果relay log/臨時文件讀寫性能很差，將會大大增加事務的延時。在這兩個地方可能產生物理IO瓶頸。
- 對于多主架構減少校驗的復雜度
事務在節(jié)點執(zhí)行完成，commit前發(fā)送到GR做校驗。校驗成功后，GR會給此事務分配一個GTID（如果該事務沒有GTID）。GR會給每個節(jié)點預留一個范圍的GTID，（GTID是由server_uuid+數字組成，gr中GTID中的UUID部分都是一樣的，數字部分則為各節(jié)點分配一個范圍段，用完了再分配一個新的范圍段）。這個范圍段的大小就是有group_replication_gtid_assignment_block_size變量控制，默認是1000000。這個數字范圍如果很大的話，gtid_executed就不能及時合并,許多GTID interval 會使校驗算法變得復雜。group_replication_gtid_assignment_block_size=1000000 # default
Applier應用線程
- 啟用MTS多線程應用
set global slave_parallel_type=LOGICAL_CLOCK;
set global slave_parallel_workers=8/16/32/+;
set global slave_preserve_commit_order=ON;
- 啟用基于寫集依賴的多線程應用，使并發(fā)效率更高
# for mysql8
binlog_transaction_dependency_tracking=WRITESET
Applier線程的高效應用對提升集群性能非常重要。因為Applier 線程應用不及時可能會觸發(fā)writer節(jié)點啟用flow control,直接影響性能。除此之外，它對校驗也會有重要的影響。因為Applier 的及時應用可以使transaction_commit_on_all_memebers及時跟進，stable set 更加接近最新的事務。這會使校驗集合（Certification_info）中的無用的快照版本被及時垃圾回收，從而降低了校驗的復雜度，提高了整體性能的吞吐量。這是一個很重要的優(yōu)化策略！
總結
根據group replication的實現原理，其瓶頸主要產生于三點：
- 復制組間通信（高帶寬網絡）
- 事務在各節(jié)點的校驗
- Applier應用效率
優(yōu)化的思路也是主要集中在這三個方向。每次調整參數都應壓測對比效果，確保理論符合實際。盲目根據理論調優(yōu)而不壓測對比是不可取的。一套優(yōu)化方案，都是經過反復調參反復壓測而得出的最終結果。
參考資料：
之前讀過一篇文章，寫的很好，現在找不到了，很抱歉！
