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，以避免未检测到的冲突。