# 18.3.2 组复制限制

组复制存在以下已知限制。Note that the limitations and issues described for multi-primary mode groups can also apply in single-primary mode clusters during a failover event, while the newly elected primary flushes out its applier queue from the old primary.

提示

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

  • **--升级=最小选项。**使用 MINIMAL 选项 (--升级=最小),它不会升级复制内部依赖的系统表。

  • **间隙锁。**Group Replication 对并发事务的认证过程不考虑间隙锁,因为有关间隙锁的信息在外部不可用InnoDB.看间隙锁了解更多信息。

    笔记

    对于多主模式下的组,除非您依赖可重复阅读在您的应用程序中使用语义,我们建议使用阅读已提交组复制的隔离级别。InnoDB 不使用间隙锁阅读已提交,它将 InnoDB 中的本地冲突检测与 Group Replication 执行的分布式冲突检测对齐。对于单主模式的组,只有主节点接受写入,所以阅读已提交隔离级别对组复制并不重要。

  • **表锁和命名锁。**认证过程不考虑表锁(见第 13.3.6 节,“LOCK TABLES 和 UNLOCK TABLES 语句”)或命名锁(见GET_LOCK())。

  • **二进制日志校验和。**直到并包括 MySQL 8.0.20,Group Replication 不能使用校验和并且不支持它们在二进制日志中的存在,因此您必须设置binlog_checksum=NONE将服务器实例配置为组成员时。从 MySQL 8.0.21 开始,Group Replication 支持校验和,因此组成员可以使用默认设置binlog_checksum=CRC32.设置为binlog_checksum不必对组的所有成员都相同。

    当校验和可用时,组复制不使用它们来验证group_replication_applier通道,因为事件是从多个源写入该中继日志的,并且在它们实际写入原始服务器的二进制日志之前,也就是生成校验和的时候。校验和用于验证事件的完整性group_replication_recovery通道和组成员上的任何其他复制通道。

  • SERIALIZABLE 隔离级别。 可序列化默认情况下,多主组中不支持隔离级别。将事务隔离级别设置为可序列化将组复制配置为拒绝提交事务。

  • **并行DDL与DML操作。**使用多主模式时,不支持针对同一对象但在不同服务器上执行的并发数据定义语句和数据操作语句。在对象上执行数据定义语言(DDL)语句的过程中,在同一对象上但在不同服务器实例上执行并发数据操作语言(DML)可能会导致在不同实例上执行的DDL冲突而未被检测到。

  • **具有级联约束的外键。**多主模式组(所有成员都配置了组复制单个主模式=关闭)不支持具有多级外键依赖项的表,尤其是已定义层叠 外键约束。这是因为外键约束导致多主模式组执行级联操作,可能会导致未检测到的冲突,并导致组成员之间的数据不一致。因此,我们建议设置组_复制_强制_更新_无处不在_checks=ON在多主模式组中使用的服务器实例上,以避免未检测到的冲突。

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

  • **多主模式死锁。**当一个组在多主模式下运行时,选择更新语句可能会导致死锁。这是因为锁不是在组成员之间共享的,因此可能无法达到对此类声明的预期。

  • **复制过滤器。**全局复制筛选器不能用于为组复制配置的MySQL服务器实例,因为在某些服务器上过滤事务会使组无法就一致状态达成一致。特定于通道的复制筛选器可用于不直接涉及组复制的复制通道,例如组成员还充当组外源的副本的情况。它们不能在地面上使用组复制应用程序组_复制_恢复频道。

  • **加密连接。**对TLSv1的支持。3协议在MySQL 8.0.16之后的MySQL服务器中可用,前提是MySQL是使用OpenSSL 1.1.1或更高版本编译的。在MySQL 8.0.16和MySQL 8.0.17中,如果服务器支持TLSv1。3、组通信引擎不支持该协议,组复制无法使用该协议。组复制支持TLSv1。3来自MySQL 8.0.18,可用于组通信连接和分布式恢复连接。

    在MySQL 8.0.18中,TLSv1。3可用于分布式恢复连接的组复制,但组\u复制\u恢复\u tls\u版本组\u复制\u恢复\u tls\u密码套件系统变量不可用。因此,捐赠服务器必须允许使用至少一个TLSv1。3默认启用的ciphersuite,如中所列第6.3.2节,“加密连接TLS协议和密码”。从MySQL 8.0.19中,您可以使用这些选项为任何选择的密码套件配置客户端支持,如果需要,仅包括非默认密码套件。

  • **克隆操作。**组复制为分布式恢复启动和管理克隆操作,但已设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。在MySQL 8.0.20之前的版本中,如果克隆操作涉及正在运行组复制的组成员,则无法手动启动克隆操作。在MySQL 8.0.20中,您可以这样做,前提是克隆操作不会删除和替换收件人上的数据。因此,启动克隆操作的语句必须包含数据目录子句,以确定是否正在运行组复制。看见第18.5.4.2.4节,“出于其他目的的克隆”.

# 团体人数限制

可以成为单个复制组成员的MySQL服务器的最大数量为9。如果其他成员试图加入该组织,他们的请求将被拒绝。该限制已通过测试和基准测试确定为集团在稳定局域网上可靠运行的安全边界。

# 交易规模限制

如果单个事务导致消息内容足够大,以至于无法在5秒钟的时间内通过网络在组成员之间复制消息,则可能怀疑成员失败,然后仅仅因为他们忙于处理该事务就被驱逐。由于内存分配问题,大型事务还可能导致系统速度减慢。为避免这些问题,请使用以下缓解措施:

  • 如果由于大量消息而发生不必要的驱逐,请使用系统变量组\复制\成员\驱逐\超时在被怀疑失败的成员被开除之前留出额外的时间。在最初的5秒检测期结束后,您最多可以等待一个小时,然后将可疑成员从群中驱逐出去。在MySQL 8.0.21中,默认情况下允许额外5秒。

  • 在可能的情况下,在通过组复制处理事务之前,请尝试限制事务的大小。例如,拆分与一起使用的文件加载数据分成小块。

  • 使用系统变量组\复制\事务\大小\限制指定组接受的最大事务大小。在MySQL 8.0中,此系统变量默认最大事务大小为15000000字节(约143MB)。超过此大小的事务将回滚,不会发送到集团复制的集团通信系统(GCS)以分发给集团。根据您需要组允许的最大消息大小,调整此变量的值,请记住处理事务所需的时间与其大小成正比。

  • 使用系统变量组\u复制\u压缩\u阈值指定应用压缩的消息大小。此系统变量默认为1000000字节(1MB),因此会自动压缩大型消息。压缩由组复制的组通信系统(GCS)在接收到许可的消息时执行组\复制\事务\大小\限制设置,但超出组\u复制\u压缩\u阈值背景有关更多信息,请参阅第18.7.4节,“消息压缩”.

  • 使用系统变量组\复制\通信\最大\消息\大小指定消息大小,超过该大小的消息将被分段。此系统变量默认为10485760字节(10 MiB),因此大型消息会自动分段。如果压缩后的信息仍然超过规定值,地面军事系统将在压缩后执行分段组\复制\通信\最大\消息\大小限度为了让复制组使用碎片,所有组成员必须是MySQL 8.0.16或更高版本,并且组使用的组复制通信协议版本必须允许碎片。有关更多信息,请参阅第18.7.5节,“消息碎片”.

    通过为相关系统变量指定零值,可以停用最大事务大小、消息压缩和消息分段。如果已停用所有这些保护措施,则复制组成员上的应用程序线程可以处理的消息的大小上限是该成员的副本\u最大\u允许\u数据包从\u最大\u允许\u数据包系统变量,其默认值和最大值为1073741824字节(1 GB)。当接收成员试图处理超过此限制的消息时,该消息将失败。组成员可以发起并尝试向组传输的消息的大小上限为4294967295字节(约4 GB)。这是对分组大小的硬限制,该分组大小由用于组复制的组通信引擎(XCom,Paxos变体)接受,该引擎在GCS处理消息后接收消息。超过此限制的消息在发起成员尝试广播时失败。