本节提供了常见问题的答案。
一个组最多可以由 9 个服务器组成。试图将另一台服务器添加到具有 9 个成员的组中会导致加入请求被拒绝。该限制已通过测试和基准测试被确定为一个安全边界，在该边界内，组可在稳定的局域网上可靠地运行。
组中的服务器通过打开对等 TCP 连接连接到组中的其他服务器。这些连接仅用于组中服务器之间的内部通信和消息传递。此地址由 group_replication_local_address 变量配置。
引导标志指示成员创建组并充当初始种子服务器。加入组的第二个成员需要请求引导组的成员动态更改配置，以便将其添加到组中。
成员需要在两种情况下引导组。最初创建组时，或关闭并重新启动整个组时。
您可以使用CHANGE REPLICATION SOURCE TO语句（MySQL 8.0.23 以后）或CHANGE MASTER TO语句（MySQL 8.0.233 之前）将用户证书永久设置为group_replication_recovery通道的证书。或者，自 MySQL 8.0.21 以后，您可以在每次启动组复制时在START GROUP_REPLICATION语句中指定它们。
使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO设置的用户证书以纯文本形式存储在服务器上的复制元数据存储库中，但START GROUP_REPLICATION上指定的用户证书仅保存在内存中，并通过STOP GROUP_RESPLICATION语句或服务器关闭删除。因此，使用START GROUP_REPLICATION指定用户证书有助于保护组复制服务器免受未经授权的访问。但是，此方法与 group_replication_start_on_boot 系统变量指定的自动启动组复制不兼容。有关详细信息，请参阅 第 18.6.3.1 节 “分布式恢复的安全用户证书”。
不是直接的，但 MySQL 组复制是一种无共享的完全复制解决方案，其中组中的所有服务器都复制相同数量的数据。因此，如果作为事务提交操作的结果，组中的一个成员将 N 个字节写入存储，那么其他成员上的存储也将写入大约 N 个字节，因为事务被复制到各处。
但是，考虑到其他成员不必执行原始成员在最初执行事务时必须执行的相同数量的处理，他们可以更快地应用更改。事务以仅用于应用行转换的格式复制，而无需再次重新执行事务（基于行格式）。
此外，考虑到以基于行格式传播和应用更改，这表示以优化的、紧凑的格式接收更改，与原始成员相比，可能会减少所需的 IO 操作数。
总之，您可以通过在组中的不同成员之间传播无冲突事务来扩展处理。而且，由于远程服务器只接收到对稳定存储的 读-修改-写（read-modify-write） 更改所需的更改，因此您可能会减少一小部分 IO 操作。
预计会有一些额外的负载，因为出于同步目的，服务器需要不断地相互交互。很难量化多了多少数据。它还取决于组的大小（3 台服务器比组中的 9 台服务器对带宽要求的压力更小）。
内存和 CPU 占用也更大，因为服务器同步部分和组消息传递需要做更复杂的工作。
是的，但每个成员之间的网络连接必须可靠并具有适当的性能。低延迟、高带宽的网络连接是最佳性能的要求。
如果仅网络带宽是一个问题，则可以使用 第 18.7.4 节 “消息压缩” 来降低所需的带宽。然而，如果网络丢失数据包，导致重新传输和更高的端到端延迟，吞吐量和延迟都会受到负面影响。
警告
当任何组成员之间的网络往返时间（RTT）为 5 秒或更长时，您可能会遇到问题，因为内置故障检测机制可能会被错误触发。
这取决于产生连接问题的原因。如果连接问题是暂时的，并且重新连接足够快，以至于故障检测器没有意识到，那么服务器可能不会从组中删除。如果这是一个“长”连接问题，那么故障检测器最终会怀疑该问题，并将服务器从组中删除。
在 MySQL 8.0 中，有两种设置可以增加成员留在组中或重新加入组的机会：
如果服务器被逐出组，并且任何自动重新加入尝试都不成功，则需要重新加入。换句话说，从组中显式删除服务器后，您需要手动重新加入它（或用脚本自动执行）。
如果该成员变为静默状态，则其他成员会将其从组配置中删除。实际上，这可能发生在成员崩溃或网络断开时。
在给定成员经过给定超时后检测到故障，并创建一个不包含静默成员的新配置。
没有方法定义何时将成员自动从组中驱逐的策略。您需要找出某个成员落后的原因，并解决该问题或将该成员从组中删除。否则，如果服务器速度太慢以至于触发了流控制，那么整个组也会变慢。流量控制可根据您的需要进行配置。
不，组中没有特殊成员负责触发重新配置。
任何成员都可以怀疑组存在问题。所有成员都需要（自动）同意某个成员失败。一名成员负责通过触发重新配置将其逐出团队。您无法控制或设置哪个成员负责驱逐该成员。
组复制旨在提供高度可用的副本集；在组中的每个成员上复制数据和写入（行为）。为了扩展单个系统所能提供的范围，您需要一个由多个组复制集构成的编排（Orchestration ）和分片（Sharding ）框架，其中每个副本集维护和管理整个数据集的给定分片或分区。这种类型的设置通常被称为“分片集群（Sharded Cluster）”，允许您无限制地线性扩展读写。
如果 SELinux 已启用（您可以使用sestatus -v验证），则需要启用组复制通信端口的使用。请参阅 设置组复制的 TCP 端口上下文 。
如果启用了 iptables，则需要打开组复制端口以在机器之间进行通信。要查看每台机器上的当前规则，请发出iptables-L。假设配置的端口是 33061 ，通过执行iptables -A INPUT -p tcp --dport 33061 -j ACCEPT来启用必要端口上的通信。
组复制使用的复制通道的行为方式与异步源到副本的复制中使用的复制信道相同，因此依赖于 中继日志（Relay Log） 。如果 relay_log 变量发生更改，或者未设置该选项且主机名发生更改，则可能会发生错误。有关这种情况下的恢复程序，请参阅 第 17.2.4.1 节 “中继日志” 。或者，在组复制中解决此问题的另一种方法是发出STOP GROUP_REPLICATION语句，然后发出START GROUP_REPLICATION语句以重新启动实例。组复制插件再次创建group_replication_applier通道。
组复制使用两个绑定地址，以便在客户端用于与成员通信的 SQL 地址和组成员内部用于通信的 group_replication_local_address 之间分割网络流量。例如，假设一台服务器具有网络地址 203.0.113.1 和 198.51.100.179 的两个被分配的网络接口。在这种情况下，通过设置group_replication_local_address=203.0.113.1:33061，可以将 203.0.113.1:33061 用作内部组网络地址。然后，可以将 198.51.10.179 用作主机名，将 3306 用作端口。然后，客户端 SQL 应用程序将以 198.51.100.179:3306 连接到成员。这使您能够在不同的网络上配置不同的规则。类似地，内部组通信可以与用于客户端应用的网络连接分离，以提高安全性。
组复制使用成员之间的网络连接，因此其功能直接受主机名和端口配置方式的影响。例如，组复制的分布式恢复过程使用服务器的主机名和端口创建到现有组成员的连接。当成员加入组时，它将使用performance_schema.replication_group_members中列出的网络地址信息接收组成员信息。该表中列出的其中一个成员被选为加入成员相对于组所缺失数据的供体。
这表示使用主机名配置的任何值（如 SQL 网络地址或组种子地址）必须是完全限定的名称，并且可以由组的每个成员解析。例如，您可以通过 DNS 、正确配置的/etc/hosts文件或其他本地进程来确保这一点。如果要在服务器上配置MEMBER_HOST值，请在将其加入组之前使用服务器上的--report-host选项指定该值。
重要提示
可直接使用被赋予的值，而不受 skip_name_resolve 系统变量的影响。
要在服务器上配置MEMBER_HOST，请使用 report_port 系统变量指定它。
在服务器上启动组复制时，auto_increment_increment 的值将更改为 group_replication_auto_increment_increment 的默认值 7 ，auto_increment_offset 的值将改为 服务器 ID 。停止组复制时将恢复更改。这些设置避免为组成员上的写入选择重复的自动递增值，这会导致事务回滚。组复制的默认自动增量值 7 代表了可用值的数量与复制组（ 9 个成员）允许的最大大小之间的平衡。
只有当 auto_increment_increment 和 auto_increent_offset 各自的默认值为 1 时，才会进行更改和还原。如果它们的值已经被从默认值修改了，则组复制不会更改它们。在 MySQL 8.0 以后，当组复制处于单主模式（只有一台服务器写入）时，系统变量也不会被修改。
如果组在单主模式下运行，那么找出哪个成员是主成员可能很有用。见 第18.1.3.1.2节，“寻找主服务器”