组复制的故障检测机制是一种分布式服务，它能够识别组中的服务器不与其他服务器通信，从而怀疑该服务器已停止服务。如果该团体一致认为怀疑可能属实，则该团体会做出协调一致的决定，驱逐该成员。驱逐不进行沟通的成员是必要的，因为该团体需要大多数成员就交易或观点变更达成一致。如果某个成员不参与这些决策，则该组必须将其删除，以增加该组包含大多数正常工作成员的机会，从而可以继续处理交易。
在复制组中，每个成员都具有与其他成员之间的点对点通信通道，从而创建完全连接的图。这些连接由组通信引擎（XCom，Paxos 变体）管理并使用 TCP/IP 套接字。一个通道用于向成员发送消息，另一个通道用于接收来自成员的消息。如果一个成员在 5 秒内没有收到来自另一个成员的消息，则怀疑该成员已失败，并在UNREACHABLE其自己的性能模式表中 列出该成员的状态replication_group_members。通常，两个成员会互相怀疑对方失败了，因为他们都没有与对方沟通。尽管不太可能，成员 A 怀疑成员 B 发生了故障，但成员 B 并不怀疑成员 A 发生了故障 - 可能是由于路由或防火墙问题。成员也可能会对自己产生怀疑。与小组其他成员隔离的成员怀疑其他所有成员都失败了。
如果怀疑持续超过 10 秒，怀疑成员会尝试将其认为可疑成员有问题的观点传播给组中的其他成员。仅当可疑成员是通知者（根据其内部 XCom 节点编号计算）时，才会执行此操作。如果一个成员实际上与小组的其他成员隔离，它可能会尝试传播自己的观点，但这不会产生任何后果，因为它无法确保其他成员的法定人数达成一致。只有当成员是通知者并且其怀疑持续足够长的时间以传播到组中的其他成员并且其他成员都同意时，怀疑才会产生后果。此时，协调决策将可疑成员标记为从群组中开除，并在系统 group_replication_member_expel_timeout 变量设置的等待时间到期且开除机制检测到并执行开除后将其开除。
当网络不稳定且成员之间经常以不同的组合失去和恢复连接时，理论上一个群组有可能最终将其所有成员标记为驱逐，之后该群组将不复存在并必须重新建立再次。为了应对这种可能性，从 MySQL 8.0.20 开始，组复制的组通信系统 (GCS) 会跟踪已标记为驱逐的组成员，并在决定是否有多数成员时将它们视为可疑成员组中的成员。这可确保至少有一名成员保留在组中，并且组可以继续存在。当被驱逐的成员实际上被从群组中删除时，GCS 会删除其将该成员标记为驱逐的记录，以便该成员可以在可以的情况下重新加入群组。
有关组复制系统变量的信息，您可以配置这些变量来指定工作组成员对故障情况的响应，以及怀疑失败的组成员所采取的操作，请参阅第 20.7.7 节 “对故障检测和故障的响应”。网络分区”。
