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

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

主键。 要由组复制的每个表都必须具有定义的主键，或者主键等效于非空唯一键。这些键是表中每一行的唯一标识符，使系统能够通过准确识别每个事务修改了哪些行来确定哪些事务冲突。组复制有自己内置的主键或主键等效项检查集，并且不使用 sql_require_primary_key 系统变量执行的检查。您可以在运行组复制的服务器实例上设置 sql_require_primary_key=ON，并且可以为组复制通道设置 CHANGE REPLICATION SOURCE TO 语句的 REQUIRE_TABLE_PRIMARY_KEY_CHECK 选项为 ON。但是，请注意，您可能会发现组复制的内置检查允许的某些事务在设置 sql_require_primary_key=ON 或 REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON 时执行的检查不允许。

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

您可以使用基于 IPv4、IPv6 或两者混合的网络基础设施，用于远程组复制服务器之间的 TCP 通信。也没有什么可以阻止组复制在虚拟专用网络 (VPN) 上运行。

如果组复制服务器实例位于同一位置并共享本地组通信引擎 (XCom) 实例，则在可能的情况下，将使用具有较低开销的专用输入通道进行通信，而不是使用 TCP 套接字。对于需要远程 XCom 实例之间进行通信的某些组复制任务（例如加入组），仍然使用 TCP 网络，因此网络性能会影响组的性能。

唯一的服务器标识符。 使用 server_id 系统变量为服务器配置唯一的服务器 ID，这是复制拓扑中所有服务器的要求。服务器 ID 必须是介于 1 和 (2³²)−1 之间的正整数，并且必须与复制拓扑中任何其他服务器使用的任何其他服务器 ID 不同。

二进制日志处于活动状态。 在 MySQL 8.4 中，默认情况下启用二进制日志记录。您可以选择使用 --log-bin[=log_file_name] 指定二进制日志文件的名称。组复制会复制二进制日志的内容，因此需要启用二进制日志才能使其运行。请参阅 第 7.4.4 节“二进制日志”。

记录副本更新。 设置 log_replica_updates=ON（如果尚未启用）。（在 MySQL 8.4 中，这是默认设置。）组成员需要记录在加入时从其捐赠者接收并通过复制应用程序应用的事务，并记录它们从组接收和应用的所有事务。这使得组复制能够通过从现有组成员的二进制日志进行状态传输来执行分布式恢复。

二进制日志行格式。 如果需要，请设置 binlog_format=ROW；在 MySQL 8.4 中，这是默认设置。组复制依赖于基于行的复制格式在组中的服务器之间一致地传播更改，并提取必要的信息来检测组中不同服务器上并发执行的事务之间的冲突。将 REQUIRE_ROW_FORMAT 的设置自动添加到组复制的通道中，以便在应用事务时强制使用基于行的复制。请参阅 第 19.2.1 节“复制格式” 和 第 19.3.3 节“复制权限检查”。

全局事务标识符开启。 设置 gtid_mode=ON 和 enforce_gtid_consistency=ON。这些设置不是默认设置。组复制需要基于 GTID 的复制，它使用全局事务标识符来跟踪组中每个服务器实例上已提交的事务。请参阅 第 19.1.3 节“使用全局事务标识符进行复制”。

默认表加密。 在所有组成员上将 default_table_encryption 设置为相同的值。默认架构和表空间加密可以启用（ON）或禁用（OFF，默认值），只要所有成员上的设置相同即可。

小写表名。 在所有组成员上将 lower_case_table_names 设置为相同的值。对于使用组复制所需的 InnoDB 存储引擎，设置为 1 是正确的。请注意，此设置并非在所有平台上都是默认设置。

多线程应用器。 组复制成员可以配置为多线程副本，从而可以并行应用事务。默认情况下，所有副本都配置为多线程。 replica_parallel_workers 的非零值将启用成员上的多线程应用器。默认值为 4 个并行应用器线程；最多可以指定 1024 个并行应用器线程。

设置 replica_parallel_workers=0 将禁用并行执行，并为副本提供单个应用器线程，而不提供协调器线程。使用该设置，replica_parallel_type 和 replica_preserve_commit_order 选项将不起作用并被忽略。如果在副本上使用 GTID 时禁用了并行执行，则副本实际上将使用一个并行工作线程，以利用该方法在不访问文件位置的情况下重试事务。但是，此行为不会对用户造成任何改变。

分离的 XA 事务。 MySQL 8.4 及更高版本支持分离的 XA 事务。分离的事务是指一旦准备就绪，便不再连接到当前会话的事务。这是在执行 XA PREPARE 时自动发生的。准备好的 XA 事务可以由另一个连接提交或回滚，然后当前会话可以在不等待刚刚准备完成的事务完成的情况下启动另一个 XA 事务或本地事务。

如果启用了分离的 XA 事务支持（xa_detach_on_prepare = ON），则对此服务器的任何连接都可以列出（使用 XA RECOVER）、回滚或提交任何已准备好的 XA 事务。此外，您不能在分离的 XA 事务中使用临时表。

您可以通过将 xa_detach_on_prepare 设置为 OFF 来禁用对分离的 XA 事务的支持，但建议不要这样做。特别是，如果要将此服务器设置为 MySQL 组复制中的实例，则应将此变量保留为其默认值（ON）。

有关更多信息，请参阅 第 15.3.8.2 节“XA 事务状态”。