一个组最多可以包含 9 台服务器。尝试向拥有 9 个成员的组中添加另一台服务器会导致加入请求被拒绝。通过测试和基准测试，该限制已被确定为一个安全边界，在该边界内，组在稳定的局域网上能够可靠地执行。

组中的服务器通过打开对等 TCP 连接连接到组中的其他服务器。这些连接仅用于组中服务器之间的内部通信和消息传递。此地址由 group_replication_local_address 变量配置。

引导标志指示成员创建一个组并充当初始种子服务器。加入该组的第二个成员需要请求引导该组的成员动态更改配置，以便将其添加到该组中。

在两种情况下，成员需要引导组。在最初创建组时，或者在关闭并重新启动整个组时。

可以使用 CHANGE REPLICATION SOURCE TO 语句永久设置用户凭据作为 group_replication_recovery 通道的凭据。您可以在每次启动组复制时在 START GROUP_REPLICATION 语句中指定它们。

使用 CHANGE REPLICATION SOURCE TO 设置的用户凭据以纯文本形式存储在服务器上的复制元数据存储库中，但在 START GROUP_REPLICATION 上指定的用户凭据仅保存在内存中，并由 STOP GROUP_REPLICATION 语句或服务器关闭删除。因此，使用 START GROUP_REPLICATION 指定用户凭据有助于保护组复制服务器免遭未经授权的访问。但是，此方法与自动启动组复制不兼容，如 group_replication_start_on_boot 系统变量所指定。有关更多信息，请参阅 第 20.6.3.1 节，“用于分布式恢复的安全用户凭据”。

不能直接扩展，但 MySQL 组复制是一种无共享的完全复制解决方案，其中组中的所有服务器都复制相同数量的数据。因此，如果组中的一个成员由于事务提交操作而向存储写入 N 个字节，则其他成员上也会向存储写入大约 N 个字节，因为事务在所有地方都进行了复制。

但是，鉴于其他成员不必执行与原始成员在最初执行事务时必须执行的相同数量的处理，因此它们应用更改的速度更快。事务以仅用于应用行转换的格式进行复制，而无需再次重新执行事务（基于行的格式）。

此外，鉴于更改是以基于行的格式传播和应用的，这意味着它们是以优化且紧凑的格式接收的，并且与原始成员相比，可能减少了所需的 IO 操作次数。

总而言之，您可以通过将无冲突事务分散到组中的不同成员来扩展处理。您还可以扩展一小部分 IO 操作，因为远程服务器仅接收对稳定存储进行读-修改-写更改所需的更改。

预计会有一些额外的负载，因为服务器需要不断地相互交互以进行同步。很难量化有多少数据。它还取决于组的大小（三个服务器对带宽的要求低于组中的九个服务器）。

此外，内存和 CPU 占用量也更大，因为服务器同步部分和组消息传递需要完成更复杂的工作。

可以，但每个成员之间的网络连接必须可靠并具有合适的性能。低延迟、高带宽网络连接是获得最佳性能的必要条件。

如果仅网络带宽是一个问题，则可以使用 第 20.7.4 节，“消息压缩” 来降低所需的带宽。但是，如果网络丢包，导致重新传输和更高的端到端延迟，则吞吐量和延迟都会受到负面影响。

这取决于连接问题的原因。如果连接问题是暂时的，并且重新连接的速度足够快，以至于故障检测器没有意识到它，则服务器可能不会从组中移除。如果这是一个“长时间”的连接问题，那么故障检测器最终会怀疑出现问题，并将服务器从组中移除。

有两个设置可以增加成员保留在组中或重新加入组的机会

如果服务器从组中被驱逐，并且任何自动重新加入尝试均未成功，则您需要将其重新加入。换句话说，在服务器从组中被显式移除后，您需要手动将其重新加入（或使用脚本自动执行此操作）。

如果成员变得静默，则其他成员会将其从组配置中移除。在实践中，当成员崩溃或网络断开连接时，可能会发生这种情况。

在给定成员的给定超时时间过后，将检测到故障，并创建一个不包含静默成员的新配置。

没有定义何时自动从组中驱逐成员的策略的方法。您需要找出成员落后的原因并解决该问题，或者将成员从组中移除。否则，如果服务器速度太慢以至于触发了流量控制，那么整个组也会变慢。可以根据您的需要配置流量控制。

不，组中没有专门负责触发重新配置的成员。

任何成员都可能怀疑存在问题。所有成员都需要（自动）同意给定成员已失败。一个成员负责通过触发重新配置将其从组中驱逐。哪个成员负责驱逐该成员不是您可以控制或设置的。

组复制旨在提供高可用的副本集；数据和写入操作会在组中的每个成员上复制。为了扩展到单个系统所能提供的范围之外，您需要围绕多个组复制集构建编排和分片框架，其中每个副本集维护和管理总数据集的给定分片或分区。这种类型的设置（通常称为“分片集群”）允许您线性地、无限制地扩展读取和写入操作。

如果启用了 SELinux（您可以使用 sestatus -v 进行验证），则需要启用组复制通信端口的使用。请参阅设置组复制的 TCP 端口上下文。

如果启用了 iptables，则需要打开组复制端口，以便在机器之间进行通信。要查看每台机器上的当前规则，请发出 iptables -L。假设配置的端口为 33061，请通过发出 iptables -A INPUT -p tcp --dport 33061 -j ACCEPT 来启用通过必要端口的通信。

组复制使用的复制通道的行为方式与异步源到副本复制中使用的复制通道相同，因此依赖于中继日志。如果 relay_log 变量发生更改，或者未设置该选项且主机名发生更改，则可能会出现错误。有关这种情况下的恢复过程，请参阅第 19.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.100.179 用于 hostname，将 3306 用于 port。然后，客户端 SQL 应用程序将连接到 198.51.100.179:3306 上的成员。这使您能够在不同的网络上配置不同的规则。类似地，可以将内部组通信与用于客户端应用程序的网络连接分开，以提高安全性。

组复制使用成员之间的网络连接，因此其功能直接受您如何配置主机名和端口的影响。例如，组复制的分布式恢复过程使用服务器的主机名和端口创建到现有组成员的连接。当成员加入组时，它会使用 performance_schema.replication_group_members 中列出的网络地址信息来接收组成员信息。该表中列出的成员之一被选为从组到加入成员的缺失数据的提供者。

这意味着您使用主机名配置的任何值（例如 SQL 网络地址或组种子地址）都必须是完全限定名称，并且可以由组的每个成员解析。例如，您可以通过 DNS、正确配置的 /etc/hosts 文件或其他本地进程来确保这一点。如果您想在服务器上配置 MEMBER_HOST 值，请在将其加入组之前，使用服务器上的 --report-host 选项指定它。

要在服务器上配置 MEMBER_PORT，请使用 report_port 系统变量指定它。

在服务器上启动组复制时，auto_increment_increment 的值会更改为 group_replication_auto_increment_increment 的值（默认为 7），auto_increment_offset 的值会更改为服务器 ID。当组复制停止时，这些更改将被还原。这些设置避免了为组成员上的写入操作选择重复的自动递增值，这会导致事务回滚。组复制的默认自动递增值 7 表示可用值的数量与允许的最大复制组大小（9 个成员）之间的平衡。

仅当 auto_increment_increment 和 auto_increment_offset 均为其默认值（在两种情况下均为 1）时，才会进行和还原更改。如果它们的值已从默认值修改，则组复制不会更改它们。当组复制处于单主模式（其中只有一个服务器写入）时，也不会修改系统变量。

如果组在单主模式下运行，则找到哪个成员是主服务器可能很有用。请参阅第 20.1.3.1.2 节“查找主服务器”