Group Replication Requirements
要用於組複製的服務器實例必須滿足以下要求。
基礎設施
InnoDB Storage Engine. 數據必須存儲在InnoDB事務存儲引擎中。事務以樂觀的方式執行，然後在提交時檢查衝突。如果存在衝突，爲了保持整個組的一致性，某些事務將回滾。這意味着需要事務存儲引擎。此外，InnoDB提供了一些額外的功能，當與組複製一起操作時，可以更好地管理和處理衝突。
Primary Keys. 組複製的每個表都必須定義一個顯式主鍵。主鍵通過精確地識別每個事務已經修改了哪些行，在確定哪些事務發生衝突時起着極其重要的作用。
IPv4 Network. MySQL組複製使用的組通信引擎僅支持IPv4。因此，組複製需要IPv4網絡基礎結構。
Network Performance. 組複製設計爲部署在集羣環境中，其中服務器實例彼此非常接近，並受網絡延遲和網絡帶寬的影響。
服務器實例配置
必須在作爲組成員的服務器實例上配置以下選項。
Binary Log Active. 啓動binlog
Slave Updates Logged. Log_slave_updates設置爲1
Binary Log Row Format. Binlog_format設置爲row
Global Transaction Identifiers On. 啓用gtid
Replication Information Repositories.設置--master-info-repository=TABLE 和 --relay-log-info-repository=TABLE來保證複製元數據的一致性
Transaction Write Set Extraction.
設置 --transaction-write-set-extraction=XXHASH64保證產生寫集合
Limitations
組複製存在以下已知的限制。
Replication Event Checksums.
由於複製事件校驗和的設計限制，組複製當前無法使用它們。因此設置--binlog-checksum = NONE。
Gap Locks.
認證過程沒有考慮間隙鎖，因爲有關間隙鎖的信息在InnoDB之外不可用。組複製建議將事務隔離級別設置爲read commit
Table Locks and Named Locks.
認證過程不支持表鎖和名稱鎖，即lock tables，unlock tables和get_lock()
Savepoints Not Supported. 不支持保存點
SERIALIZABLE Isolation Level.
不支持SERIALIZABLE的事務隔離級別
Concurrent DDL versus DML Operations.
使用多主模式時，不支持在同一對象上但在不同服務器上執行併發數據定義語句和數據操作語句。在對象上執行數據定義語言（DDL）語句期間，在同一對象上但在不同的服務器實例上執行併發數據操作語言（DML）時，可能會在未檢測到的不同實例上執行衝突的DDL。
Foreign Keys with Cascading Constraints.
多主模式組（所有配置爲group_replication_single_primary_mode = OFF的成員）不支持具有多級外鍵依賴關係的表，特別是已定義了CASCADING外鍵約束的表。這是因爲導致由多主模式組執行的級聯操作的外鍵約束可能導致未檢測到的衝突，並且導致該組的成員之間的不一致的數據。因此，我們建議在多主模式組中使用的服務器實例上設置group_replication_enforce_update_everywhere_checks = ON，以避免未檢測到的衝突。