组复制存在以下已知限制。请注意,为多主模式组描述的限制和问题也可能在单主模式集群中发生故障转移事件时适用,而新当选的主服务器从旧主服务器中刷新其应用队列。
组复制基于 GTID 复制构建,因此您还应了解 第 19.1.3.7 节,“使用 GTID 进行复制的限制”。
--upgrade=MINIMAL
选项。 在使用 MINIMAL 选项 (--upgrade=MINIMAL
) 升级 MySQL 服务器后,无法启动组复制,该选项不会升级复制内部依赖的系统表。间隙锁。 组复制的并发事务认证过程没有考虑 间隙锁,因为有关间隙锁的信息在
InnoDB
之外不可用。有关更多信息,请参阅 间隙锁。注意对于处于多主模式的组,除非您的应用程序依赖于
REPEATABLE READ
语义,否则我们建议在组复制中使用READ COMMITTED
隔离级别。InnoDB 在READ COMMITTED
中不使用间隙锁,这使 InnoDB 中的本地冲突检测与组复制执行的分布式冲突检测保持一致。对于处于单主模式的组,只有主服务器接受写入,因此READ COMMITTED
隔离级别对组复制并不重要。表锁和命名锁。 认证过程没有考虑表锁(请参阅 第 15.3.6 节,“LOCK TABLES 和 UNLOCK TABLES 语句”)或命名锁(请参阅
GET_LOCK()
)。二进制日志校验和。 MySQL 8.4 中的组复制支持校验和,因此组成员可以使用默认设置
binlog_checksum=CRC32
。binlog_checksum
的设置不必对组中的所有成员都相同。当校验和可用时,组复制不会使用它们来验证
group_replication_applier
通道上的传入事件,因为事件是从多个源写入该中继日志的,并且是在它们实际写入到源服务器的二进制日志之前,而此时会生成校验和。校验和用于验证group_replication_recovery
通道以及组成员上的任何其他复制通道上的事件的完整性。SERIALIZABLE 隔离级别。
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
通道。加密连接。 如果使用 OpenSSL 1.1.1 或更高版本编译,则 MySQL 支持 TLSv1.3 协议。组复制支持 TLSv1.3,其中它可用于组通信连接和分布式恢复连接。
group_replication_recovery_tls_version
和group_replication_recovery_tls_ciphersuites
可用于配置客户端对任何密码套件选择的支持,包括仅在需要时仅使用非默认密码套件。请参阅 第 8.3.2 节“加密连接 TLS 协议和密码”。克隆操作。 组复制启动和管理用于分布式恢复的克隆操作,但已配置为支持克隆的组成员也可以参与用户手动启动的克隆操作。如果操作涉及运行组复制的组成员,则可以手动启动克隆操作,前提是克隆操作不会删除和替换接收方的数据。因此,如果运行组复制,则启动克隆操作的语句必须包含
DATA DIRECTORY
子句。请参阅 第 20.5.4.2.4 节“用于其他目的的克隆”。
可以作为单个复制组成员的 MySQL 服务器最大数量为 9。如果进一步的成员尝试加入该组,则会拒绝他们的请求。此限制已通过测试和基准测试确定为一个安全边界,在该边界上,该组在稳定的局域网中可靠地执行。
如果单个事务导致的消息内容足够大,以至于消息无法在 5 秒窗口内通过网络在组成员之间复制,则成员可能会被怀疑已失败,然后被驱逐,仅仅是因为它们正在忙于处理事务。大型事务也会导致系统变慢,因为内存分配出现问题。为避免这些问题,请使用以下缓解措施
如果由于大型消息导致不必要的驱逐,请使用系统变量
group_replication_member_expel_timeout
以在驱逐被怀疑已失败的成员之前允许额外的时间。您可以在初始 5 秒检测期之后允许最多 1 小时,然后才能将可疑成员从组中驱逐。默认情况下,还会额外允许 5 秒。尽可能地,请尝试在事务由组复制处理之前限制事务的大小。例如,将与
LOAD DATA
一起使用的文件拆分为较小的块。使用系统变量
group_replication_transaction_size_limit
指定组接受的最大事务大小。默认最大事务大小为 150000000 字节(约 143 MB);超过此大小的事务将回滚,并且不会发送到组复制的组通信系统 (GCS) 以分发到组。根据您需要组容忍的最大消息大小调整此变量的值,请记住,处理事务所需的时间与其大小成正比。使用系统变量
group_replication_compression_threshold
指定应用压缩的消息大小。此系统变量默认为 1000000 字节 (1 MB),因此大型消息会自动压缩。当组通信系统 (GCS) 接收由group_replication_transaction_size_limit
设置允许但超过group_replication_compression_threshold
设置的消息时,GCS 会进行压缩。有关更多信息,请参阅 第 20.7.4 节“消息压缩”。使用系统变量
group_replication_communication_max_message_size
指定消息大小,超过此大小的消息将被分段。此系统变量默认为 10485760 字节 (10 MiB),因此大型消息会自动分段。如果压缩后的消息仍然超过group_replication_communication_max_message_size
限制,GCS 会在压缩后进行分段。有关更多信息,请参阅 第 20.7.5 节“消息分段”。
最大事务大小、消息压缩和消息分段都可以通过为相关系统变量指定零值来停用。如果您已停用所有这些保护措施,则复制组成员上的应用程序线程可以处理的消息的上限是成员的 replica_max_allowed_packet
系统变量的值,该变量的默认值和最大值为 1073741824 字节 (1 GB)。当接收成员尝试处理超过此限制的消息时,消息会失败。组成员可以发起并尝试传输到组的消息的上限为 4294967295 字节(约 4 GB)。这是组复制(XCom,Paxos 变体)的组通信引擎接受的包大小的硬性限制,该引擎在 GCS 处理消息后会接收消息。当发起成员尝试广播超过此限制的消息时,消息会失败。