组复制限制

组复制存在以下已知限制。请注意，在故障转移事件期间，针对多主要模式组描述的限制和问题也可以适用于单主要模式集群，而新选举的主要对象会从旧的主要对象中清除其申请者队列。

组复制建立在基于GTID的复制之上，因此，您还应该注意“使用GTID进行复制的限制”。

• --upgrade=MINIMAL选项。使用MINIMAL选项（--upgrade=MINIMAL）的MySQL Server升级后，无法启动组复制，该选项不会升级复制内部依赖的系统表。

• 间隙锁。认证过程未考虑间隙锁，因为有关间隙锁的信息在之外无法获得InnoDB。有关更多信息，请参见间隙锁。

  注意

  除非您REPEATABLE READ在应用程序中依赖语义，否则建议将READ COMMITTED隔离级别与组复制一起使用。InnoDB不使用中的间隙锁READ COMMITTED，它使InnoDB中的本地冲突检测与组复制执行的分布式冲突检测对齐。

• 表锁和命名锁。认证过程未考虑表锁（请参见“ LOCK TABLES和UNLOCK TABLES语句”）或命名锁（请参见GET_LOCK()）。
• 复制事件校验和。由于复制事件校验和的设计限制，组复制当前无法使用它们。因此设置--binlog-checksum=NONE。
• 可隔离的隔离级别。SERIALIZABLE默认情况下，多主要组中不支持隔离级别。设置事务隔离级别以SERIALIZABLE将组复制配置为拒绝提交事务。
• 并行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_applier或group_replication_recovery通道上使用。

• 加密的连接。从MySQL 8.0.16开始，MySQL Server中提供了对TLSv1.3协议的支持，但前提是MySQL是使用OpenSSL 1.1.1或更高版本进行编译的。在MySQL 8.0.16和MySQL 8.0.17中，如果服务器支持TLSv1.3，则组通信引擎中不支持该协议，并且组复制不能使用该协议。组复制支持MySQL 8.0.18中的TLSv1.3，可将其用于组通信连接和分布式恢复连接。

  在MySQL 8.0.18中，TLSv1.3可以在组复制中用于分布式恢复连接，但是group_replication_recovery_tls_version和group_replication_recovery_tls_ciphersuites系统变量不可用。因此，施主服务器必须允许使用至少一个默认启用的TLSv1.3密码套件，如“加密连接TLS协议和密码”中所列。从MySQL 8.0.19开始，您可以使用这些选项来配置对任何密码套件选择的客户端支持，如果需要的话，仅包括非默认密码套件。

• 克隆操作。组复制启动并管理用于分布式恢复的克隆操作，但是已设置为支持克隆的组成员也可能参与用户手动启动的克隆操作。在MySQL 8.0.20之前的版本中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL 8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，DATA DIRECTORY如果正在运行组复制，则用于启动克隆操作的语句必须包含该子句。看到“其他用途的克隆”。

团体人数限制

可以成为一个复制组成员的MySQL服务器的最大数量为9。如果其他成员尝试加入该组，则其请求将被拒绝。从测试和基准测试中可以确定此限制是安全的边界，在此范围内，组可以在稳定的局域网上可靠地运行。

交易规模限制

如果单个事务导致消息内容足够大，以致于无法在5秒的时间内通过网络在组成员之间复制消息，则可能会怀疑成员失败了，然后将其驱逐出局，仅仅是因为他们正在忙于处理消息。交易。大型事务还会由于内存分配问题而导致系统变慢。为避免这些问题，请使用以下缓解措施：

• 如果由于大消息而发生不必要的驱逐，请使用系统变量group_replication_member_expel_timeout留出更多时间，以驱逐被怀疑失败的成员。您可以在最初的5秒检测期之后最多等待一个小时，然后才能将可疑成员从小组中驱逐出去。
• 在可能的情况下，请尝试限制事务的大小，然后再由组复制对其进行处理。例如，将用于的文件拆分LOAD DATA为较小的块。
• 使用系统变量group_replication_transaction_size_limit来指定组将接受的最大事务大小。在MySQL 8.0中，此系统变量的默认最大事务大小为150000000字节（约143 MB）。超过此大小的事务将回滚，并且不会发送到组复制的组通信系统（GCS）进行分发。请记住，处理事务所需的时间与其大小成正比，请根据需要该组允许的最大消息大小来调整此变量的值。
• 使用系统变量group_replication_compression_threshold来指定消息大小，在该消息大小之上进行压缩。该系统变量的默认值为1000000字节（1 MB），因此会自动压缩大消息。当组复制的组通信系统（GCS）收到group_replication_transaction_size_limit设置允许但超过group_replication_compression_threshold设置的消息时，将执行压缩。有关更多信息，请参见“消息压缩”。
• 使用系统变量group_replication_communication_max_message_size来指定消息大小，在该大小以上，消息将被分段。该系统变量的默认值为10485760字节（10 MiB），因此大型邮件会自动分段。如果压缩的消息仍超出group_replication_communication_max_message_size限制，则GCS会在压缩后执行分段操作。为了使复制组能够使用分段，所有组成员必须位于MySQL 8.0.16或更高版本，并且该组使用的“组复制”通信协议版本必须允许分段。有关更多信息，

通过为相关系统变量指定零值，可以停用最大事务大小，消息压缩和消息分段。如果您停用了所有这些保护措施，则复制组成员上的应用程序线程可以处理的消息的大小上限为该成员的值上限。slave_max_allowed_packet系统变量，其默认值为最大值1073741824字节（1 GB）。当接收成员尝试处理超过此限制的消息时，该消息将失败。组成员可以发起并尝试发送到该组的消息的最大大小限制为4294967295字节（大约4 GB）。这是组通信引擎接受的用于组复制（XCom，Paxos变体）的数据包大小的硬限制，它在GCS处理完消息后接收消息。当发起成员尝试广播超过此限制的消息时，该消息将失败。