MySQL 8.4 Release Notes
20.3.2 组复制限制
以下是 Group Replication 的已知限制。请注意，对于多主模式组群的限制和问题，也可以在单主模式集群中出现，特别是在故障转移事件中，而新选举的主服务器flushes out its applier queue from the old primary。
Tip
Group Replication 是基于 GTID 的 replication，因此您也应该了解第19.1.3.7节，“GTIDs 限制”。
-
--upgrade=MINIMAL选项。 Group Replication 无法在使用 MINIMAL 选项（--upgrade=MINIMAL）升级 MySQL Server 之后启动，因为该选项不升级 replication internals 依赖的系统表。 -
Gap Locks. Group Replication 的并发事务认证过程不考虑gap locks，因为 gap locks 信息在
InnoDB外部不可用。请参阅Gap Locks以获取更多信息。Note在多主模式的组中，除非您的应用程序依赖于
REPEATABLE READ语义，我们建议使用READ COMMITTED隔离级别与Group Replication。InnoDB在READ COMMITTED中不使用gap锁，这使得InnoDB的本地冲突检测与Group Replication的分布式冲突检测保持一致。在单主模式的组中，只有主服务器接受写入，所以READ COMMITTED隔离级别对Group Replication不重要。 -
表锁和命名锁 认证过程不考虑表锁（见第15.3.6节，“LOCK TABLES and UNLOCK TABLES Statements”)或命名锁（见
GET_LOCK()）。 -
二进制日志校验和 MySQL 8.4中的Group Replication支持校验和，所以组成员可以使用默认设置
binlog_checksum=CRC32。binlog_checksum的设置不需要在组中的所有成员相同。当 checksum 可用时，Group Replication 不会使用它们来验证
group_replication_applier通道上的 incoming 事件，因为这些事件来自多个来源，并且在写入到源服务器的二进制日志之前被写入到该中继日志中，这时才生成 checksum。checksums 在group_replication_recovery通道和 Group 成员上的其他复制通道上用于验证事件的完整性。 -
SERIALIZABLE隔离级别.
SERIALIZABLE隔离级别在多主组中默认不支持。将事务隔离级别设置为SERIALIZABLE配置 Group Replication 拒绝提交事务。 -
并发 DDL 与 DML 操作. 在使用多主模式时，执行相同对象但在不同服务器实例上的数据定义语句和数据操作语句不受支持。在对一个对象执行数据定义语言（DDL）语句期间，对同一个对象但在不同的服务器实例上执行数据操作语言（DML）语句存在冲突的风险，因为在不同实例上执行的 DDL 语句可能不会被检测到。
-
级联外键约束. 多主模式组（所有成员都配置了
group_Replication_single_primary_mode=OFF)不支持具有多级外键依赖关系的表，特别是那些定义了CASCADING外键约束的表。这是因为多主模式组中的外键约束可能会导致未检测到的冲突，从而在组中的成员之间引起不一致数据。因此，我们建议在用于多主模式组的服务器实例中设置group_Replication_enforce_update_everywhere_checks=ON以避免未检测到的冲突。在单主模式下，这不是问题，因为它不允许对组中的多个成员进行并发写入，因此没有风险出现未检测到的冲突。
-
多主模式死锁. 在多主模式下，
SELECT .. FOR UPDATE语句可能会导致死锁。这是因为锁不在组中的成员之间共享，因此对这种语句的期望可能不会被满足。 -
复制过滤器. 在 MySQL 服务器实例上配置 Group Replication 时，不能使用全局复制过滤器，因为在某些服务器上对事务进行 filtering 将使得组无法达成一致状态。可以在不直接参与 Group Replication 的复制渠道上使用通道特定的复制过滤器，例如，在一个组成员同时作为外部源的副本时。但不能在
group_replication_applier或group_Replication_recovery渠道上使用。 -
加密连接. MySQL 支持 TLSv1.3 协议，提供 OpenSSL 1.1.1 或更高版本编译时可用。Group Replication 支持 TLSv1.3，可以用于组通信连接和分布式恢复连接。
group_Replication_recovery_tls_version和group_Replication_recovery_tls_ciphersuites可以用来配置客户端支持任何选择的加密套件，包括只使用非默认加密套件。如果需要，请参阅第 8.3.2 节，“加密连接 TLS 协议和加密套件”。 -
克隆操作. Group Replication 初始化和管理分布式恢复的克隆操作，但已经设置为支持克隆的组成员也可以参与用户手动初始化的克隆操作。您可以手动初始化一个克隆操作，如果该操作涉及Group Replication正在运行的组成员，并且该操作不删除和替换接收方的数据。因此，需要在 Group Replication 运行时包含
DATA DIRECTORY子句。请参阅第20.5.4.2.4节，“克隆其他目的”。
MySQL 服务器组中的成员数量限制为9个。如果尝试加入的成员超过这个限制，请求将被拒绝。这一限制是通过测试和基准测试确定的，可以确保在稳定的局域网上组件性能可靠。
如果单个事务的消息内容太大，无法在5秒内在网络上复制到组成员之间，那么成员可能会被认为已经失败，并且被驱逐。大量的事务也可以导致系统由于内存分配问题而变慢，以避免这些问题，请使用以下缓解措施：
-
如果由于大型消息而发生不必要的驱逐，可以使用系统变量
group_ replication_member_expel_timeout来允许在成员被怀疑失败前额外的时间。您可以在初始5秒检测期后允许最多1小时的时间来驱逐suspect成员。默认情况下，额外5秒是允许的。 -
尽量限制Group Replication处理的事务大小。在使用
LOAD DATA时，例如，可以将文件分割成更小的块。 -
使用系统变量
group_ replication_transaction_size_limit指定组接受的最大事务大小。默认情况下，最大事务大小为150000000字节（约143MB）；超过这个大小的事务将被回滚，不会发送到Group Replication的Group Communication System（GCS）中进行分配给组。根据您需要组容忍的最大消息大小调整该变量的值，考虑事务处理时间与其大小成正比关系。 -
使用系统变量
group_replication_compression_threshold指定压缩的消息大小上限。这个系统变量默认为1000000字节（1MB），因此大消息自动被压缩。GCS在接收允许的group_replication_transaction_size_limit设置的消息，但超过group_Replication_compression_threshold设置时，进行压缩。更多信息，请见第20.7.4节，“消息压缩”。 -
使用系统变量
group_Replication_communication_max_message_size指定消息大小上限以上的消息将被分割。这系统变量默认为10485760字节（10MiB），因此大消息自动被分割。GCS在压缩后，如果压缩后的消息仍然超过group_Replication_communication_max_message_size限制时，进行分割。更多信息，请见第20.7.5节，“消息分割”。
可以通过将相关系统变量的值设置为零来停用事务大小限制、消息压缩和消息分片。 如果您已经停用了所有这些安全措施，复制组成员的应用线程可以处理的最大消息大小将是该成员的replica_max_allowed_packet系统变量的值，该变量的默认和最大值为1073741824字节（1 GB）。当接收成员尝试处理该消息时，超过这个限制的消息将失败。复制组成员可以originate并尝试将消息传输到组中的最大消息大小为4294967295字节（约4 GB）。这是在Group Replication（XCom，Paxos变体）中接受消息的群组通信引擎对包大小的硬限制，该引擎在GCS处理完消息后接收消息。超过这个限制的消息将失败，当originate成员尝试广播该消息时。