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

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

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

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

您可以使用 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 节“查找主服务器”