组复制的故障检测机制是一个分布式服务，可以识别组中的服务器不再与其他服务器通信，从而怀疑该服务器已停止服务。如果组的共识认为怀疑是正确的，组将采取协调的决定来驱逐该成员。驱逐不再通信的成员是必要的，因为组需要大多数成员同意事务或视图更改。如果成员不参与这些决定，组必须将其删除，以增加正确工作的成员的可能性，从而继续处理事务。

在复制组中，每个成员都有一个点对点通信通道与其他成员，创建了一个完全连接的图形。这些连接由组通信引擎（XCom，Paxos 变体）管理，并使用 TCP/IP 套接字。一个通道用于向成员发送消息，另一个通道用于从成员接收消息。如果成员没有从另一个成员那里接收到消息 5 秒钟，它怀疑该成员已经失败，并在自己的性能模式表 replication_group_members 中将该成员的状态列为 UNREACHABLE。通常，两个成员将互相怀疑对方已经失败，因为它们各自没有从对方那里接收到消息。也可能，成员 A怀疑成员 B 已经失败，但成员 B 并不怀疑成员 A 已经失败 - 也许是由于路由或防火墙问题。成员也可以怀疑自己。如果成员与组的其他成员隔离，它怀疑所有其他成员已经失败。

如果怀疑持续超过 10 秒钟，怀疑的成员将尝试将其视图传播给组的其他成员，以便怀疑的成员是 notifier，根据其内部 XCom 节点号计算。如果成员实际上与组的其他成员隔离，它可能会尝试传播其视图，但这将没有任何后果，因为它无法获得其他成员的同意。怀疑只有在成员是 notifier，并且怀疑持续足够长时间以便传播给组的其他成员，并且其他成员同意时，才会产生后果。在这种情况下，怀疑的成员将被标记为驱逐出组，并在等待期结束后被驱逐，等待期由 group_replication_member_expel_timeout 系统变量设置。

在网络不稳定且成员频繁地失去和重新连接到其他成员的不同组合的情况下，理论上可能会出现组将所有成员标记为驱逐的情况，继而组将停止存在并需要重新设置。为对抗这种可能性，从 MySQL 8.0.20 开始，Group Replication 的组通信系统（GCS）跟踪已被标记为驱逐的组成员，并将其视为怀疑的成员组，以便决定是否存在多数。这样可以确保至少一个成员留在组中，组可以继续存在。当被驱逐的成员实际上被从组中删除时，GCS 将删除其记录，以便成员可以重新加入组。

有关 Group Replication 系统变量的信息，可以配置以指定工作组成员对故障情况的响应，以及怀疑的成员采取的行动，请参阅 第 20.7.7 节，“响应故障检测和网络分区”。