組複制官方翻譯七、Requirements and Limitations

https://dev.mysql.com/doc/refman/8.0/en/group-replication-requirements-and-limitations.html

關于Group Replication System Variables這一節沒有講，主要是變量屬于工具類，需要檢視的時候去搜一下即可

https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html

18.8.1 Group Replication Requirements

需要使用MGR的執行個體必須滿足如下要求

基礎設施

• InnoDB存儲引擎
• 主鍵
• 網絡性能

執行個體配置

• 開啟binlog
• log-slave-update=on
• binlog必須是row格式
• GTID=on
• 複制資訊必須以table存儲 --master-info-repository=TABLE and --relay-log-info-repository=TABLE
• 事務寫集 --transaction-write-set-extraction=XXHASH64
• 多線程複制開啟

1.  slave_parallel_type=LOGICAL_CLOCK
2.  slave_preserve_commit_order=1
3.  slave_parallel_workers= （0~1024）  ## 可以配置使用多線程，也可以不使用多線程

           

18.8.2 Group Replication Limitations

下面列了一些已知的MGR的限制

注意：由于MGR是在GTID的基礎上建構的，是以GTID的限制也同樣是MGR的限制 Section 17.1.3.6, “Restrictions on Replication with GTIDs”.

• 複制event的checksums --binlog-checksum=NONE

由于設計的問題，MGR不能使用event的checksums

--binlog-checksum=NONE 必須這樣設定
           

• Gap locks ， 建議設定隔離級别為 READ COMMITTED

由于認證階段無法使用gap lock，是以建議使用隔離級别為READ COMMITTED，READ COMMITTED 不适用gap locks
           

• SERIALIZABLE , MGR不支援SERIALIZABLE隔離級别
• 并發DDL和DML在同一個對象上的操作，會有問題

舉例：
    A執行個體 表t進行DDL
    B執行個體 表t進行dml
    會導緻沖突無法檢測到，會有很高的風險
    這種情況一般在multi-primary模式下容易遇到（因為多執行個體寫嘛的原因嘛），是以DDL要特别小心           

• 外鍵級聯限制
• 大事務

在5秒鐘的世界視窗中如果無法将事務copy到其他成員的話，那麼MGR的通信會失敗，重傳，會有嚴重影響
建議切分、限制 事務大小
           

• multi-primary的死鎖檢測

多主模式下，如果使用SELECT .. FOR UPDATE 會導緻死鎖

主要是lock無法跨越多伺服器
           

• 複制過濾

MGR中不要使用任何複制的filter