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