17.7.2 组复制限制
组复制存在以下已知限制。请注意，在故障转移事件期间，针对多主要模式组描述的限制和问题也可以适用于单主要模式集群，而新选举的主要对象会从旧的主要对象中清除其申请者队列。
Tip
组复制构建在基于 GTID 的复制之上，因此您还应该注意第 16.1.3.6 节，“使用 GTID 复制的限制”。
Note
对于处于多主模式的组，除非您在应用程序中依赖REPEATABLE READ语义，否则我们建议对组复制使用READ COMMITTED隔离级别。 InnoDB 不使用READ COMMITTED中的间隙锁，该间隙将 InnoDB 中的本地冲突检测与组复制执行的分布式冲突检测对齐。对于单主模式的组，只有主模式接受写操作，因此READ COMMITTED隔离级别对组复制并不重要。
-
table 锁和命名锁. 认证过程未考虑 table 锁(请参见第 13.3.5 节“ LOCK TABLES 和 UNLOCK TABLES 语句”)或命名锁(请参见GET_LOCK())。
-
复制事件校验和. 由于复制事件校验和的设计限制，组复制当前无法使用它们。因此设置--binlog-checksum=NONE。
-
SERIALIZABLE 隔离级别. 默认情况下，多主要组不支持SERIALIZABLE隔离级别。将事务隔离级别设置为
SERIALIZABLE可以将组复制配置为拒绝提交事务。 -
并发 DDL 与 DML 操作. 当使用多主模式时，不支持针对同一对象但在不同服务器上执行的并发数据定义语句和数据操作语句。在对象上执行数据定义语言(DDL)语句期间，在同一对象上但在不同服务器实例上执行并发数据操作语言(DML)可能会导致未检测到在不同实例上执行的 DDL 冲突的风险。
-
具有级联约束的外键. 多主模式组(成员均配置为group_replication_single_primary_mode=OFF)不支持具有多级外键依赖关系的 table，尤其是定义了
CASCADING外键约束的 table。这是因为导致由多主模式组执行级联操作的外键约束可能导致无法检测到的冲突，并导致该组成员之间的数据不一致。因此，我们建议在多主要模式组中使用的服务器实例上设置group_replication_enforce_update_everywhere_checks=ON，以避免未检测到的冲突。
在单主模式下，这不是问题，因为它不允许同时写入组中的多个成员，因此不存在未检测到冲突的风险。
- MySQL Enterprise Audit 和 MySQL Enterprise Firewall. 在 5.7.21 版之前，MySQL Enterprise Audit 和 MySQL Enterprise Firewall 在
mysql系统数据库中使用MyISAMtable。组复制不支持MyISAMtable。
-
多主模式死锁. 当组以多主模式运行时，
SELECT .. FOR UPDATE语句可能导致死锁。这是因为该锁未在组的成员之间共享，因此可能无法达到此类声明的期望。 -
复制过滤器. 复制过滤器不能在为组复制配置的 MySQL 服务器实例上使用，因为在某些服务器上过滤事务将使组无法在一致状态下达成协议。
Groups 人数上限
可以成为一个复制组成员的 MySQL 服务器的最大数量为 9.如果其他成员尝试加入该组，则其请求将被拒绝。从测试和基准测试中可以确定此限制是安全的边界，在此范围内，组可以在稳定的局域网上可靠地运行。
Transaction 规模限制
如果单个事务产生的消息内容足够大，以致于无法在 5 秒的时间内通过网络在组成员之间复制消息，则可能会怀疑成员失败了，然后将其驱逐出局，只是因为他们正在忙于处理消息。Transaction。大型事务还会由于内存分配问题而导致系统变慢。为避免这些问题，请使用以下缓解措施：
-
尽可能尝试限制 Transaction 量。例如，将用于
LOAD DATA的文件拆分为较小的块。 -
使用系统变量group_replication_transaction_size_limit指定组将接受的最大事务大小。在 MySQL 5.7 中，此系统变量默认为零，但在 MySQL 8.0 中，默认为最大事务大小为 150000000 字节(约 143 MB)。超过此限制的事务将回滚，并且不会发送到组复制的组通信系统(GCS)进行分发。请记住，处理事务所需的时间与其大小成正比，请根据需要该组允许的最大消息大小来调整此变量的值。
-
使用系统变量group_replication_compression_threshold指定消息大小，在该消息大小之上进行压缩。该系统变量的默认值为 1000000 字节(1 MB)，因此会自动压缩大消息。当组复制的组通信系统(GCS)收到group_replication_transaction_size_limit设置允许但超过group_replication_compression_threshold设置的消息时，将执行压缩。如果将系统变量值设置为零，则将禁用压缩。有关更多信息，请参见第 17.9.7.2 节“消息压缩”。
如果您已停用消息压缩并且未指定最大事务大小，则复制组成员上的应用程序线程可以处理的消息的大小上限为成员的slave_max_allowed_packet系统变量的值，该变量具有一个默认值和最大值 1073741824 字节(1 GB)。当接收成员尝试处理超过此限制的消息时，该消息将失败。组成员可以发起并尝试传输到该组的消息的大小上限为 4294967295 字节(大约 4 GB)。这是组通信引擎接受的用于组复制(XCom，Paxos 变体)的数据包大小的硬限制，它在 GCS 处理完消息后接收消息。当发起成员尝试 Broadcast 超过此限制的消息时，该消息将失败。