MySQL :: MySQL 8.4 参考手册 :: 20.3.2 组复制限制

MySQL 8.4 参考手册 · 中文镜像

正文为中文，英文原文默认隐藏。点击任意中文段落即可展开 / 收起对应英文原文。

译文由机器翻译生成，仅供理解参考；有疑问请以官方英文原文为准。

MySQL 8.4 参考手册 / 20 组复制 / 20.3 要求和限制 / 20.3.2 组复制限制

中文点击中文段落可显示 / 隐藏英文原文本页译文覆盖 100%

20.3.2 组复制的限制20.3.2 Group Replication Limitations

组复制存在以下已知限制。请注意，多主模式组中描述的限制和问题也可能在单主模式集群中在故障转移事件期间发生，同时新选出的主节点会清空旧主节点的应用队列。The following known limitations exist for Group Replication. 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.

Tip

组复制是基于 GTID 的复制构建的，因此您还应了解第 19.1.3.7 节，“使用 GTID 的复制限制”。Group Replication is built on GTID based replication, therefore you should also be aware of Section 19.1.3.7, “Restrictions on Replication with GTIDs”.

--upgrade=MINIMAL 选项。 在使用 MINIMAL 选项（--upgrade=MINIMAL）进行 MySQL 服务器升级后，无法启动组复制，因为该选项不会升级复制内部依赖的系统表。--upgrade=MINIMAL option. Group Replication cannot be started following a MySQL Server upgrade that uses the MINIMAL option (--upgrade=MINIMAL), which does not upgrade system tables on which the replication internals depend.
间隙锁。 群组复制对并发事务的认证过程不考虑间隙锁，因为间隙锁的信息在InnoDB之外不可用。有关更多信息，请参见间隙锁。Gap Locks. Group Replication's certification process for concurrent transactions does not take into account gap locks, as information about gap locks is not available outside of InnoDB. See Gap Locks for more information.
Note
对于多主模式下的组，除非您的应用依赖于 REPEATABLE READ 语义，否则我们建议在组复制中使用 READ COMMITTED 隔离级别。在 READ COMMITTED 中，InnoDB 不使用间隙锁，从而使 InnoDB 的本地冲突检测与组复制执行的分布式冲突检测保持一致。对于单主模式的组，只有主节点接受写操作，因此 READ COMMITTED 隔离级别对于组复制并不重要。For a group in multi-primary mode, unless you rely on REPEATABLE READ semantics in your applications, we recommend using the READ COMMITTED isolation level with Group Replication. InnoDB does not use gap locks in READ COMMITTED, which aligns the local conflict detection within InnoDB with the distributed conflict detection performed by Group Replication. For a group in single-primary mode, only the primary accepts writes, so the READ COMMITTED isolation level is not important to Group Replication.
表锁和命名锁。 认证过程不考虑表锁（参见第 15.3.6 节，“LOCK TABLES 和 UNLOCK TABLES 语句”）或命名锁（参见 GET_LOCK()）。Table Locks and Named Locks. The certification process does not take into account table locks (see Section 15.3.6, “LOCK TABLES and UNLOCK TABLES Statements”) or named locks (see GET_LOCK()).
二进制日志校验和。 MySQL 8.4 的组复制支持校验和，因此组成员可以使用默认设置 binlog_checksum=CRC32。binlog_checksum 的设置不必在组的所有成员中相同。Binary Log Checksums. Group Replication in MySQL 8.4 supports checksums, so group members may use the default setting binlog_checksum=CRC32. The setting for binlog_checksum does not have to be the same for all members of a group.
当校验和可用时，组复制不会使用它们来验证 group_replication_applier 通道上的传入事件，因为这些事件是从多个来源写入该中继日志的，并且在实际写入源服务器的二进制日志之前，此时才生成校验和。校验和用于验证 group_replication_recovery 通道以及组成员上任何其他复制通道事件的完整性。When checksums are available, Group Replication does not use them to verify incoming events on the group_replication_applier channel, because events are written to that relay log from multiple sources and before they are actually written to the originating server's binary log, which is when a checksum is generated. Checksums are used to verify the integrity of events on the group_replication_recovery channel and on any other replication channels on group members.
可串行化隔离级别。 SERIALIZABLE 隔离级别在多主组中默认不支持。将事务隔离级别设置为 SERIALIZABLE 会配置组复制拒绝提交该事务。SERIALIZABLE Isolation Level. SERIALIZABLE isolation level is not supported in multi-primary groups by default. Setting a transaction isolation level to SERIALIZABLE configures Group Replication to refuse to commit the transaction.
并发 DDL 与 DML 操作。 在多主模式下，不支持在不同服务器上对同一对象执行并发的数据定义语句和数据操作语句。在对对象执行数据定义语言（DDL）语句的过程中，如果在不同的服务器实例上对同一对象执行并发的数据操作语言（DML）操作，可能存在无法检测不同实例上执行的 DDL 冲突的风险。Concurrent DDL versus DML Operations. Concurrent data definition statements and data manipulation statements executing against the same object but on different servers is not supported when using multi-primary mode. During execution of Data Definition Language (DDL) statements on an object, executing concurrent Data Manipulation Language (DML) on the same object but on a different server instance has the risk of conflicting DDL executing on different instances not being detected.
带级联约束的外键。 多主模式组（所有成员都配置为 group_replication_single_primary_mode=OFF）不支持具有多级外键依赖的表，特别是定义了 CASCADING 外键约束的表。这是因为多主模式组执行的外键约束级联操作可能导致未检测到的冲突，并导致组成员之间的数据不一致。因此，我们建议在用于多主模式组的服务器实例上设置 group_replication_enforce_update_everywhere_checks=ON 以避免未检测到的冲突。Foreign Keys with Cascading Constraints. Multi-primary mode groups (members all configured with group_replication_single_primary_mode=OFF) do not support tables with multi-level foreign key dependencies, specifically tables that have defined CASCADING foreign key constraints. This is because foreign key constraints that result in cascading operations executed by a multi-primary mode group can result in undetected conflicts and lead to inconsistent data across the members of the group. Therefore we recommend setting group_replication_enforce_update_everywhere_checks=ON on server instances used in multi-primary mode groups to avoid undetected conflicts.
在单主模式下，这不是问题，因为它不允许对组的多个成员进行并发写入，因此不存在未检测到的冲突风险。In single-primary mode this is not a problem as it does not allow concurrent writes to multiple members of the group and thus there is no risk of undetected conflicts.
多主模式死锁。 当一个组在多主模式下运行时，SELECT .. FOR UPDATE 语句可能导致死锁。这是因为锁不会在组成员之间共享，因此这类语句的预期可能无法实现。Multi-primary Mode Deadlock. When a group is operating in multi-primary mode, SELECT .. FOR UPDATE statements can result in a deadlock. This is because the lock is not shared across the members of the group, therefore the expectation for such a statement might not be reached.
复制过滤器。 配置为组复制的 MySQL 服务器实例无法使用全局复制过滤器，因为在某些服务器上过滤事务会导致组无法就一致状态达成共识。特定通道的复制过滤器可以用于与组复制不直接相关的复制通道，例如组成员同时作为组外源的副本时可以使用。它们不能用于 group_replication_applier 或 group_replication_recovery 通道。Replication Filters. Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replica to a source that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.
加密连接。 MySQL 支持 TLSv1.3 协议，前提是它是使用 OpenSSL 1.1.1 或更高版本编译的。组复制支持 TLSv1.3，可以用于组通信连接和分布式恢复连接。Encrypted Connections. Support for the TLSv1.3 protocol is available in MySQL, provided that it was compiled using OpenSSL 1.1.1 or higher. Group Replication supports TLSv1.3, where it can be used for group communication connections and distributed recovery connections.
group_replication_recovery_tls_version 和 group_replication_recovery_tls_ciphersuites 可用于配置客户端对任意选择的加密套件的支持，包括仅使用非默认加密套件（如果需要）。请参见第 8.3.2 节，“加密连接 TLS 协议和加密套件”。group_replication_recovery_tls_version and group_replication_recovery_tls_ciphersuites can be used to configure client support for any selection of ciphersuites, including only non-default ciphersuites if desired. See Section 8.3.2, “Encrypted Connection TLS Protocols and Ciphers”.
克隆操作。 群组复制会启动并管理用于分布式恢复的克隆操作，但已设置为支持克隆的群组成员也可以参与用户手动启动的克隆操作。如果操作涉及正在运行群组复制的群组成员，并且克隆操作不会删除或替换接收方的数据，则可以手动启动克隆操作。因此，如果群组复制正在运行，启动克隆操作的语句必须包含DATA DIRECTORY子句。请参见第 20.5.4.2.4 节，“用于其他目的的克隆”。Cloning Operations. Group Replication initiates and manages cloning operations for distributed recovery, but group members that have been set up to support cloning may also participate in cloning operations that a user initiates manually. You can initiate a cloning operation manually if the operation involves a group member on which Group Replication is running, provided that the cloning operation does not remove and replace the data on the recipient. The statement to initiate the cloning operation must therefore include the DATA DIRECTORY clause if Group Replication is running. See Section 20.5.4.2.4, “Cloning for Other Purposes”.

群组大小限制Limit on Group Size

单个复制组中 MySQL 服务器的最大成员数量是 9。如果有更多成员尝试加入该组，其请求将被拒绝。通过测试和基准测试已确定此限制为一个安全边界，在稳定的局域网环境下，组能够可靠运行。The maximum number of MySQL servers that can be members of a single replication group is 9. If further members attempt to join the group, their request is refused. This limit has been identified from testing and benchmarking as a safe boundary where the group performs reliably on a stable local area network.

事务大小限制Limits on Transaction Size

如果单个事务导致的消息内容足够大，以至于消息无法在 5 秒内通过网络在组成员之间复制，那么成员可能会被怀疑已失败，然后被开除，仅仅因为它们正在忙于处理事务。大型事务还可能因为内存分配问题而导致系统变慢。为避免这些问题，请使用以下缓解措施：If an individual transaction results in message contents which are large enough that the message cannot be copied between group members over the network within a 5-second window, members can be suspected of having failed, and then expelled, just because they are busy processing the transaction. Large transactions can also cause the system to slow due to problems with memory allocation. To avoid these issues use the following mitigations:

如果由于大消息而发生不必要的驱逐，请使用系统变量 group_replication_member_expel_timeout 来允许在怀疑成员失败被驱逐之前额外的时间。在初始 5 秒的检测期之后，最多可以允许一个小时才将可疑成员从组中驱逐。默认情况下允许额外 5 秒。If unnecessary expulsions occur due to large messages, use the system variable group_replication_member_expel_timeout to allow additional time before a member under suspicion of having failed is expelled. You can allow up to an hour after the initial 5-second detection period before a suspect member is expelled from the group. An additional 5 seconds is allowed by default.
在可能的情况下，尝试在事务被组复制处理之前限制其大小。例如，将用于 LOAD DATA 的文件拆分为更小的块。Where possible, try and limit the size of your transactions before they are handled by Group Replication. For example, split up files used with LOAD DATA into smaller chunks.
使用系统变量 group_replication_transaction_size_limit 来指定组接受的最大事务大小。默认最大事务大小是 150000000 字节（约 143 MB）；超过此大小的事务将被回滚，并且不会发送到 Group Replication 的组通信系统（GCS）以分发到组中。根据您希望组能够容忍的最大消息大小调整此变量的值，同时请注意，处理事务所需的时间与其大小成正比。Use the system variable group_replication_transaction_size_limit to specify a maximum transaction size that the group accepts. The default maximum transaction size is 150000000 bytes (approximately 143 MB); transactions above this size are rolled back and are not sent to Group Replication's Group Communication System (GCS) for distribution to the group. Adjust the value of this variable depending on the maximum message size that you need the group to tolerate, bearing in mind that the time taken to process a transaction is proportional to its size.
使用系统变量 group_replication_compression_threshold 来指定超过该大小的消息将被压缩。该系统变量的默认值为 1000000 字节（1 MB），因此大消息会自动压缩。当 Group Replication 的组通信系统 (GCS) 接收到符合 group_replication_transaction_size_limit 设置但超过 group_replication_compression_threshold 设置的消息时，将执行压缩。更多信息，请参见第 20.7.4 节，“消息压缩”。Use the system variable group_replication_compression_threshold to specify a message size above which compression is applied. This system variable defaults to 1000000 bytes (1 MB), so large messages are automatically compressed. Compression is carried out by Group Replication's Group Communication System (GCS) when it receives a message that was permitted by the group_replication_transaction_size_limit setting but exceeds the group_replication_compression_threshold setting. For more information, see Section 20.7.4, “Message Compression”.
使用系统变量 group_replication_communication_max_message_size 来指定超出该大小的消息将被分段。该系统变量的默认值为 10485760 字节（10 MiB），因此大消息会自动被分段。GCS 会在压缩后进行分段，如果压缩后的消息仍然超过 group_replication_communication_max_message_size 限制。有关更多信息，请参见第 20.7.5 节，“消息分段”。Use the system variable group_replication_communication_max_message_size to specify a message size above which messages are fragmented. This system variable defaults to 10485760 bytes (10 MiB), so large messages are automatically fragmented. GCS carries out fragmentation after compression if the compressed message still exceeds the group_replication_communication_max_message_size limit. For more information, see Section 20.7.5, “Message Fragmentation”.

通过为相关的系统变量指定零值，可以停用最大事务大小、消息压缩和消息分片。如果您已停用所有这些保护措施，则复制组成员的应用线程可以处理的消息的最大大小上限为该成员的 replica_max_allowed_packet 系统变量的值，其默认值和最大值为 1073741824 字节（1 GB）。当接收成员尝试处理超出此限制的消息时，消息将失败。组成员可以发起并尝试向组传输的消息的最大大小上限为 4294967295 字节（约 4 GB）。这是组通信引擎（用于组复制的 XCom，即 Paxos 变体）所接受的数据包大小的硬性限制，消息在被 GCS 处理后由该引擎接收。发送成员尝试广播超出此限制的消息时，消息将失败。The maximum transaction size, message compression, and message fragmentation can all be deactivated by specifying a zero value for the relevant system variable. If you have deactivated all these safeguards, the upper size limit for a message that can be handled by the applier thread on a member of a replication group is the value of the member's replica_max_allowed_packet system variable, which has a default and maximum value of 1073741824 bytes (1 GB). A message that exceeds this limit fails when the receiving member attempts to handle it. The upper size limit for a message that a group member can originate and attempt to transmit to the group is 4294967295 bytes (approximately 4 GB). This is a hard limit on the packet size that is accepted by the group communication engine for Group Replication (XCom, a Paxos variant), which receives messages after GCS has handled them. A message that exceeds this limit fails when the originating member attempts to broadcast it.

首页上一级下一节