组复制的失败检测机制旨在识别不再与组通信的组成员，并将其驱逐出去，以确保组中有多数正确工作的成员，从而正确地处理客户端的请求。

通常，所有组成员都定期与其他组成员交换消息。如果某个组成员在5秒内没有从其他组成员那里收到任何消息，那么它将怀疑该成员失败。当怀疑超时时，怀疑的成员将被视为失败，并被驱逐出组。被驱逐的成员将从其他成员的成员列表中删除，但它不知道自己被驱逐了，所以它认为自己在线，而其他成员不可达。如果该成员实际上没有失败（例如，因为临时网络问题），并且它能够恢复与其他成员的通信，那么它将收到包含其被驱逐信息的视图。

组成员，包括失败的成员本身，对这些情况的响应可以在过程中的多个点进行配置。默认情况下，如果某个成员被怀疑失败：

您可以使用本节中描述的组复制配置选项永久或临时地更改这些行为，以适应系统的需求和优先级。如果您经常遇到不必要的驱逐情况，例如由于网络或机器慢速、网络中断或计划的网络中断，可以考虑增加驱逐超时和自动重新加入尝试次数。虽然成员正在经历这些默认行为，但它仍然可以与客户端通信，读取操作仍然可以执行，但随着时间的推移，读取操作的可能性会增加。如果避免陈旧读取是您的更高优先级，可以考虑减少驱逐超时和自动重新加入尝试次数，或者将其设置为零。

组成员可能会由于网络分区而失去与部分组成员的联系。例如，在 5 服务器（S1、S2、S3、S4、S5）的组中，如果 S1 和 S2 之间断开连接，而 S3、S4 和 S5 之间断开连接，那么就会出现网络分区。第一个组（S1、S2）现在是少数，因为它无法与组的多数成员联系。任何由少数成员处理的交易都将被阻止，因为组无法达到多数。有关此场景的详细描述，请参阅 第 20.7.8 节，“处理网络分区和多数失去”。在这种情况下，默认行为是让少数和多数组成员都留在组中，继续接受交易（尽管它们被阻止在少数成员上），并等待操作员的干预。这个行为也是可配置的。

注意，在较旧的 MySQL Server 版本中，组成员可能不支持相关设置，或者在具有不同默认值的版本中，他们将根据上述默认行为对自己和其他组成员采取行动。例如，不支持 group_replication_member_expel_timeout 系统变量的成员将在检测到过期的怀疑时立即驱逐其他成员，而这将被其他成员接受，即使他们支持该系统变量并设置了更长的超时。