本文介紹MGR最佳實踐參考以及使用MGR的約束限制。

1. 參數選項設置

下面是幾個MGR相關參數選項設置建議：

#建議只用單主模式
loose-group_replication_single_primary_mode=ON

#不要啟用引導模式
loose-group_replication_bootstrap_group=OFF 

#默認值150MB，但建議調低在20MB以內，不要使用大事務
loose-group_replication_transaction_size_limit = 10M

#大消息分片處理，每個分片10M，避免網絡延遲太大
loose-group_replication_communication_max_message_size = 10M

#節點退出后的默認行為，將本節點設置為RO模式
loose-group_replication_exit_state_action = READ_ONLY

#超過多長時間收不到廣播消息就認定為可疑節點，如果網絡環境不好，可以適當調高
loose-group_replication_member_expel_timeout = 5

#建議關閉MySQL流控機制
loose-group_replication_flow_control_mode = "DISABLED"

#AFTER模式下，只要多數派達成一致就可以，不需要全部節點一致
loose-group_replication_majority_after_mode = ON

#是否設置為仲裁節點
loose-group_replication_arbitrator = 0

#啟用快速單主模式
loose-group_replication_single_primary_fast_mode = 1

#當MGR層耗時超過100ms就記錄日志，確認是否MGR層的性能瓶頸問題
loose-group_replication_request_time_threshold = 100

#記錄更多日志信息，便于跟蹤問題
log_error_verbosity=3

2. MGR相關約束

下面是關于MGR使用的一些限制：

• 所有表必須是InnoDB引擎。可以創建非InnoDB引擎表，但無法寫入數據，在利用Clone構建新節點時也會報錯（在GreatSQL中，可以設置選項enforce_storage_engine = InnoDB 只允許使用InnoDB引擎，而禁用其他引擎）。
• 所有表都必須要有主鍵。同上，能創建沒有主鍵的表，但無法寫入數據，在利用Clone構建新節點時也會報錯。
• 盡量不要使用大事務，默認地，事務超過150MB會報錯，最大可支持2GB的事務（在GreatSQL未來的版本中，會增加對大事務的支持，提高大事務上限，但依然不建議運行大事務）。
• 如果是從舊版本進行升級，則不能選擇 MINIMAL 模式升級，建議選擇 AUTO 模式，即upgrade=AUTO。
• 由于MGR的事務認證線程不支持gap lock，因此建議把所有節點的事務隔離級別都改成 READ COMMITTED。基于相同的原因，MGR集群中也不要使用 table lock 及 name lock（即 GET_LOCK() 函數 ）。
• 在多主（multi-primary）模式下不支持串行（SERIALIZABLE）隔離級別。
• 不支持在不同的MGR節點上，對同一個表分別執行DML和DDL，可能會造成數據丟失或節點報錯退出。
• 在多主（multi-primary）模式下不支持多層級聯外鍵表。另外，為了避免因為使用外鍵造成MGR報錯，建議設置 group_replication_enforce_update_everywhere_checks=ON。
• 在多主（multi-primary）模式下，如果多個節點都執行 SELECT ... FOR UPDATE 后提交事務會造成死鎖。
• 不支持復制過濾（Replication Filters）設置。

看起來限制有點多，但絕大多數時候并不影響正常的業務使用。

此外，想要啟用MGR還有幾個要求：

• 每個節點都要啟用binlog。
• 每個節點都要轉存binlog，即設置log_slave_updates=1。
• binlog format務必是row模式，即binlog_format=ROW。
• 每個節點的server_id 及 server_uuid 不能相同。
• 在8.0.20之前，要求binlog_checksum=NONE，但是從8.0.20后，可以設置 binlog_checksum=CRC32。
• 要求啟用 GTID，即設置gtid_mode=ON。
• 要求master_info_repository=TABLE 及 relay_log_info_repository=TABLE，不過從MySQL 8.0.23開始，這兩個選項已經默認設置TABLE，因此無需再單獨設置。
• 所有節點上的表名大小寫參數lower_case_table_names 設置要求一致。
• 最好在局域網內部署MGR，而不要跨公網，網絡延遲太大的話，會導致MGR性能很差或很容易出錯。
• 建議啟用writeset模式，即設置以下幾個參數

slave_parallel_type = LOGICAL_CLOCK

slave_parallel_workers = N，N>0，可以設置為邏輯CPU數的2倍

binlog_transaction_dependency_tracking = WRITESET

• slave_preserve_commit_order = 1

slave_checkpoint_period = 2

3. MGR使用建議

在使用MGR時，有以下幾個建議：

• 不同版本不要混用，尤其是不同大版本不要混用，要盡快完成升級。
• 對同一個表的DDL和DML都只在同一個節點，否則可能會造成節點意外退出MGR。
• 不要跑大事務，每個事務盡量控制在10MB以內。

參考資料、文檔

MySQL 8.0 Reference Manual()

數據庫內核開發 - 溫正湖()

Group Replication原理 - 宋利兵()