MGR要求与限制

您要用于组复制的服务器实例必须满足以下要求。

根据官方文档内容的整理

参考网址：https://dev.mysql.com/doc/refman/8.0/en/group-replication-requirements-and-limitations.html。

组复制要求

基础设施

• InnoDB存储引擎。 数据必须存储在 InnoDB 事务存储引擎中。乐观地执行事务，然后在提交时检查冲突。如果存在冲突，为了保持整个组的一致性，将回滚某些事务。这意味着需要事务存储引擎。此外， InnoDB 还提供了一些附加功能，可以在与组复制一起操作时更好地管理和处理冲突。使用其他存储引擎，包括临时 MEMORY 存储引擎，可能会导致组复制中的错误。您可以通过 disabled_storage_engines 在组成员上设置系统变量来阻止使用其他存储引擎 ，例如：
  disabled_storage_engines=“MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY”

• 主键。 该组要复制的每个表都必须具有定义的主键，或等效的主键，其中等效项是非null的唯一键。此类键是作为表中每一行的唯一标识符所必需的，从而使系统能够通过准确标识每个事务已修改的行来确定哪些事务发生冲突。组复制具有其自己的内置的主键或主键等效项检查集，并且不使用 sql_require_primary_key 系统变量执行的检查 。你可以设置 sql_require_primary_key=ON对于正在运行“组复制”的服务器实例，您可以将语句REQUIRE_TABLE_PRIMARY_KEY_CHECK 选项设置 为“组复制”通道。但是，请注意，您可能会发现在设置或 时执行的组检查不允许组复制的内置检查所允许的某些事务 。 CHANGE MASTER TO ONsql_require_primary_key=ONREQUIRE_TABLE_PRIMARY_KEY_CHECK=ON

• 网络性能。 MySQL组复制旨在部署在服务器实例彼此非常靠近的群集环境中。一组的性能和稳定性可能会受到网络延迟和网络带宽的影响。所有组成员之间必须始终保持双向通信。如果针对服务器实例阻止了入站或出站通信（例如，通过防火墙或由于连接问题），则该成员无法在该组中运行，并且该组成员（包括有问题的成员）可能无法报告受影响的服务器实例的正确成员状态。

从MySQL 8.0.14开始，您可以使用IPv4或IPv6网络基础结构或两者的结合来进行远程组复制服务器之间的TCP通信。也没有什么可以阻止组复制通过虚拟专用网络（VPN）进行操作。

同样，从MySQL 8.0.14（组复制服务器实例位于同一位置并共享本地组通信引擎（XCom）实例）开始，在可能的情况下，使用开销较小的专用输入通道代替TCP套接字进行通信。对于某些需要在远程XCom实例之间进行通信的组复制任务（例如加入组），仍然使用TCP网络，因此网络性能会影响组的性能。

服务器实例配置

必须按照作为组成员的服务器实例上所示配置以下选项。

• 二进制日志处于活动状态。 设置 _{[—log-bin[=log_file_name]](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_log_bin)}。MySQL Group Replication复制二进制日志内容，因此二进制日志需要打开才能运行。默认情况下启用此选项。请参见 第5.4.4节“二进制日志” 。
• 已记录副本更新。 设置 —log-slave-updates 。默认情况下启用此选项。组成员需要记录加入时从其捐助者处收到并通过复制应用程序应用的事务，并记录他们从组中接收并应用的所有事务。这样，组复制就可以通过从现有组成员的二进制日志进行状态转移来执行分布式恢复。
• 二进制日志行格式。 设置 —binlog-format=row 。组复制依靠基于行的复制格式在组中的服务器之间一致地传播更改。它依靠基于行的基础结构来提取必要的信息，以检测在组中不同服务器中同时执行的事务之间的冲突。从MySQL 8.0.19起，该 REQUIRE_ROW_FORMAT设置会自动添加到组复制的通道中，以在应用事务时强制使用基于行的复制。请参见 第17.2.1节“复制格式” 和 第17.3.3节“复制特权检查” 。
• 关闭二进制日志校验和（适用于MySQL 8.0.20）。 直到MySQL 8.0.20（含）以上 —binlog-checksum=NONE 。在这些发行版中，组复制无法使用校验和，并且不支持二进制日志中的校验和。从MySQL 8.0.21开始，组复制支持校验和，因此组成员可以使用默认设置。
• 全局事务标识符打开。 设置 gtid_mode=ON 。组复制使用全局事务标识符来准确跟踪每个服务器实例上已提交哪些事务，从而能够推断出哪些服务器已执行可能与其他位置已提交的事务发生冲突的事务。换句话说，显式事务标识符是框架的基本部分，能够确定哪些事务可能发生冲突。请参见 第17.1.3节“使用全局事务标识符进行复制” 。
• 复制信息存储库。 设置 master_info_repository=TABLE 和 relay_log_info_repository=TABLE 。复制应用程序需要将复制元数据写入 mysql.slave_master_info和 mysql.slave_relay_log_info表。这样可以确保组复制插件对复制元数据具有一致的可恢复性和事务管理。在MySQL 8.0.2中，TABLE默认情况下将这些选项设置为默认值，在MySQL 8.0.3中则不建议FILE使用该设置。请参见 第17.2.4.2节“复制元数据存储库” 。
• 事务写集提取。 进行设置， —transaction-write-set-extraction=XXHASH64 以便在收集行以将它们记录到二进制日志时，服务器也收集写集。写集基于每行的主键，并且是标签的简化且紧凑的视图，该标签唯一地标识已更改的行。然后，该标签用于检测冲突。默认情况下启用此选项。
• 二进制日志依赖项跟踪。 设置 binlog_transaction_dependency_tracking=WRITESET_SESSION 可以提高组成员的性能，具体取决于组的工作量。在应用中继日志中的事务时，组复制在认证后执行其自身的并行化，而与的值无关 binlog_transaction_dependency_tracking 。但是， binlog_transaction_dependency_tracking 确实会影响将事务写入组复制成员上的二进制日志的方式。这些日志中的依赖项信息用于协助从捐赠者的二进制日志进行状态转移的过程，以进行分布式恢复，只要成员加入或重新加入该组，就会发生这种情况。
• 默认表加密。 —default-table-encryption 在所有组成员上 设置 为相同的值。只要所有成员的设置都相同，就可以启用（ON）或禁用（OFF默认值）默认模式和表空间加密。
• 小写表格名称。 —lower-case-table-names 在所有组成员上 设置 为相同的值。设置1对于使用 InnoDB 存储引擎是正确的 ，这对于组复制是必需的。请注意，该设置并非在所有平台上都是默认设置。
• 多线程应用程序。 可以将组复制成员配置为多线程副本，从而使事务可以并行应用。一个非零值，用于 slave_parallel_workers 在成员上启用多线程应用程序，并且最多可以指定1024个并行应用程序线程。设置 slave_preserve_commit_order=1 可确保并行事务的最终提交与组复制要求的原始事务的顺序相同，这取决于组复制，一致性机制建立在保证所有参与成员以相同顺序接收和应用已提交事务的基础上。最后，设置 slave_parallel_type=LOGICAL_CLOCK 需要使用，用于指定用于确定允许在副本上并行执行哪些事务的策略 slave_preserve_commit_order=1 。设置 slave_parallel_workers=0 将禁用并行执行，并为副本提供一个单一的应用程序线程，而没有协调程序线程。使用该设置时， slave_parallel_type 和 slave_preserve_commit_order 选项无效，将被忽略。

组复制限制

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

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

• —upgrade=MINIMAL选项。 使用MINIMAL选项（—upgrade=MINIMAL）的MySQL Server升级后，无法启动组复制，该选项不会升级复制内部依赖的系统表。
• 间隙锁。 组复制的并发事务认证过程未考虑 间隙锁 ，因为有关间隙锁的信息不在之外 InnoDB 。有关更多信息，请参见 间隙锁 。

注意
对于处于多主模式的组，除非您依赖 REPEATABLE READ 应用程序中的语义，否则 建议将 READ COMMITTED 隔离级别与组复制一起使用。InnoDB不使用中的间隙锁 READ COMMITTED ，它使InnoDB中的本地冲突检测与组复制执行的分布式冲突检测对齐。对于单主模式的组，只有主模式接受写操作，因此 READ COMMITTED 隔离级别对组复制并不重要。

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

• 二进制日志校验和。 直到并包括MySQL 8.0.20在内，组复制无法使用校验和，并且不支持二进制日志中的校验和，因此 binlog_checksum=NONE 在将服务器实例配置为组成员时必须进行设置 。从MySQL 8.0.21开始，组复制支持校验和，因此组成员可以使用默认设置 binlog_checksum=CRC32 。 binlog_checksum 群组的所有成员的设置不必相同。
  当校验和可用时，组复制将不使用它们来验证group_replication_applier通道上的传入事件 ，因为事件是从多个源写入到该中继日志的，并且在它们实际写入原始服务器的二进制日志之前（即生成校验和的时间） 。校验和用于验证group_replication_recovery通道和组成员上任何其他复制通道上事件的完整性 。

• 可隔离的隔离级别。 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通道上使用。

• 加密的连接。 从MySQL 8.0.16开始，MySQL Server中提供了对TLSv1.3协议的支持，前提是MySQL是使用OpenSSL 1.1.1或更高版本进行编译的。在MySQL 8.0.16和MySQL 8.0.17中，如果服务器支持TLSv1.3，则组通信引擎中不支持该协议，并且组复制不能使用该协议。组复制支持MySQL 8.0.18中的TLSv1.3，可将其用于组通信连接和分布式恢复连接。
  在MySQL 8.0.18中，TLSv1.3可以在组复制中用于分布式恢复连接，但是 group_replication_recovery_tls_version 和 group_replication_recovery_tls_ciphersuites 系统变量不可用。因此，施主服务器必须允许使用至少一个默认启用的TLSv1.3密码套件，如 第6.3.2节“加密连接TLS协议和密码”中 所列 。从MySQL 8.0.19起，您可以使用这些选项来配置对任何密码套件选择的客户端支持，如果需要的话，仅包括非默认密码套件。

• 克隆操作。 组复制启动并管理用于分布式恢复的克隆操作，但是已设置为支持克隆的组成员也可能参与用户手动启动的克隆操作。在MySQL 8.0.20之前的版本中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL 8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，DATA DIRECTORY如果正在运行组复制，则用于启动克隆操作的语句必须包含该 子句。看到 第18.4.3.2.4节“为其他目的克隆” 。

团体人数限制

可以成为一个复制组成员的MySQL服务器的最大数量为9。如果其他成员尝试加入该组，则其请求将被拒绝。从测试和基准测试中可以确定此限制是安全的边界，在此范围内该组在稳定的局域网上可靠地运行。

交易规模限制

如果单个事务产生的消息内容足够大，以致于无法在5秒的时间内通过网络在组成员之间复制消息，则可能会怀疑成员失败了，然后将其驱逐出局，仅仅是因为他们正在忙于处理消息。交易。大型事务还会由于内存分配问题而导致系统变慢。为避免这些问题，请使用以下缓解措施：

• 如果由于大消息而发生不必要的驱逐，请使用系统变量 group_replication_member_expel_timeout 留出更多时间，以驱逐被怀疑失败的成员。在最初的5秒检测期之后，您最多可以等待一个小时，然后才能将可疑成员从小组中驱逐出去。从MySQL 8.0.21开始，默认情况下再允许5秒。

• 在可能的情况下，请尝试限制事务的大小，然后再由组复制对其进行处理。例如，将用于的文件拆分LOAD DATA为较小的块。

• 使用系统变量 group_replication_transaction_size_limit 来指定组接受的最大事务大小。在MySQL 8.0中，此系统变量的默认最大事务大小为150000000字节（约143 MB）。超过此大小的事务将回滚，并且不会发送到组复制的组通信系统（GCS）进行分发。请记住，处理事务所花费的时间与其大小成正比，请根据需要该组允许的最大消息大小来调整此变量的值。

• 使用系统变量 group_replication_compression_threshold 来指定消息大小，在该消息大小之上进行压缩。该系统变量的默认值为1000000字节（1 MB），因此会自动压缩大消息。当组复制的组通信系统（GCS）收到 group_replication_transaction_size_limit 设置所允许但超出 group_replication_compression_threshold 设置的消息时，将执行压缩 。有关更多信息，请参见 第18.6.3节“消息压缩” 。

• 使用系统变量 group_replication_communication_max_message_size 来指定消息大小，超过该大小后，消息将被分段。该系统变量的默认值为10485760字节（10 MiB），因此大型邮件将自动分段。如果压缩的消息仍超出 group_replication_communication_max_message_size 限制，则GCS会在压缩后执行分段操作 。为了使复制组使用分段，所有组成员必须都在MySQL 8.0.16或更高版本上，并且该组使用的“组复制”通信协议版本必须允许分段。有关更多信息，请参见 第18.6.4节“消息碎片” 。

通过为相关系统变量指定零值，可以停用最大事务大小，消息压缩和消息碎片。如果您停用了所有这些保护措施，则复制组成员上的应用程序线程可以处理的消息的大小上限为该成员的值上限。 slave_max_allowed_packet 系统变量，其默认值为最大值1073741824字节（1 GB）。当接收成员尝试处理此消息时，超出此限制的消息将失败。组成员可以发起并尝试发送到该组的消息的大小上限为4294967295字节（约4 GB）。这是组通信引擎接受的用于组复制（XCom，Paxos变体）的数据包大小的硬限制，它在GCS处理完消息后接收消息。当发起成员尝试广播超过此限制的消息时，该消息将失败。