本节提供了常见问题的答案。
一个组最多可以有9台服务器。尝试将另一个服务器添加到已经有9个成员的组中将被拒绝。这个限制来自测试和基准测试,确定了组在稳定的局域网中可靠地执行的安全边界。
组中的服务器通过打开点对点TCP连接来连接其他服务器。这些连接仅用于组内服务器之间的内部通信和消息传递。该地址由 group_replication_local_address
变量配置。
引导标志指示成员 创建 组并充当初始种子服务器。第二个成员加入组时,需要请求引导组的成员动态更改配置,以便将其添加到组中。
成员需要在两个场景中引导组。当组最初创建时,或者当关闭并重新启动整个组时。
您可以永久地将用户凭据设置为 group_replication_recovery
通道的凭据,使用 CHANGE REPLICATION SOURCE TO
语句。您可以在 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 节,“Secure User Credentials for Distributed Recovery”。
不直接,但 MySQL 组复制是一个共享 nothing 全复制解决方案,其中组中的所有服务器复制相同的数据量。因此,如果一个组成员在存储中写入 N 字节作为事务提交操作的结果,那么大约 N 字节将被写入其他成员的存储中,因为事务被复制到 mọi处。
然而,鉴于其他成员不需要执行原始成员执行事务时所需的相同处理,因此他们可以更快地应用更改。事务以行转换格式复制,而不需要重新执行事务(基于行的格式)。
此外,由于更改以行转换格式传播和应用,因此它们以优化的紧凑格式接收,可能减少了与原始成员相比所需的 IO 操作数量。
总之,您可以通过在组中的不同成员之间分配无冲突事务来扩展处理能力。并且,您可能可以扩展一小部分 IO 操作,因为远程服务器仅接收稳定存储中的必要更改。
由于服务器需要不断地相互交互以实现同步,因此预计会增加一些负载。很难量化增加的数据量。它还取决于组的大小(三个服务器组对带宽要求的压力小于九个服务器组)。
此外,内存和 CPU 足迹也较大,因为服务器同步部分和组消息传递需要更多的复杂工作。
可以,但是成员之间的网络连接 必须 是可靠的且性能良好。低延迟、高带宽的网络连接是最佳性能的要求。
如果网络带宽是一个问题,那么 第 20.7.4 节,“消息压缩” 可以用来降低所需的带宽。然而,如果网络丢包,导致重新传输和更高的端到端延迟,那么吞吐量和延迟都会受到负面影响。
当网络往返时间(RTT)在 5 秒或更长时,您可能会遇到问题,因为内置的故障检测机制可能会被错误地触发。
这取决于连接问题的原因。如果连接问题是暂时性的,并且重新连接速度足够快,以至于故障检测器不知道它,那么服务器可能不会从组中删除。如果连接问题较长,那么故障检测器最终会怀疑问题并将服务器从组中删除。
有两个设置可以增加成员留在或重新加入组的机会:
-
group_replication_member_expel_timeout
增加了从怀疑创建到成员被驱逐之间的时间。你可以设置最长 1 小时的等待期,默认为 5 秒。 -
group_replication_autorejoin_tries
使成员在被驱逐或不可达多数超时后尝试重新加入组。成员每 5 分钟尝试重新加入指定次数的自动重新加入尝试。该功能默认启用,成员尝试重新加入三次。
如果服务器从组中被驱逐,并且任何自动重新加入尝试都没有成功,那么您需要手动将其重新加入组(或使用脚本自动执行)。
没有方法来定义自动将成员从组中删除的策略。你需要找到成员落后原因并修复它,或者从组中删除该成员。否则,如果服务器太慢以至于触发流控制,那么整个组也将减慢。流控制可以根据需要进行配置。
不,在组中没有特殊成员负责触发重新配置。
任何成员都可以怀疑组中存在问题。所有成员需要自动同意某个成员已经失败。一个成员负责将其从组中删除,通过触发重新配置。哪个成员负责删除成员是无法控制或设置的。
Group Replication旨在提供高度可用的副本集;数据和写入操作在每个组成员上都被复制。为了超越单个系统的限制,你需要一个围绕多个Group Replication集的编排和分片框架,每个副本集维护和管理数据集的某个分片或分区。这种设置,通常称为“分片集群”,允许你线性地扩展读取和写入操作,而不受限制。
如果启用了SELinux,可以使用sestatus -v验证,那么你需要启用Group Replication通信端口的使用。请参阅为Group Replication设置TCP端口上下文。
如果启用了iptables,那么你需要打开Group Replication端口以便机器之间的通信。要查看每台机器上的当前规则,请使用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
。在这种情况下,您可以使用 203.0.113.1:33061
作为内部组网络地址,通过设置group_replication_local_address=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
选项在加入组之前。
分配的值将被直接使用,不受 skip_name_resolve
系统变量的影响。
要配置 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 节,“找到主服务器”