一个组最多可以包含 9 个服务器。尝试将另一台服务器添加到具有 9 个成员的组会导致加入请求被拒绝。这个限制已经从测试和基准测试中确定为一个安全边界，在该边界中，该组可以在稳定的局域网上可靠地运行。

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

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

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

group_replication_recovery您可以使用CHANGE REPLICATION SOURCE TO语句（从 MySQL 8.0.23 开始）或 CHANGE MASTER TO语句（在 MySQL 8.0.23 之前） 将用户凭证永久设置为通道的凭证。或者，从 MySQL 8.0.21 开始，您可以在START GROUP_REPLICATION 每次启动组复制时在语句中指定它们。

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

不直接，但 MySQL Group 复制是一种无共享的完全复制解决方案，其中组中的所有服务器复制相同数量的数据。因此，如果作为事务提交操作的结果，组中的一个成员将 N 字节写入存储，那么其他成员也将大约 N 字节写入存储，因为事务在各处被复制。

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

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

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

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

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

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

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

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

从 MySQL 8.0 开始，有两个设置可用于增加成员留在或重新加入组的机会：

如果服务器被逐出组并且任何自动重新加入尝试均未成功，则您需要重新加入该服务器。换句话说，在服务器从组中明确删除后，您需要手动重新加入它（或让脚本自动执行）。

如果成员变得沉默，其他成员将其从组配置中删除。实际上，当成员崩溃或网络断开时，可能会发生这种情况。

在给定成员的给定超时过去后检测到故障，并且创建了其中没有静默成员的新配置。

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

不，小组中没有负责触发重新配置的特殊成员。

任何成员都可以怀疑有问题。所有成员都需要（自动）同意给定成员失败。一名成员负责通过触发重新配置将其从组中驱逐出去。哪个会员负责开除会员，不是你能控制和设定的。

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

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

如果启用了iptables，则需要打开 Group Replication 端口以实现机器之间的通信。要查看每台机器上的当前规则，请发出 iptables -L。假设配置的端口是 33061，通过发出 iptables -A INPUT -p tcp --dport 33061 -j ACCEPT启用必要端口上的通信。

Group Replication 使用的复制通道的行为方式与异步源到副本复制中使用的复制通道的行为相同，因此依赖于中继日志。如果 relay_log变量发生变化，或者未设置选项且主机名发生变化，则可能会出错。有关这种情况下的恢复过程，请参阅第 17.2.4.1 节，“中继日志”。或者，另一种专门解决组复制问题的方法是先发出一个 STOP GROUP_REPLICATION语句，然后再发出一个START GROUP_REPLICATION 语句来重新启动实例。Group Replication 插件group_replication_applier再次创建通道。

组复制使用两个绑定地址，以便在客户端用于与成员通信的 SQL 地址和 group_replication_local_address组成员内部用于通信的 SQL 地址之间拆分网络流量。例如，假设一个服务器有两个网络接口分配给网络地址203.0.113.1和 198.51.100.179。在这种情况下，您可以203.0.113.1:33061通过设置使用内部组网络地址 group_replication_local_address=203.0.113.1:33061。然后你可以使用198.51.100.179for hostname和 3306for port。然后，客户端 SQL 应用程序将连接到位于 198.51.100.179:3306. 这使您能够在不同的网络上配置不同的规则。同样，内部组通信可以与用于客户端应用程序的网络连接分开，以提高安全性。

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

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

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

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

仅当每个更改的默认值为 1 时，才会进行和恢复更改 auto_increment_increment。 auto_increment_offset如果它们的值已经从默认值修改，组复制不会更改它们。从 MySQL 8.0 开始，当 Group Replication 处于单主模式时，系统变量也不会被修改，其中只有一台服务器写入。

如果该组在单主模式下运行，则找出哪个成员是主成员会很有用。请参阅 第 18.1.3.1.2 节，“查找主节点”