组复制要求
数据必须存储在InnoDB事务存储引擎中。事务以乐观方式执行，然后在提交时检查冲突。如果存在冲突，为了保持整个组的一致性，将回滚一些事务，因此需要事务存储引擎。此外，InnoDB还提供了一些附加功能，可以在与组复制一起操作时更好地管理和处理冲突。使用其它存储引擎（包括临时MEMORY存储引擎）可能会导致组复制出错。可以通过在组成员上设置disabled_storage_engines系统变量来阻止使用其它存储引擎，例如：disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
组复制的每个表必须具有主键，或者具有等效的非空唯一键。它们作为表中每一行的唯一标识符是必需的，这使得系统能够通过准确识别每个事务已修改的行来确定哪些事务存在冲突。
网络性能会影响组的性能，网络延迟和网络带宽都会影响组复制性能及稳定性。因此组复制中的MySQL服务器实例应该部署在彼此非常接近的集群环境中，使得所有组成员之间始终保持双向通信。如果阻止服务器实例的收发消息（例如通过防火墙限制），则该成员无法在组中运行，并且组成员（包括有问题的成员）可能无法报告受影响的服务器实例的正确成员状态。从MySQL 8.0.14开始，可以使用IPv4或IPv6网络基础结构，或两者的混合，用于远程组复制服务器之间的TCP通信。
设置--log-bin [= log_file_name] 激活二进制日志，MySQL 8中缺省启用此选项。与其它MySQL复制方式一样，组复制需要复制二进制日志内容，因此需要打开二进制日志才能运行。
设置--log-slave-updates 记录从库更新。服务器需要记录通过复制应用程序应用的二进制日志。组中的服务器需要记录它们收到的所有事务并从组中应用。这是必需的，因为分布式恢复依赖组中成员的二进制日志进行。因此，每个事务的副本都需要存在于每个服务器上，即使对于那些未在服务器本身上启动的事务也是如此。MySQL 8中缺省启用此选项。
设置--binlog-format = row 将二进制日志设为行格式。组复制依赖于基于行的复制格式，以在组成员之间一致地传播更改。它依赖于基于行的基础结构来提取必要信息，以检测在组中不同服务器并发执行的事务之间的冲突。
设置--binlog-checksum = NONE 关闭二进制日志校验。由于复制事件校验和的设计限制，组复制无法使用它们，因此必须禁用。
设置--gtid-mode = ON 开启全局事务标识符。组复制使用全局事务标识符来准确跟踪在每个服务器实例上已提交的事务，从而能够推断哪些服务器执行的事务可能与其它地方已提交的事务冲突。
设置--master-info-repository = TABLE和--relay-log-info-repository = TABLE，将复制信息资料库存储到表中。复制应用程序需要将主库信息和中继日志元数据写入mysql.slave_master_info和mysql.slave_relay_log_info系统表。这可确保组复制插件具有一致的可复制性和复制元数据的事务管理。从MySQL 8.0.2开始，这些选项缺省值为TABLE，而从MySQL 8.0.3开始，不推荐使用FILE设置。
设置--transaction-write-set-extraction = XXHASH64，以便在以将数据行记录到二进制日志时，服务器也会收集写入集。写入集基于每行的主键，唯一标识已更改的行，用于检测事务冲突。MySQL 8中缺省启用此选项。
推荐设置slave_parallel_workers为大于零的值，启用组成员上的多线程复制应用程序，最多可以指定1024个并行复制应用程序线程。设置slave_preserve_commit_order = 1，确保并行事务的最终提交与原始事务的顺序相同，这是组复制所需的，它依赖于所有组成员以相同顺序接收和应用已提交事务，以保证并行事务的数据一致性。slave_preserved_commit_order = 1需要设置slave_parallel_type = LOGICAL_CLOCK，该策略指定用于决定允许哪些事务在从库上并行执行的策略。设置slave_parallel_workers = 0会禁用并行复制，并为从库提供单个应用程序线程，而不是协调器线程。使用该设置，slave_parallel_type和slave_preserve_commit_order选项无效并被忽略。
组复制限制
认证过程没有考虑间隙锁。除非应用程序中依赖REPEATABLE READ语义，否则MySQL建议将READ COMMITTED隔离级别与组复制一起使用InnoDB在READ COMMITTED中不使用间隙锁，它将InnoDB中的本地冲突检测与组复制执行的分布式冲突检测统一化。
认证过程不考虑表锁（LOCK TABLES和UNLOCK TABLES）或命名锁（GET_LOCK）
复制不支持SERIALIZABLE隔离级别。将事务隔离级别设置为SERIALIZABLE会将使组拒绝提交事务。
使用多主模式时，不支持针对同一对象但在不同服务器上执行的并发数据定义语句（DDL）和数据操作语句（DML）。
多主模式不支持具有多级外键依赖关系的表，特别是具有已定义CASCADING外键约束的表。MySQL建议在多主模式组复制中设置group_replication_enforce_update_everywhere_checks = ON，以避免未检测到的冲突。
当组复制以多主模式运行时，SELECT .. FOR UPDATE语句可能导致死锁。
全局复制过滤器不能在为组复制配置的MySQL服务器实例上使用。
如果单个事务太大，以至于在5秒钟内无法通过网络在组成员之间复制消息，则可能会怀疑成员失败，然后被移出组。由于内存分配问题，大型事务也可能导致系统速度变慢。要避免这些问题，使用以下缓解措施：
尽可能尝试限制事务规模。例如，将与LOAD DATA一起使用的文件拆分为较小的块。
使用系统变量group_replication_transaction_size_limit指定组接收的最大事务大小。超过此大小的事务将回滚，不会发送到组。在MySQL 8.0中，此系统变量缺省值为150000000字节（大约143 MB）。
从MySQL 8.0.13开始，可以使用系统变量group_replication_member_expel_timeout来允许在怀疑失败的成员在被移出之前有更多的时间。可以在最初的5秒检测期后最多延长一个小时。
从MySQL 8.0.16开始，大型消息会自动分段，这意味着大型消息不会触发引发怀疑的5秒检测周期，除非此时存在其它网络问题。为了使复制组使用分段，所有组成员必须处于MySQL 8.0.16或更高版本，并且组使用的组复制通信协议版本必须允许分段。如果MySQL版本不支持消息分段，可以使用系统变量group_replication_communication_max_message_size来调整最大消息大小，缺省值为10485760字节（10 MB），或通过指定零值来关闭分段。