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

1. 參數(shù)選項(xiàng)設(shè)置

下面是幾個(gè)MGR相關(guān)參數(shù)選項(xiàng)設(shè)置建議：

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

#不要啟用引導(dǎo)模式
loose-group_replication_bootstrap_group=OFF 

#默認(rèn)值150MB，但建議調(diào)低在20MB以內(nèi)，不要使用大事務(wù)
loose-group_replication_transaction_size_limit = 10M

#大消息分片處理，每個(gè)分片10M，避免網(wǎng)絡(luò)延遲太大
loose-group_replication_communication_max_message_size = 10M

#節(jié)點(diǎn)退出后的默認(rèn)行為，將本節(jié)點(diǎn)設(shè)置為RO模式
loose-group_replication_exit_state_action = READ_ONLY

#超過多長時(shí)間收不到廣播消息就認(rèn)定為可疑節(jié)點(diǎn)，如果網(wǎng)絡(luò)環(huán)境不好，可以適當(dāng)調(diào)高
loose-group_replication_member_expel_timeout = 5

#建議關(guān)閉MySQL流控機(jī)制
loose-group_replication_flow_control_mode = "DISABLED"

#AFTER模式下，只要多數(shù)派達(dá)成一致就可以，不需要全部節(jié)點(diǎn)一致
loose-group_replication_majority_after_mode = ON

#是否設(shè)置為仲裁節(jié)點(diǎn)
loose-group_replication_arbitrator = 0

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

#當(dāng)MGR層耗時(shí)超過100ms就記錄日志，確認(rèn)是否MGR層的性能瓶頸問題
loose-group_replication_request_time_threshold = 100

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

2. MGR相關(guān)約束

下面是關(guān)于MGR使用的一些限制：

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

看起來限制有點(diǎn)多，但絕大多數(shù)時(shí)候并不影響正常的業(yè)務(wù)使用。

此外，想要啟用MGR還有幾個(gè)要求：

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

slave_parallel_type = LOGICAL_CLOCK

slave_parallel_workers = N，N>0，可以設(shè)置為邏輯CPU數(shù)的2倍

binlog_transaction_dependency_tracking = WRITESET

• slave_preserve_commit_order = 1

slave_checkpoint_period = 2

3. MGR使用建議

在使用MGR時(shí)，有以下幾個(gè)建議：

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

參考資料、文檔

MySQL 8.0 Reference Manual()

數(shù)據(jù)庫內(nèi)核開發(fā) - 溫正湖()

Group Replication原理 - 宋利兵()