InnoDB 存储引擎。 数据必须存储在 InnoDB 事务型存储引擎中。事务以乐观方式执行，然后在提交时检查是否存在冲突。如果出现冲突，为了保持组内的一致性，某些事务会被回滚。这意味着需要使用事务型存储引擎。此外，InnoDB 提供了一些额外功能，使在与组复制一起操作时能够更好地管理和处理冲突。使用其他存储引擎，包括临时的 MEMORY 存储引擎，可能会在组复制中导致错误。在使用实例进行组复制前，请将其他存储引擎的任何表转换为 InnoDB。你可以通过在组成员上设置 disabled_storage_engines 系统变量来防止使用其他存储引擎，例如：InnoDB Storage Engine.  Data must be stored in the InnoDB transactional storage engine. Transactions are executed optimistically and then, at commit time, are checked for conflicts. If there are conflicts, in order to maintain consistency across the group, some transactions are rolled back. This means that a transactional storage engine is required. Moreover, InnoDB provides some additional functionality that enables better management and handling of conflicts when operating together with Group Replication. The use of other storage engines, including the temporary MEMORY storage engine, might cause errors in Group Replication. Convert any tables in other storage engines to use InnoDB before using the instance with Group Replication. You can prevent the use of other storage engines by setting the disabled_storage_engines system variable on group members, for example:

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

主键。 每个要由组复制的表必须有定义的主键，或者主键等价项，其中等价项是非空唯一键。这样的键是表中每一行的唯一标识符，使系统能够通过准确识别每个事务修改了哪些行来确定哪些事务发生冲突。组复制有自己内置的一套用于主键或主键等价项的检查，并不使用sql_require_primary_key系统变量所进行的检查。您可以在运行组复制的服务器实例上设置sql_require_primary_key=ON，并且可以在组复制通道中将REQUIRE_TABLE_PRIMARY_KEY_CHECK语句的CHANGE REPLICATION SOURCE TO选项设置为ON。但是，请注意，您可能会发现一些在组复制的内置检查下被允许的事务，在设置sql_require_primary_key=ON或REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON进行检查时并不被允许。Primary Keys.  Every table that is to be replicated by the group must have a defined primary key, or primary key equivalent where the equivalent is a non-null unique key. Such keys are required as a unique identifier for every row within a table, enabling the system to determine which transactions conflict by identifying exactly which rows each transaction has modified. Group Replication has its own built-in set of checks for primary keys or primary key equivalents, and does not use the checks carried out by the sql_require_primary_key system variable. You may set sql_require_primary_key=ON for a server instance where Group Replication is running, and you may set the REQUIRE_TABLE_PRIMARY_KEY_CHECK option of the CHANGE REPLICATION SOURCE TO statement to ON for a Group Replication channel. However, be aware that you might find some transactions that are permitted under Group Replication's built-in checks are not permitted under the checks carried out when you set sql_require_primary_key=ON or REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON.

网络性能。 MySQL 群组复制旨在部署在服务器实例彼此非常接近的集群环境中。群组的性能和稳定性可能会受到网络延迟和网络带宽的影响。必须在所有群组成员之间始终保持双向通信。如果某个服务器实例的入站或出站通信被阻止（例如，由防火墙或连接问题造成），该成员将无法在群组中正常工作，并且群组成员（包括出现问题的成员）可能无法报告受影响服务器实例的正确成员状态。Network Performance.  MySQL Group Replication is designed to be deployed in a cluster environment where server instances are very close to each other. The performance and stability of a group can be impacted by both network latency and network bandwidth. Bi-directional communication must be maintained at all times between all group members. If either inbound or outbound communication is blocked for a server instance (for example, by a firewall, or by connectivity issues), the member cannot function in the group, and the group members (including the member with issues) might not be able to report the correct member status for the affected server instance.

您可以使用基于 IPv4、IPv6 或两者混合的网络基础设施，在远程群组复制服务器之间进行 TCP 通信。也没有任何因素阻止群组复制通过虚拟专用网络（VPN）运行。You can use a network infrastructure based on IPv4, IPv6, or a mix of the two, for TCP communication between remote Group Replication servers. There is also nothing preventing Group Replication from operating over a virtual private network (VPN).

当组复制服务器实例共同部署并共享本地组通信引擎（XCom）实例时，会尽可能使用具有较低开销的专用输入通道进行通信，而不是使用 TCP 套接字。对于某些需要远程 XCom 实例间通信的组复制任务，例如加入组，仍然使用 TCP 网络，因此网络性能会影响组的性能。Where Group Replication server instances are co-located and share a local group communication engine (XCom) instance, a dedicated input channel with lower overhead is used for communication where possible instead of the TCP socket. For certain Group Replication tasks that require communication between remote XCom instances, such as joining a group, the TCP network is still used, so network performance influences the group's performance.

唯一服务器标识符。 使用 server_id 系统变量为服务器配置唯一的服务器 ID，这是所有复制拓扑中服务器的必需要求。服务器 ID 必须是介于 1 和 (2³²)−1 之间的正整数，并且必须与复制拓扑中任何其他服务器使用的服务器 ID 不同。Unique Server Identifier.  Use the server_id system variable to configure the server with a unique server ID, as required for all servers in replication topologies. The server ID must be a positive integer between 1 and (2³²)−1, and it must be different from every other server ID in use by any other server in the replication topology.

二进制日志已启用。 在 MySQL 8.4 中，默认启用二进制日志。您可以选择使用 --log-bin[=log_file_name] 指定二进制日志文件的名称。组复制会复制二进制日志的内容，因此二进制日志必须启用才能运行组复制。请参见 第 7.4.4 节，“二进制日志”。Binary Log Active.  In MySQL 8.4, binary logging is enabled by default. You can optionally specify the names of the binary log files using --log-bin[=log_file_name]. Group Replication replicates the binary log's contents, therefore the binary log needs to be on for it to operate. See Section 7.4.4, “The Binary Log”.

复制更新已记录。 如果尚未启用，请设置 log_replica_updates=ON。（在 MySQL 8.4 中，这是默认设置。）组成员需要记录在加入时从其捐赠者接收并通过复制应用程序应用的事务，并记录他们从组中接收并应用的所有事务。这使得组复制能够通过从现有组成员的二进制日志进行状态传输来执行分布式恢复。Replica Updates Logged.  Set log_replica_updates=ON if it is not already enabled. (In MySQL 8.4, this is the default.) Group members need to log transactions that are received from their donors at joining time and applied through the replication applier, and to log all transactions that they receive and apply from the group. This enables Group Replication to carry out distributed recovery by state transfer from an existing group member's binary log.

二进制日志行格式。 如有必要，请设置 binlog_format=ROW；在 MySQL 8.4 中，这是默认设置。组复制依赖基于行的复制格式，将更改一致地传播到组中的各个服务器，并提取必要的信息以检测在组中不同服务器上同时执行的事务之间的冲突。REQUIRE_ROW_FORMAT 的设置会自动添加到组复制的通道中，以在应用事务时强制使用基于行的复制。参见 第 19.2.1 节，“复制格式” 和 第 19.3.3 节，“复制权限检查”。Binary Log Row Format.  Set binlog_format=ROW if necessary; in MySQL 8.4, this is the default. Group Replication relies on the row-based replication format to propagate changes consistently among the servers in the group, and extract the necessary information to detect conflicts among transactions that execute concurrently in different servers in the group. The setting for REQUIRE_ROW_FORMAT is automatically added to Group Replication's channels to enforce the use of row-based replication when the transactions are applied. See Section 19.2.1, “Replication Formats” and Section 19.3.3, “Replication Privilege Checks”.

全局事务标识符启用。 设置 gtid_mode=ON 和 enforce_gtid_consistency=ON。这些设置不是默认值。基于 GTID 的复制是组复制所必需的，它使用全局事务标识符来跟踪组中每个服务器实例上已提交的事务。参见 第 19.1.3 节，“使用全局事务标识符的复制”。Global Transaction Identifiers On.  Set gtid_mode=ON and enforce_gtid_consistency=ON. These settings are not the defaults. GTID-based replication is required for Group Replication, which uses global transaction identifiers to track the transactions that have been committed on every server instance in the group. See Section 19.1.3, “Replication with Global Transaction Identifiers”.

此外，如果需要设置 gtid_purged 的值，必须在组复制未运行时进行设置。In addition, if you need to set the value of gtid_purged, you must do so while Group Replication is not running.

默认表加密。 在所有组成员上将 default_table_encryption 设置为相同的值。默认的模式和表空间加密可以启用（ON）或禁用（OFF，默认值），只要所有成员上的设置一致即可。Default Table Encryption.  Set default_table_encryption to the same value on all group members. Default schema and tablespace encryption can be either enabled (ON) or disabled (OFF, the default) as long as the setting is the same on all members.

在 Group Replication 运行时，default_table_encryption 的值无法更改。The value of default_table_encryption cannot be changed while Group Replication is running.

小写表名。 在所有组成员上将 lower_case_table_names 设置为相同的值。对于使用 InnoDB 存储引擎（Group Replication 所需），设置为 1 是正确的。注意，这个设置并不是所有平台的默认值。Lower Case Table Names.  Set lower_case_table_names to the same value on all group members. A setting of 1 is correct for the use of the InnoDB storage engine, which is required for Group Replication. Note that this setting is not the default on all platforms.

多线程应用程序。组复制成员可以配置为多线程副本，使事务可以并行应用。所有副本默认配置为多线程。replica_parallel_workers 的非零值可在成员上启用多线程应用程序。默认值为 4 个并行应用线程；最多可以指定 1024 个并行应用线程。对于多线程副本，还需要以下设置：Multithreaded Appliers.  Group Replication members can be configured as multithreaded replicas, enabling transactions to be applied in parallel. All replicas are configured as multithreaded by default. A nonzero value for replica_parallel_workers enables the multithreaded applier on the member. The default is 4 parallel applier threads; up to 1024 parallel applier threads can be specified. For a multithreaded replica, the following is also required:

将 replica_parallel_workers=0 设置会禁用并行执行，并为副本提供单个应用线程且没有协调线程。在该设置下，replica_parallel_type 和 replica_preserve_commit_order 选项无效且会被忽略。如果在副本上使用 GTID 时禁用并行执行，副本实际上会使用一个并行工作线程，以利用无需访问文件位置即可重试事务的方法。然而，这种行为对用户没有任何影响。Setting replica_parallel_workers=0 disables parallel execution and gives the replica a single applier thread and no coordinator thread. With that setting, the replica_parallel_type and replica_preserve_commit_order options have no effect and are ignored. If parallel execution is disabled when GTIDs are in use on a replica, the replica actually uses one parallel worker, to take advantage of the method for retrying transactions without accessing the file positions. However, this behavior does not change anything for the user.

分离的 XA 事务。 MySQL 8.4 及更高版本支持分离的 XA 事务。分离事务是指一旦准备好后，就不再与当前会话连接的事务。这会在执行 XA PREPARE 时自动发生。已准备好的 XA 事务可以由另一个连接提交或回滚，然后当前会话可以启动另一个 XA 事务或本地事务，而无需等待刚准备好的事务完成。Detached XA transactions.  MySQL 8.4 and later supports detached XA transactions. A detached transaction is one which, once prepared, is no longer connected to the current session. This happens automatically as part of executing XA PREPARE. The prepared XA transaction can be committed or rolled back by another connection, and the current session can then initiate another XA transaction or local transaction without waiting for the transaction that was just prepared to complete.

当启用分离 XA 事务支持时（xa_detach_on_prepare = ON），任何连接到该服务器的连接都可以列出（使用 XA RECOVER）、回滚或提交任何已准备的 XA 事务。此外，您不能在分离的 XA 事务中使用临时表。When detached XA transaction support is enabled (xa_detach_on_prepare = ON) it is possible for any connection to this server to list (using XA RECOVER), roll back, or commit any prepared XA transaction. In addition, you cannot use temporary tables within detached XA transactions.

您可以通过将 xa_detach_on_prepare 设置为 OFF 来禁用对分离 XA 事务的支持，但这不推荐。尤其是，如果该服务器被设置为 MySQL 组复制中的一个实例，您应该将此变量保持为默认值（ON）。You can disable support for detached XA transactions by setting xa_detach_on_prepare to OFF, but this is not recommended. In particular, if this server is being set up as an instance in MySQL group replication, you should leave this variable set to its default value (ON).

有关更多信息，请参阅第 15.3.8.2 节，“XA 事务状态”。See Section 15.3.8.2, “XA Transaction States”, for more information.