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

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

主键.  每个要被复制组中的表都必须有定义的主键或等效主键，其中等效主键是非空唯一键。这些键是为了在每个表中确定每行的唯一标识符，从而使系统能够确定哪些事务冲突，通过确定每个事务修改了哪些行。Group Replication有自己的检查机制来检测主键或等效主键，不使用sql_require_primary_key系统变量的检查。你可以将sql_require_primary_key=ON设置到运行Group Replication的服务器实例中，并将CHANGE REPLICATION SOURCE TO语句中的REQUIRE_TABLE_PRIMARY_KEY_CHECK选项设置为ON 以便在Group Replication通道中。但请注意，在将sql_require_primary_key=ON或REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON时，你可能会发现一些事务被允许的，但是在Group Replication的检查机制下不被允许。

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

您可以使用基于 IPv4、IPv6 或这两者的混合网络基础结构来实现远程 Group Replication 服务器之间的 TCP 通信。Group Replication 也可以在虚拟私人网络（VPN）上运行。

当 Group Replication 服务器实例彼此共享本地组通信引擎（XCom）实例时，可以使用具有较低开销的专用输入通道来实现通信，而不是 TCP 套接字。然而，对于需要远程 XCom 实例之间通信的某些 Group Replication 任务，例如加入组，这些任务仍然使用 TCP 网络，因此网络性能将影响组的性能。

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

二进制日志活动.  在MySQL 8.4中，二进制日志默认启用。您可以选择性地指定二进制日志文件名称使用--log-bin[=log_file_name]。群组复制将复制二进制日志的内容，因此需要在其操作时启用二进制日志。请参阅第7.4.4节，“The Binary Log”。

副本更新记录.  如果不是已经启用，请设置log_replica_updates=ON。(在MySQL 8.4中，这是默认值。)群组成员需要在加入时从捐赠者接收事务并通过复制应用程序应用事务，并且需要记录所有从群组接收和应用的事务。这使得群组复制能够通过状态转移从现有群组成员的二进制日志中执行分布式恢复。

二进制日志行格式 如果必要，请设置binlog_ format=ROW；在 MySQL 8.4 中，这是默认值。Group Replication 依赖于行基于的复制格式来 propagate 更改一致地在组中的服务器之间，并从必要信息中提取冲突事务检测的必要信息，以便在不同的服务器中并发执行的事务。在 Group Replication 的通道中，自动添加了REQUIRE_ROW_FORMAT设置，以强制使用行基于的复制格式时应用事务。请参阅第19.2.1节，“Replication Formats”和第19.3.3节，“Replication Privilege Checks”。

全局事务标识符开启 设置gtid_ mode=ON和enforce_gtid_consistency=ON。这些设置不是默认值。基于 GTID 的复制是 Group Replication 所需的，它使用全局事务标识符来跟踪每个服务器实例在组中的事务已经提交了。请参阅第19.1.3节，“Replication with Global Transaction Identifiers”。

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

小写表名.  将lower_case_table_names设置为所有组成员的相同值。设置为1是正确的使用InnoDB存储引擎的用法，该引擎是Group Replication所需的。请注意，这个设置不是所有平台上的默认值。

多线程应用程序.  Group Replication成员可以配置为多线程副本，启用并行事务应用程序。所有副本都默认为多线程。非零值replica_parallel_workers启用成员上的多线程应用程序。默认是4个并行应用程序线程，可以指定最多1024个并行应用程序线程。

设置replica_parallel_workers=0禁用并行执行，并将副本分配一个单独的应用线程和无协调线程。使用该设置时，replica_parallel_type 和replica_preserve_commit_order 选项无效且被忽略。如果在副本上禁用并行执行，并且GTIDs正在使用，那么副本当地使用一个并行工作者，以便利用事务重试方法，而不需要访问文件位置。然而，这种行为对用户没有任何影响。

独立XA事务。 MySQL 8.4 及更高版本支持独立XA事务。独立事务是指，一旦准备好，就不再连接到当前会话。这是作为执行XA PREPARE的一部分自动发生。可以由另一个连接提交或回滚准备好的XA事务，然后当前会话可以继续执行另一个XA事务或本地事务，而不需要等待刚刚准备的事务完成。

当启用 detached XA 事务支持（xa_detach_on_prepare = ON)，任何连接到该服务器的客户端都可以使用XA RECOVER语句来列出、回滚或提交任何准备好的 XA 事务。此外，在 detached XA 事务中不能使用临时表。

可以通过将xa_detach_on_prepare设置为OFF来禁用 detached XA 事务支持，但这不建议。特别是，如果该服务器正在被设置为 MySQL 组复制实例，您应该将该变量留在其默认值（ON）中。

请查看第15.3.8.2节，“XA 事务状态”，了解更多信息。