InnoDB存储引擎。数据必须存储在InnoDB事务性存储引擎。事务被乐观地执行，然后在提交时检查是否存在冲突。如果有冲突，为了保持整个组的一致性，一些事务会被回滚。这意味着需要一个事务性存储引擎。此外,InnoDB提供了一些额外的功能，在与组复制一起操作时，可以更好地管理和处理冲突。使用其他存储引擎，包括临时内存存储引擎，可能会导致组复制错误。通过设置，可以防止使用其他存储引擎disabled_storage_engines组成员的系统变量，例如:

disabled_storage_engines = " MyISAM、黑洞、联合、归档、记忆”

主键。每个要被组复制的表必须有一个已定义的主键，或者等效的主键，其中等效的是一个非空唯一键。这样的键需要作为表中每一行的唯一标识符，使系统能够通过准确识别每个事务修改了哪些行来确定哪些事务发生冲突。组复制对主键或主键等价物有自己的内置检查集，并且不使用sql_require_primary_key系统变量。你可以设置sql_require_primary_key =对对于正在运行组复制的服务器实例，您可以设置REQUIRE_TABLE_PRIMARY_KEY_CHECK选择的将复制源更改为|改变主声明在用于组复制通道。但是，请注意，您可能会发现在组复制的内置检查下允许的一些事务在您设置时执行的检查下不允许sql_require_primary_key =对或REQUIRE_TABLE_PRIMARY_KEY_CHECK =对。

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

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

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

独特的服务器标识符。使用server_idsystem变量，为服务器配置唯一的服务器ID，这对于复制拓扑中的所有服务器都是必需的。服务器ID必须是1到(2)之间的正整数³²−1，并且它必须不同于复制拓扑中任何其他服务器正在使用的其他服务器ID。

二进制日志活动。集——log-bin [= log_file_name]。从MySQL 8.0开始，默认启用二进制日志记录，除非您想更改二进制日志文件的名称，否则不需要指定此选项。Group Replication复制二进制日志的内容，因此需要打开二进制日志才能进行操作。看到第5.4.4节“二进制日志”。

副本更新记录。集log_replica_updates =对(从MySQL 8.0.26)或log_slave_updates =对(在MySQL 8.0.26之前)。从MySQL 8.0开始，这个设置是默认的，所以你不需要指定。组成员需要记录在加入时从他们的捐赠者接收到的事务，并通过复制应用程序申请，并记录他们从组中接收和申请的所有事务。这使得Group Replication可以从现有组成员的二进制日志中通过状态传输进行分布式恢复。

二进制日志行格式。集binlog_format =行。此设置为默认设置，因此不需要指定。。Group Replication依赖于基于行的复制格式，在组中的服务器之间一致地传播更改，并提取必要的信息，以检测在组中不同服务器中并发执行的事务之间的冲突。从MySQL 8.0.19，的REQUIRE_ROW_FORMAT设置会自动添加到Group Replication的通道中，以在应用事务时强制使用基于行的复制。看到第17.2.1节，“复制格式”和第17.3.3节，“复制权限检查”。

二进制日志校验和关闭(MySQL 8.0.20)。到并包括MySQL 8.0.20，设置binlog_checksum =没有。在这些版本中，Group Replication不能使用校验和，也不支持校验和出现在二进制日志中。从MySQL 8.0.21开始，Group Replication支持校验和，所以组成员可以使用默认设置binlog_checksum = CRC32，不需要指定。

全局事务标识符开启。集gtid_mode =对和enforce_gtid_consistency =对。这些设置不是默认设置。Group replication需要基于gtid的复制，它使用全局事务标识符来跟踪组中每个服务器实例上已提交的事务。看到第17.1.3节，“使用全局事务标识符的复制”。

复制信息存储库。集master_info_repository =表和relay_log_info_repository =表。在MySQL 8.0中，这些设置是默认的，而文件设置是弃用。从MySQL 8.0.23开始，这些系统变量的使用已被弃用，所以省略这些系统变量，只允许默认设置。复制应用程序需要将复制元数据写入mysql.slave_master_info和mysql.slave_relay_log_info系统表，以确保组复制插件具有一致的可恢复性和事务管理的复制元数据。看到第17.2.4.2节，“复制元数据存储库”。

事务写集提取。集transaction_write_set_extraction = XXHASH64因此，在收集行并将它们记录到二进制日志的同时，服务器也会收集写集。在MySQL 8.0中，这个设置是默认的，而从MySQL 8.0.26开始，系统变量的使用已被弃用。写集基于每一行的主键，是一个标记的简化和紧凑视图，唯一标识被更改的行。Group Replication使用此信息对所有组成员进行冲突检测和认证。

默认表加密。集default_table_encryption到所有组成员的相同值。默认模式和表空间加密可以被启用(在)或已残疾(从，默认值)，只要所有成员的设置都是相同的。

小写表名。集lower_case_table_names到所有组成员的相同值。的使用，设置为1是正确的InnoDB存储引擎，这是组复制所需的。注意，这个设置不是所有平台的默认设置。

二进制日志依赖跟踪。设置binlog_transaction_dependency_tracking = WRITESET_SESSION可以提高组成员的性能，取决于组成员的工作量。当从中继日志中应用事务时，Group Replication在认证后执行自己的并行化，独立于设置的值binlog_transaction_dependency_tracking。然而，的价值binlog_transaction_dependency_tracking会影响事务如何写入Group Replication成员上的二进制日志。这些日志中的依赖信息用于帮助从捐赠者的二进制日志进行分布式恢复的状态传输过程，该过程在成员加入或重新加入组时发生。

多线程的类型。Group Replication成员可以配置为多线程副本，使事务可以并行应用。系统变量的非零值replica_parallel_workers(从MySQL 8.0.26)或slave_parallel_workers(在MySQL 8.0.26之前)在成员上启用多线程应用程序，最多可以指定1024个并行应用程序线程。如果你这样做，还需要以下设置:

设置replica_parallel_workers = 0或slave_parallel_workers = 0禁用并行执行，并给副本一个单一的应用程序线程和没有协调线程。有了这个设置，replica_parallel_type或slave_parallel_type和replica_preserve_commit_order或slave_preserve_commit_order选项没有效果，会被忽略。