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）实例时，使用专门的输入通道以降低开销，用于通信，除非需要远程 XCom 实例之间的通信，例如加入组时，TCP 网络仍然用于这些任务，因此网络性能影响组的性能。

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

二进制日志活动。 在 MySQL 8.3 中，默认启用二进制日志记录。您可以选择使用 --log-bin[=log_file_name] 指定二进制日志文件的名称。组复制将二进制日志的内容复制，因此需要启用二进制日志记录以便其正常工作。请参阅 第 7.4.4 节，“二进制日志”。

副本更新日志。 设置 log_replica_updates=ON，如果尚未启用（在 MySQL 8.3 中，默认启用）。组成员需要记录从捐赠者那里接收的交易，并应用于复制 applier， 以便在组成员之间进行分布式恢复。

二进制日志行格式。 如果必要，设置 binlog_format=ROW；在 MySQL 8.3 中，默认启用。组复制依赖于基于行的复制格式来在组中的服务器之间一致地传播更改，并从事务中提取必要的信息，以检测组中的服务器之间的并发事务冲突。设置 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 为相同的值。设置为 1 是正确的，用于 InnoDB 存储引擎，该引擎是组复制所需的。请注意，这不是所有平台上的默认设置。

二进制日志依赖项跟踪。 将 binlog_transaction_dependency_tracking 设置为 WRITESET 可以提高组成员的性能，具体取决于组的工作负载（在 MySQL 8.3 及更高版本中，默认启用）。虽然组复制在认证后独立地并行应用事务，但这项设置会影响事务如何写入二进制日志，而这将影响分布式恢复过程中的状态传输。

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

设置 replica_parallel_workers=0 禁用并行执行，并将副本设置为单个应用程序线程和无协调器线程。使用该设置时，replica_parallel_type 和 replica_preserve_commit_order 选项无效且被忽略。如果在使用 GTIDs 的副本上禁用了并行执行，副本实际上使用一个并行工作线程，以便重试事务而不访问文件位置。但是，这种行为对用户没有任何影响。

脱机 XA 事务。 MySQL 8.3 及更高版本支持脱机 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 事务状态”，以获取更多信息。