组复制的故障检测机制是一种分布式服务，能够识别组中某个服务器没有与其他服务器通信，因此被怀疑已停止服务。如果组的共识是怀疑可能属实，则该组会做出协调一致的决定，将该成员驱逐出去。驱逐一个没有通信的成员是必要的，因为该组需要其大多数成员同意一项事务或视图更改。如果一个成员没有参与这些决定，该组必须将其移除，以增加该组包含大多数正常运行的成员的可能性，因此可以继续处理事务。

在复制组中，每个成员都与其他每个成员之间具有点对点通信通道，形成一个完全连接的图。这些连接由组通信引擎（XCom，一种 Paxos 变体）管理，并使用 TCP/IP 套接字。一个通道用于向成员发送消息，另一个通道用于接收来自成员的消息。如果一个成员在 5 秒内没有收到来自另一个成员的消息，它会怀疑该成员已发生故障，并在其自己的性能架构表 replication_group_members 中将该成员的状态列为 UNREACHABLE。通常，两个成员会互相怀疑对方已发生故障，因为它们彼此之间没有通信。虽然不太可能，但也有可能成员 A 怀疑成员 B 已发生故障，而成员 B 却没有怀疑成员 A 已发生故障 - 可能是由于路由或防火墙问题。成员也可以怀疑自己。与组的其余部分隔离的成员会怀疑所有其他成员都已发生故障。

如果怀疑持续超过 10 秒，怀疑成员会尝试将它认为怀疑成员有故障的观点传播给组中的其他成员。怀疑成员只有在其是通知者时才会这样做，通知者是从其内部 XCom 节点编号计算出来的。如果成员实际上与组的其余部分隔离，它可能会尝试传播它的观点，但那将没有任何后果，因为它无法获得其他成员的多数票来同意它。只有在成员是通知者，并且它的怀疑持续时间足够长以传播到组中的其他成员，并且其他成员同意它的情况下，怀疑才会产生后果。在这种情况下，怀疑成员将在协调一致的决定中被标记为将从组中驱逐出去，并且在由 group_replication_member_expel_timeout 系统变量设置的等待时间到期并且驱逐机制检测到并执行驱逐后，它将被驱逐出去。

如果网络不稳定，成员经常在不同组合中失去与彼此的连接，并重新获得连接，理论上该组最终可能会将所有成员都标记为要驱逐出去，然后该组将不复存在，必须重新设置。为了解决这种情况，组复制组通信系统 (GCS) 会跟踪被标记为要驱逐出去的组成员，并在决定是否有多数票时将它们视为怀疑成员组的一部分。这确保至少有一个成员留在组中，并且该组可以继续存在。当被驱逐出去的成员实际上已从组中删除后，GCS 会删除其已将该成员标记为要驱逐出去的记录，以便该成员能够重新加入该组（如果它能够）。

有关您可以配置以指定正常运行的组成员对故障情况的响应以及被怀疑已发生故障的组成员所采取的操作的组复制系统变量的信息，请参见 第 20.7.7 节，“对故障检测和网络分区的响应”.