Group Replication 的故障检测机制旨在识别不再与组进行通信的组成员,并在似乎它们已经发生故障时将其驱逐。拥有故障检测机制可以增加组中包含大多数正常工作的成员的可能性,从而确保来自客户端的请求能够被正确处理。Group Replication's failure detection mechanism is designed to identify group members that are no longer communicating with the group, and expel them as and when it seems likely that they have failed. Having a failure detection mechanism increases the chance that the group contains a majority of correctly working members, and that requests from clients are therefore processed correctly.
通常,所有组成员会定期与其他所有组成员交换消息。如果某个组成员在 5 秒内未收到来自特定成员的任何消息,当此检测期结束时,会产生对该成员的怀疑。当怀疑超时时,怀疑的成员会被认为已失败,并被从组中移除。被移除的成员会从其他成员看到的成员列表中消失,但它自己不知道已经被移除,因此它会认为自己仍然在线,而其他成员则不可达。如果该成员实际上并未失败(例如,仅因为临时网络问题而断开连接),并且能够重新与其他成员通信,它会收到一个视图,其中包含它已被移除出该组的信息。Normally, all group members regularly exchange messages with all other group members. If a group member does not receive any messages from a particular fellow member for 5 seconds, when this detection period ends, it creates a suspicion of the fellow member. When a suspicion times out, the suspected member is assumed to have failed, and is expelled from the group. An expelled member is removed from the membership list seen by the other members, but it does not know that it has been expelled from the group, so it sees itself as online and the other members as unreachable. If the member has not in fact failed (for example, because it was just disconnected due to a temporary network issue) and it is able to resume communication with the other members, it receives a view containing the information that it has been expelled from the group.
组成员对这些情况的反应,包括失败的成员本身,可以在过程的多个环节进行配置。默认情况下,如果怀疑某个成员已失败,会发生以下行为:The responses of group members, including the failed member itself, to these situations can be configured at a number of points in the process. By default, the following behaviors happen if a member is suspected of having failed:
在 MySQL 8.4 中,当产生怀疑时,会增加 5 秒的等待期,在这段时间后怀疑超时,涉嫌失败的成员可能会被开除。In MySQL 8.4, when a suspicion is created, a waiting period of 5 seconds is added before the suspicion times out and the suspected member is liable for expulsion.
如果被开除的成员恢复通信并发现自己已被开除,它会自动尝试重新加入小组三次(每次尝试间隔 5 分钟);如果此自动重新加入程序不起作用,它将停止尝试重新加入小组。If an expelled member resumes communication and realises that it was expelled, it automatically makes three attempts to rejoin the group (with 5 minutes between each attempt); if this auto-rejoin procedure does not work, it then stops trying to rejoin the group.
当被开除的成员不尝试重新加入小组时,它会切换到超级只读模式并等待操作员处理。When an expelled member is not trying to rejoin the group, it switches to super-read-only mode and awaits operator attention.
您可以使用本节中描述的组复制配置选项永久或临时更改这些行为,以满足系统的需求和您的优先级。如果您遇到由于网络或机器较慢、网络中意外短暂中断率较高或计划网络中断而导致的不必要的逐出,请考虑增加逐出超时和自动重新加入尝试次数。当成员正在经历前面描述的任何默认行为时,尽管它不接受写入,但如果该成员仍在与客户端通信,仍然可以执行读取操作,随时间推移产生陈旧读取的可能性会增加。如果避免陈旧读取对您来说比避免操作员干预更优先,请考虑减少逐出超时和自动重新加入尝试次数,或者将其设置为零。You can use the Group Replication configuration options described in this section to change these behaviors either permanently or temporarily, to suit your system's requirements and your priorities. If you are experiencing unnecessary expulsions caused by slower networks or machines, networks with a high rate of unexpected transient outages, or planned network outages, consider increasing the expel timeout and auto-rejoin attempts. While a member is undergoing any of the default behaviors described previously, although it does not accept writes, reads can still be performed if the member is still communicating with clients, with an increasing likelihood of stale reads over time. If avoiding stale reads is a higher priority for you than avoiding operator intervention, consider reducing the expel timeout and auto-rejoin attempts or setting them to zero.
未出现故障的成员可能会由于网络分区而与部分(但不是全部)复制组失去联系。例如,在一个有 5 台服务器(S1、S2、S3、S4、S5)的组中,如果 (S1, S2) 与 (S3, S4, S5) 之间出现断开连接,就会形成网络分区。第一个小组 (S1, S2) 现在处于少数,因为它无法联系到超过一半的组成员。少数组成员处理的任何事务都会被阻塞,因为组的大多数成员无法访问,因此组无法达到仲裁数。如需此场景的详细描述,请参见 第 20.7.8 节,“处理网络分区和仲裁数丢失”。在这种情况下,默认行为是少数和多数成员都保持在组中,继续接受事务(尽管在少数成员上它们会被阻塞),并等待操作员干预。此行为也是可以配置的。Members that have not failed might lose contact with part, but not all, of the replication group due to a network partition. For example, in a group of 5 servers (S1, S2, S3, S4, S5), if there is a disconnection between (S1, S2) and (S3, S4, S5) there is a network partition. The first group (S1, S2) is now in a minority because it cannot contact more than half of the group. Any transactions that are processed by the members in the minority group are blocked, because the majority of the group is unreachable, therefore the group cannot achieve quorum. For a detailed description of this scenario, see Section 20.7.8, “Handling a Network Partition and Loss of Quorum”. In this situation, the default behavior is for the members in both the minority and the majority to remain in the group, continue to accept transactions (although they are blocked on the members in the minority), and wait for operator intervention. This behavior is also configurable.
请注意,如果组成员使用的是较旧版本的 MySQL 服务器,该版本不支持相关设置,或使用的是默认值不同的版本,它们会根据上述默认行为对自身及其他组成员采取行动。例如,一个不支持 group_replication_member_expel_timeout 系统变量的成员,在检测到可疑状态过期时会立即驱逐其他成员,即使其他成员支持该系统变量并设置了更长的超时时间,也会接受这种驱逐。Note that where group members are at an older MySQL Server release
that does not support a relevant setting, or at a release with a
different default, they act towards themselves and other group
members according to the default behaviors stated above. For
example, a member that does not support the
group_replication_member_expel_timeout
system variable expels other members as soon as an expired
suspicion is detected, and this expulsion is accepted by other
members even if they support the system variable and have a longer
timeout set.