MySQL 8.0 参考手册  / 第十八章 组复制  / 18.3 要求和限制  /  17.3.2 组复制限制

17.3.2 组复制限制

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

小费

组复制建立在基于 GTID 的复制之上,因此您还应该了解 第 16.1.3.6 节,“使用 GTID 进行复制的限制”

  • 缝隙锁。  Group Replication 的并发事务认证过程不考虑 间隙锁,因为关于间隙锁的信息在 之外不可用 InnoDB。有关详细信息,请参阅 间隙锁

    笔记

    REPEATABLE READ对于多主模式下的组,除非您在应用程序中 依赖 语义,否则我们建议使用READ COMMITTEDGroup Replication 的隔离级别。InnoDB 不使用间隙锁READ COMMITTED,这使得 InnoDB 内部的本地冲突检测与 Group Replication 执行的分布式冲突检测保持一致。对于单主模式的组,只有主接受写入,因此READ COMMITTED隔离级别对组复制并不重要。

  • 表锁和命名锁。  认证过程不考虑表锁(请参阅第 13.3.5 节,“LOCK TABLES 和 UNLOCK TABLES 语句”)或命名锁(请参阅参考资料GET_LOCK())。

  • 复制事件校验和。  由于复制事件校验和的设计限制,Group Replication 目前无法使用它们。因此设 --binlog-checksum=NONE

  • 可串行化隔离级别。  SERIALIZABLE默认情况下,多主组不支持隔离级别。设置事务隔离级别来 SERIALIZABLE配置 Group Replication 以拒绝提交事务。

  • 并发 DDL 与 DML 操作。  使用多主模式时,不支持针对同一对象但在不同服务器上执行的并发数据定义语句和数据操作语句。在对象上执行数据定义语言 (DDL) 语句期间,在同一对象但在不同的服务器实例上执行并发数据操作语言 (DML) 存在在未检测到的不同实例上执行的冲突 DDL 的风险。

  • 具有级联约束的外键。  多主模式组(成员都配置了 group_replication_single_primary_mode=OFF)不支持多级外键依赖的表,特别是定义了 CASCADING 外键约束的表。这是因为导致多主模式组执行级联操作的外键约束可能导致未检测到的冲突,并导致组成员之间的数据不一致。因此,我们建议 group_replication_enforce_update_everywhere_checks=ON 在多主模式组中使用的服务器实例上进行设置,以避免未检测到的冲突。

    在单主模式下,这不是问题,因为它不允许并发写入组的多个成员,因此不存在未检测到的冲突风险。

  • MySQL 企业审计和 MySQL 企业防火墙。  在版本 5.7.21 之前,MySQL Enterprise Audit 和 MySQL Enterprise Firewall 使用 系统数据库MyISAM中的表 。mysql组复制不支持MyISAM表。

  • 多主模式死锁。  当一个组在多主模式下运行时, SELECT .. FOR UPDATE语句可能会导致死锁。这是因为锁未在组成员之间共享,因此可能无法达到对此类语句的期望。

  • 复制过滤器。  复制过滤器不能在为组复制配置的 MySQL 服务器实例上使用,因为在某些服务器上过滤事务会使组无法就一致状态达成一致。

团体人数限制

可以成为单个复制组成员的 MySQL 服务器的最大数量是 9。如果更多成员试图加入该组,他们的请求将被拒绝。这个限制已经从测试和基准测试中确定为一个安全边界,在该边界中,该组可以在稳定的局域网上可靠地运行。

交易规模限制

如果单个事务导致消息内容大到无法在 5 秒窗口内通过网络在组成员之间复制消息,则成员可以被怀疑失败,然后被驱逐,因为他们正忙于处理事务交易。由于内存分配问题,大型事务也可能导致系统变慢。为避免这些问题,请使用以下缓解措施:

  • 在可能的情况下,尝试限制交易的规模。例如,将使用的文件拆分LOAD DATA成更小的块。

  • 使用系统变量 group_replication_transaction_size_limit 指定组接受的最大交易大小。在 MySQL 5.7.37 及之前的版本中,此系统变量默认为零,但从 MySQL 5.7.38 开始,在 MySQL 8.0 中,它默认为最大事务大小 150000000 字节(大约 143 MB)。超过此限制的事务将被回滚,并且不会发送到组复制的组通信系统(GCS)以分发给组。根据您需要组容忍的最大消息大小调整此变量的值,请记住处理事务所花费的时间与其大小成正比。

    笔记

    当您从 MySQL 5.7.37 或更早版本升级到 MySQL 5.7.38 或更高版本时,如果您的组复制服务器先前接受了大于新默认限制的事务,并且您允许 group_replication_transaction_size_limit 默认为旧的零限制,那么这些事务将开始升级到新默认值后失败。您必须指定一个适当的大小限制以允许您需要组容忍的最大消息大小(这是推荐的解决方案),或者指定一个零设置以恢复以前的行为。

  • 使用系统变量 group_replication_compression_threshold 指定消息大小,超过该大小应用压缩。此系统变量默认为 1000000 字节 (1 MB),因此会自动压缩大消息。Group Replication 的 Group Communication System (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 处理消息后接收消息。超过此限制的消息在发起成员尝试广播时失败。