建站
咨詢
售后
建站咨詢
新聞中心
這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
深入淺出MGR，你明白了嗎？
本文介紹MGR最佳實踐參考以及使用MGR的約束限制。
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、成都微信小程序、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了葫蘆島免費建站歡迎大家使用！
1. 參數(shù)選項設(shè)置
下面是幾個MGR相關(guān)參數(shù)選項設(shè)置建議：
#建議只用單主模式
loose-group_replication_single_primary_mode=ON
#不要啟用引導(dǎo)模式
loose-group_replication_bootstrap_group=OFF
#默認值150MB，但建議調(diào)低在20MB以內(nèi)，不要使用大事務(wù)
loose-group_replication_transaction_size_limit = 10M
#大消息分片處理，每個分片10M，避免網(wǎng)絡(luò)延遲太大
loose-group_replication_communication_max_message_size = 10M
#節(jié)點退出后的默認行為，將本節(jié)點設(shè)置為RO模式
loose-group_replication_exit_state_action = READ_ONLY
#超過多長時間收不到廣播消息就認定為可疑節(jié)點，如果網(wǎng)絡(luò)環(huán)境不好，可以適當(dāng)調(diào)高
loose-group_replication_member_expel_timeout = 5
#建議關(guān)閉MySQL流控機制
loose-group_replication_flow_control_mode = "DISABLED"
#AFTER模式下，只要多數(shù)派達成一致就可以，不需要全部節(jié)點一致
loose-group_replication_majority_after_mode = ON
#是否設(shè)置為仲裁節(jié)點
loose-group_replication_arbitrator = 0
#啟用快速單主模式
loose-group_replication_single_primary_fast_mode = 1
#當(dāng)MGR層耗時超過100ms就記錄日志，確認是否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é)點時也會報錯（在GreatSQL中，可以設(shè)置選項enforce_storage_engine = InnoDB 只允許使用InnoDB引擎，而禁用其他引擎）。
- 所有表都必須要有主鍵。同上，能創(chuàng)建沒有主鍵的表，但無法寫入數(shù)據(jù)，在利用Clone構(gòu)建新節(jié)點時也會報錯。
- 盡量不要使用大事務(wù)，默認地，事務(wù)超過150MB會報錯，最大可支持2GB的事務(wù)（在GreatSQL未來的版本中，會增加對大事務(wù)的支持，提高大事務(wù)上限，但依然不建議運行大事務(wù)）。
- 如果是從舊版本進行升級，則不能選擇 MINIMAL 模式升級，建議選擇 AUTO 模式，即upgrade=AUTO。
- 由于MGR的事務(wù)認證線程不支持gap lock，因此建議把所有節(jié)點的事務(wù)隔離級別都改成 READ COMMITTED?；谙嗤脑?，MGR集群中也不要使用 table lock 及 name lock（即 GET_LOCK() 函數(shù) ）。
- 在多主（multi-primary）模式下不支持串行（SERIALIZABLE）隔離級別。
- 不支持在不同的MGR節(jié)點上，對同一個表分別執(zhí)行DML和DDL，可能會造成數(shù)據(jù)丟失或節(jié)點報錯退出。
- 在多主（multi-primary）模式下不支持多層級聯(lián)外鍵表。另外，為了避免因為使用外鍵造成MGR報錯，建議設(shè)置 group_replication_enforce_update_everywhere_checks=ON。
- 在多主（multi-primary）模式下，如果多個節(jié)點都執(zhí)行 SELECT ... FOR UPDATE 后提交事務(wù)會造成死鎖。
- 不支持復(fù)制過濾（Replication Filters）設(shè)置。
看起來限制有點多，但絕大多數(shù)時候并不影響正常的業(yè)務(wù)使用。
此外，想要啟用MGR還有幾個要求：
- 每個節(jié)點都要啟用binlog。
- 每個節(jié)點都要轉(zhuǎn)存binlog，即設(shè)置log_slave_updates=1。
- binlog format務(wù)必是row模式，即binlog_format=ROW。
- 每個節(jié)點的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開始，這兩個選項已經(jīng)默認設(shè)置TABLE，因此無需再單獨設(shè)置。
- 所有節(jié)點上的表名大小寫參數(shù)lower_case_table_names 設(shè)置要求一致。
- 最好在局域網(wǎng)內(nèi)部署MGR，而不要跨公網(wǎng)，網(wǎng)絡(luò)延遲太大的話，會導(dǎo)致MGR性能很差或很容易出錯。
- 建議啟用writeset模式，即設(shè)置以下幾個參數(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時，有以下幾個建議：
- 不同版本不要混用，尤其是不同大版本不要混用，要盡快完成升級。
- 對同一個表的DDL和DML都只在同一個節(jié)點，否則可能會造成節(jié)點意外退出MGR。
- 不要跑大事務(wù)，每個事務(wù)盡量控制在10MB以內(nèi)。
參考資料、文檔
MySQL 8.0 Reference Manual()
數(shù)據(jù)庫內(nèi)核開發(fā) - 溫正湖()
Group Replication原理 - 宋利兵()
網(wǎng)頁題目：深入淺出MGR，你明白了嗎？
文章來源：http://www.dlmjj.cn/article/cdieppc.html
