MySQL 8.0发行说明
MySQL 8.0源代码文档10bet官方网站
组复制存在以下已知限制。请注意，在故障转移事件期间，对多主模式组描述的限制和问题也可以应用于单程模式集群，而新选当的主从旧主机刷掉其应用程序队列。
小费
组复制是基于GTID的复制构建的，因此您还应该了解第17.1.3.7节“对GTID的复制的限制”．
- aupgrade =最小选择。在使用最小选项的MySQL Server升级之后无法启动组复制（- aupgrade =最小），不会升级复制内部依赖的系统表。间隙锁。组复制的并发事务的认证过程不会考虑间隙锁，因为关于差距锁的信息在外面不可用
Innodb.．看间隙锁想要查询更多的信息。表锁和命名锁。认证过程没有考虑表锁（见Section 13.3.6， " LOCK TABLES and UNLOCK TABLES Statements ")或命名锁(参见
get_lock（））。二进制日志校验和。ob and包括mysql 8.0.20，组复制无法使用校验和，并且不支持其在二进制日志中的存在，因此必须设置
binlog_checksum = none配置服务器实例以成为组成员。来自MySQL 8.0.21，组复制支持校验和，因此组成员可以使用默认设置binlog_checksum = CRC32．设置binlog_checksum.对于组的所有成员不一定是相同的。当校验和可用时，组复制不会使用它们来验证传入事件
group_replication_applier频道，因为事件被写入来自多个源的中继日志，并且在它们实际写入始发服务器的二进制日志之前，这是生成校验和时。校验和用于验证事件的完整性group_replication_recovery.频道和组成员上的任何其他复制频道。可延长的隔离级别。
可序列化默认情况下，多主组不支持隔离级别。设置事务隔离级别可序列化配置组复制以拒绝提交事务。并发DDL与DML操作。在使用多主模式时，不支持并发数据定义语句和执行针对同一对象但在不同服务器上执行的数据操作语句。在对象上执行数据定义语言（DDL）语句期间，在同一对象上执行并发数据操作语言（DML），但在不同的服务器实例上具有在未检测到的不同实例上执行冲突的DDL冲突的风险。
带级联约束的外钥匙。多主模式组（所有成员都配置为
group_replication_single_primary_mode =关闭）不支持具有多级外键依赖性的表，具体介绍已定义的表级联外键约束．这是因为导致由多主模式组执行的级联操作的外键约束可能导致未检测到的冲突并导致组中的成员的不一致数据。因此，我们建议设置group_replication_enforce_update_everywhere_checks = on在多主模式组中使用的服务器实例，以避免未检测到的冲突。在单程模式下，这不是问题，因为它不允许并发写入该组的多个成员，因此没有未被发现的冲突的风险。
多主要模式死锁。当组在多主模式下运行时，
选择..进行更新陈述可能导致僵局。这是因为锁未在组的成员身上共享，因此可能无法达到此类语句的期望。复制过滤器。全局复制过滤器无法在配置为组复制的MySQL Server实例上使用，因为某些服务器上的过滤事务将使该组无法在一致状态下达成协议。通道特定的复制过滤器可以用于未直接涉及组复制的复制通道，例如组成员还充当副本到组外部的源。他们不能用在
group_replication_applier或group_replication_recovery.渠道。加密连接。只要使用OpenSSL 1.1.1或更高版本编译MySQL 8.0.16，MySQL Server在MySQL Server中提供了TLSv1.3协议的支持。在MySQL 8.0.16和MySQL 8.0.17中，如果服务器支持TLSv1.3，则组通信引擎不支持该协议，并且不能被组复制使用。组复制支持来自MySQL 8.0.18的TLSv1.3，可用于组通信连接和分布式恢复连接。
在MySQL 8.0.18中，TLSv1.3可以用于组复制的分布式恢复连接，但是
group_replication_recovery_tls_version.和group_replication_recovery_tls_ciphersuites.系统变量不可用。因此，捐赠者服务器必须允许使用默认情况下的至少一个TLSv1.3 CIPHerSuite，如列出的那样，第6.3.2节“加密连接TLS协议和CIPHERS”．从MySQL 8.0.19中，您可以使用选项来配置客户端支持，以了解任何选择的CIPhersuites，包括如果需要的非默认CIPhersuites。克隆业务。组复制启动并管理分布式恢复的克隆操作，但已设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。在MySQL 8.0.20之前的版本中，如果操作涉及运行组复制的组成员，则无法手动启动克隆操作。从MySQL 8.0.20，您可以执行此操作，只要克隆操作不会删除并替换收件人上的数据。因此，发起克隆操作的陈述必须包括
数据目录子句，如果运行组复制。看第18.5.3.2.4节“克隆其他目的”．
如果单个事务导致消息内容足够大的消息内容，则在5秒窗口中的网络中无法在组成员之间复制消息，可以怀疑成员失败，然后驱逐出来，只是因为它们正在繁忙处理交易。大型事务也可能导致系统由于内存分配问题而慢。为避免这些问题，请使用以下缓解：
如果由于大消息而发生不必要的驱逐，请使用系统变量
group_replication_member_expel_timeout.在被驱逐失败的怀疑后额外的时间允许额外的时间。在嫌疑人从组中断之前，您可以在初始的5秒检测期后允许最多一个小时。从MySQL 8.0.21，默认情况下允许额外的5秒钟。在可能的情况下，在按组复制处理之前尝试和限制事务的大小。例如，拆分使用的文件
加载数据进入较小的块。使用系统变量
group_replication_transaction_size_limit.指定组接受的最大事务大小。在MySQL 8.0中，此系统变量默认为最大事务大小为15000万字节（约143 MB）。上面的事务回滚，不会发送到组复制的组通信系统（GCS）以分发给该组。根据您需要该组要容忍的最大消息大小来调整此变量的值，以至于处理处理事务的时间与其大小成比例。使用系统变量
group_replication_compression_threshold.指定上述邮件大小应用了压缩。该系统变量默认为1000000字节（1 MB），因此大消息将自动压缩。当它收到允许的消息时，通过组复制的组通信系统（GCS）进行压缩group_replication_transaction_size_limit.设置但超过group_replication_compression_threshold.环境。有关更多信息，请参阅第18.7.3节“消息压缩”．使用系统变量
group_replication_communication_max_message_size.指定上面的消息大小是碎片化的。此系统变量默认为10485760字节（10个MIB），因此大消息自动分段。如果压缩的消息仍然超过，GCS在压缩后进行碎片化group_replication_communication_max_message_size.限制。为了使复制组使用碎片化，所有组成员必须在MySQL 8.0.16或更高版本中，并且组中使用的组复制通信协议版本必须允许碎片化。有关更多信息，请参阅第18.7.4节“消息碎片”．
可以通过为相关系统变量指定零值来取消激活最大事务大小，消息压缩和消息碎片。如果您已停用所有这些保障措施，则可以在复制组成员上由应用程序线程处理的消息的大小限制是成员的值slave_max_allowed_packet.系统变量，默认值和最大值为1073741824字节（1 GB）。当接收成员尝试处理它时，超过此限制的消息失败。组成员可以发起并尝试传输给组的消息的大小限制为4294967295字节（大约4 GB）。这是对组通信引擎接受的分组大小的难限度，用于组复制（XCOM，PaxoS变体），在GCS处理GC之后接收消息。当始发成员尝试广播时，超过此限制的消息失败。