Group Replication 的故障检测机制是一种分布式服务，能够识别组中的服务器没有与其他服务器通信，因此怀疑服务中断。如果该小组的共识是怀疑可能是真的，则该小组将协调一致地决定开除该成员。驱逐不沟通的成员是必要的，因为该组需要其大多数成员就交易或观点变化达成一致。如果某个成员不参与这些决策，则该组必须将其移除，以增加该组包含大多数正确工作成员的机会，因此可以继续处理交易。

在复制组中，每个成员都有一个与其他成员的点对点通信通道，从而创建一个完全连接的图。这些连接由组通信引擎（XCom，一种 Paxos 变体）管理，并使用 TCP/IP 套接字。一个通道用于向成员发送消息，另一个通道用于接收来自成员的消息。如果一个成员在 5 秒内没有收到来自另一个成员的消息，它怀疑该成员已经失败，并UNREACHABLE在其自己的 Performance Schema 表中 列出该成员的状态replication_group_members. 通常，两个成员会互相怀疑对方失败了，因为他们彼此之间没有沟通。有可能，尽管不太可能，成员 A 怀疑成员 B 失败了，但成员 B 不怀疑成员 A 失败了——可能是由于路由或防火墙问题。成员也可能对自己产生怀疑。一个与团队其他成员隔离开来的成员怀疑其他人都失败了。

如果怀疑持续超过 10 秒，则怀疑成员会尝试将其认为可疑成员有问题的观点传播给组中的其他成员。根据其内部 XCom 节点编号计算，怀疑成员只有在通知时才会这样做。如果一个成员实际上与该组的其他成员隔离开来，它可能会尝试传播它的观点，但这不会产生任何后果，因为它无法确保其他成员的法定人数同意它。只有当成员是通知者时，怀疑才会产生后果，并且怀疑持续的时间足以传播到组的其他成员，并且其他成员也同意。在这种情况下， group_replication_member_expel_timeout 系统变量过期，驱逐机制检测到并执行驱逐。

如果网络不稳定，成员经常以不同的组合失去和重新建立彼此的联系，理论上一个群组最终可能会将其所有成员标记为被驱逐，之后该群组将不复存在，必须重新建立再次。为了应对这种可能性，从 MySQL 8.0.20 开始，Group Replication 的 Group Communication System (GCS) 会跟踪已被标记为被驱逐的组成员，并在决定是否存在多数时将他们视为可疑成员组中的成员. 这样可以确保至少有一个成员留在组中，并且组可以继续存在。当一个被开除的成员实际上已经被从组中移除时，

有关组复制系统变量的信息，您可以配置这些变量以指定工作组成员对故障情况的响应，以及怀疑失败的组成员采取的操作，请参阅 第 18.7.7 节，“对故障检测和响应的响应”网络分区”。