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