组复制的故障检测机制旨在识别不再与组通信的组成员,并在看似可能发生故障时将其驱逐。拥有故障检测机制可以增加组中包含大多数正常工作成员的可能性,从而确保正确处理来自客户端的请求。
通常,所有组成员都会定期与所有其他组成员交换消息。如果某个组成员在 5 秒内没有收到来自某个成员的任何消息,则在此检测期结束时,它会对该成员产生怀疑。当怀疑超时时,系统会假定可疑成员已发生故障,并将其从组中驱逐。被驱逐的成员将从其他成员看到的成员资格列表中删除,但它不知道自己已被驱逐出组,因此它会将自己视为在线,而将其他成员视为不可访问。如果该成员实际上并未发生故障(例如,由于暂时性网络问题而断开连接),并且它能够恢复与其他成员的通信,则它会收到一个视图,其中包含它已被驱逐出组的信息。
组成员(包括故障成员本身)对这些情况的响应可以在流程中的多个点进行配置。默认情况下,如果怀疑成员已发生故障,则会发生以下行为
在 MySQL 8.4 中,当产生怀疑时,会在怀疑超时和可疑成员可能被驱逐之前添加 5 秒的等待时间。
如果被驱逐的成员恢复通信并意识到自己被驱逐,它会自动尝试重新加入该组三次(每次尝试之间间隔 5 分钟);如果此自动重新加入过程不起作用,则它会停止尝试重新加入该组。
当被驱逐的成员没有尝试重新加入该组时,它会切换到超级只读模式并等待操作员注意。
您可以使用本节中描述的组复制配置选项来永久或临时更改这些行为,以满足系统的要求和优先级。如果您遇到由较慢的网络或机器、具有高频率意外瞬时中断的网络或计划内的网络中断导致的不必要的驱逐,请考虑增加驱逐超时和自动重新加入尝试次数。虽然成员正在经历前面描述的任何默认行为,但如果该成员仍在与客户端通信,则仍然可以执行读取操作,但随着时间的推移,过时读取的可能性会越来越大。如果避免过时读取的优先级高于避免操作员干预,请考虑减少驱逐超时和自动重新加入尝试次数,或将其设置为零。
未发生故障的成员可能会因网络分区而与部分(但并非所有)复制组失去联系。例如,在一个由 5 台服务器 (S1、S2、S3、S4、S5) 组成的组中,如果 (S1、S2) 和 (S3、S4、S5) 之间断开连接,则会发生网络分区。第一个组 (S1、S2) 现在处于少数,因为它无法联系到组中超过一半的成员。由少数组中的成员处理的任何事务都将被阻塞,因为无法访问组中的大多数成员,因此该组无法实现仲裁。有关此方案的详细说明,请参阅第 20.7.8 节“处理网络分区和仲裁丢失”。在这种情况下,默认行为是少数和多数中的成员都保留在组中,继续接受事务(尽管它们在少数成员上被阻塞),并等待操作员干预。此行为也是可配置的。
请注意,如果组成员使用的是不支持相关设置的较旧 MySQL Server 版本,或者使用的是默认设置不同的版本,则它们会根据上述默认行为对自己和其他组成员执行操作。例如,不支持 group_replication_member_expel_timeout
系统变量的成员会在检测到过期的怀疑后立即驱逐其他成员,即使其他成员支持该系统变量并设置了更长的超时,也会接受此驱逐。