目录

17.3 Requirements and Limitations

17.3.1 Group Replication Requirements

Infrastructure

Server Instance Configuration

17.3.2 Group Replication Limitations

Limit on Group Size

Limits on Transaction Size

---

17.3 Requirements and Limitations

这个部分列出并解释了组复制的要求和限制。

17.3.1 Group Replication Requirements

Infrastructure

InnoDB存储引擎。数据必须存储在InnoDB事务性存储引擎中。事务乐观地执行，然后在提交时检查冲突。如果存在冲突，为了在群组中保持一致性，某些事务将被回滚。这意味着需要一个事务性存储引擎。此外，当与组复制一起操作时，InnoDB提供了一些额外的功能，以实现更好的管理和处理冲突。使用其他存储引擎，包括临时MEMORY存储引擎，可能会导致组复制出现错误。在将实例与组复制一起使用之前，请将其他存储引擎中的任何表转换为使用InnoDB。您可以通过设置组成员上的disabled_storage_engines系统变量来防止使用其他存储引擎，例如：

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

主键。每个要由群组复制的表必须具有定义的主键，或者主键等效项，其中等效项是非空唯一键。此类键作为表中每行的唯一标识符是必需的，使系统能够确定哪些事务通过确定每个事务已修改的确切行而发生冲突。

IPv4网络。MySQL组复制使用的群组通信引擎仅支持IPv4。因此，组复制需要IPv4网络基础设施。

网络性能。MySQL组复制设计为部署在服务器实例非常接近的群集环境中。网络延迟和网络带宽都可能影响群组的性能和稳定性。所有群组成员之间必须始终保持双向通信。如果服务器实例的入站或出站通信被阻止（例如，由防火墙或连接问题导致），该成员将无法在群组中运行，并且群组成员（包括存在问题的成员）可能无法为受影响的服务器实例报告正确的成员状态。

Server Instance Configuration

在作为群组成员的服务器实例上必须配置以下选项。

唯一服务器标识符。使用server_id系统变量为服务器配置唯一的服务器ID，这是复制拓扑中所有服务器所需的。默认的服务器ID为0，复制拓扑中的服务器无法相互连接。服务器ID必须是介于1和(232)−1之间的正整数，并且必须与复制拓扑中任何其他服务器正在使用的任何其他服务器ID不同。

二进制日志打开。设置--log-bin[=log_file_name]。MySQL Group Replication会复制二进制日志内容，因此需要将二进制日志打开才能运行。此选项默认已启用。请参阅5.4.4节，“二进制日志”。

副本更新被记录。设置--log-slave-updates。服务器需要记录通过复制应用程序应用的二进制日志。群组中的服务器需要记录它们从群组中接收并应用的所有事务。这是因为恢复是通过依赖群组中参与者的二进制日志来进行的。因此，即使对于那些未在服务器本身上启动的事务，每个事务的副本也需要存在于每个服务器上。

二进制日志行格式。设置--binlog-format=row。组复制依赖于基于行的复制格式，以在群组中的服务器之间一致地传播更改。它依赖于基于行的基础架构，能够提取检测群组中不同服务器上同时执行的事务之间冲突所需的信息。请参阅16.2.1节，“复制格式”。

关闭二进制日志校验和。设置--binlog-checksum=NONE。由于复制事件校验和的设计限制，组复制无法使用它们，因此必须将其禁用。

全局事务标识符打开。设置gtid_mode=ON和enforce_gtid_consistency=ON。组复制使用全局事务标识符跟踪每个服务器实例上确切提交的事务，从而能够推断出哪些服务器执行了可能与其他地方已提交的事务冲突的事务。换句话说，显式事务标识符是框架的基本组成部分，以便确定哪些事务可能发生冲突。请参阅16.1.3节，“使用全局事务标识符进行复制”。

复制信息存储库。设置master_info_repository=TABLE和relay_log_info_repository=TABLE。复制应用程序需要将源和副本元数据写入mysql.slave_master_info和mysql.slave_relay_log_info系统表。这确保了Group Replication插件具有一致的可恢复性和复制元数据的事务管理。请参阅16.2.4.2节，“复制元数据存储库”。

事务写集提取。设置--transaction-write-set-extraction=XXHASH64，以便在收集行以将其记录到二进制日志时，服务器还收集写集。写集基于每行的主键，并且是标识已更改的行的简化和紧凑视图的标签。然后，此标签用于检测冲突。

小写表名。在所有群组成员上将--lower-case-table-names设置为相同的值。对于InnoDB存储引擎的使用，设置为1是正确的，这是组复制所必需的。请注意，此设置不是所有平台的默认设置。

多线程应用程序。可以将Group Replication成员配置为多线程副本，从而使事务可以并行应用。对slave_parallel_workers启用非零值会在成员上启用多线程应用程序，并且可以指定高达1024个并行应用程序线程。如果这样做，则还需要以下设置：

slave_preserve_commit_order=1 此设置是必需的，以确保并行事务的最终提交与原始事务的顺序相同。Group Replication依赖于围绕所有参与成员都按照相同顺序接收并应用提交的事务的保证建立的一致性机制。

slave_parallel_type=LOGICAL_CLOCK 与slave_preserve_commit_order=1一起需要此设置。它指定用于决定在副本上允许哪些事务并行执行的策略。

将slave_parallel_workers=0设置为禁用并行执行，并为副本提供单个应用程序线程和无协调线程。在此设置下，slave_parallel_type和slave_preserve_commit_order选项无效且被忽略。

17.3.2 Group Replication Limitations

Group Replication存在以下已知限制。请注意，对于多主模式组的限制和问题在故障转移事件期间也可能适用于单主模式集群，因为新选举的主服务器正在清除其应用程序队列中的旧主服务器的内容。

提示

Group Replication是基于GTID的复制构建的，因此您还应该注意16.1.3.6节，“使用GTID进行复制的限制”。

Gap Locks 间隙锁。 Group Replication的并发事务的认证过程不考虑间隙锁，因为间隙锁的信息在InnoDB之外不可用。有关更多信息，请参见间隙锁。

注意

对于多主模式的组，除非您的应用程序依赖REPEATABLE READ语义，否则我们建议使用READ COMMITTED隔离级别与Group Replication一起使用。InnoDB在READ COMMITTED中不使用间隙锁，这将InnoDB内部的本地冲突检测与Group Replication执行的分布式冲突检测进行了对齐。对于单主模式的组，只有主服务器接受写入，因此READ COMMITTED隔离级别对Group Replication不重要。

Table Locks and Named Locks. 表锁和命名锁。认证过程不考虑表锁（参见13.3.5节，“LOCK TABLES和UNLOCK TABLES语句”）或命名锁（参见GET_LOCK()）。

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

SERIALIZABLE Isolation Level。默认情况下，多主模式组不支持SERIALIZABLE隔离级别。将事务隔离级别设置为SERIALIZABLE会使Group Replication拒绝提交该事务。

Concurrent DDL versus DML Operations 并发DDL与DML操作。在使用多主模式时，不支持并发针对同一对象但在不同服务器上执行的数据定义语句和数据操作语句。在对对象执行数据定义语言（DDL）语句期间，对相同对象但在不同服务器实例上执行并发数据操作语言（DML）语句可能会导致未检测到的DDL在不同实例上执行冲突。

Foreign Keys with Cascading Constraints 具有级联约束的外键。多主模式组（所有成员都配置为group_replication_single_primary_mode=OFF）不支持具有多级外键依赖关系的表，特别是具有定义的级联外键约束的表。这是因为导致由多主模式组执行的级联操作的外键约束可能导致在组的成员之间未检测到的冲突，并导致组的成员之间的数据不一致。因此，我们建议在用于多主模式组的服务器实例上设置group_replication_enforce_update_everywhere_checks=ON，以避免未检测到的冲突。

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

MySQL Enterprise Audit和MySQL Enterprise Firewall。在版本5.7.21之前，MySQL Enterprise Audit和MySQL Enterprise Firewall在mysql系统数据库中使用MyISAM表。Group Replication不支持MyISAM表。

Multi-primary Mode Deadlock 多主模式死锁。当组处于多主模式时，SELECT .. FOR UPDATE语句可能导致死锁。这是因为锁不在组的成员之间共享，因此可能不会达到对此类语句的期望。

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

Limit on Group Size

单个复制组中的最大MySQL服务器数量为 9。如果更多成员尝试加入该组，则其请求将被拒绝。这个限制是从测试和基准测试中确定的，作为一个安全边界，在稳定的局域网上，该组的性能表现可靠。

Limits on Transaction Size

如果单个事务导致的消息内容足够大，以至于在5秒窗口内无法在网络上的组成员之间复制该消息，则成员可能会因为忙于处理该事务而被怀疑失败，并被驱逐。大型事务也可能因为内存分配问题而导致系统变慢。为避免这些问题，请使用以下缓解措施：

• 在可能的情况下，尽量限制事务的大小。例如，将与LOAD DATA一起使用的文件拆分为较小的块。
• 使用系统变量group_replication_transaction_size_limit来指定组接受的最大事务大小。在MySQL 5.7.37及更早版本中，该系统变量默认为零，但从MySQL 5.7.38开始，在MySQL 8.0中，默认值为最大事务大小为150000000字节（约143 MB）。超过此限制的事务将被回滚，并且不会发送到Group Replication的Group Communication System (GCS)以分发到组中。根据组需要容忍的最大消息大小调整此变量的值，要注意处理事务所需的时间与其大小成正比。

注意

当从MySQL 5.7.37或更早版本升级到MySQL 5.7.38或更高版本时，如果您的Group Replication服务器以前接受的事务大于新的默认限制，并且您允许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）。这是接受Group Replication（一种Paxos变体）的组通信引擎（XCom）所接受的数据包大小的硬限制，在GCS处理消息后接收它们。当发起成员尝试广播超过此限制的消息时，该消息会失败。