您可以使用 group_replication_member_expel_timeout MySQL 8.0.13 中提供的系统变量，在产生怀疑和驱逐可疑成员之间留出额外的时间。如第 18.1.4.2 节“故障检测”中所述，当一个服务器未收到来自另一台服务器的消息时，就会产生怀疑 。

在 Group Replication 组成员对另一个成员（或其自身）产生怀疑之前，有一个初始的 5 秒检测期。当另一个成员对它的怀疑（或它自己对自己的怀疑）超时时，一个组成员就会被开除。在此之后，在驱逐机制检测到并实施驱逐之前，可能还会经过更短的时间段。 group_replication_member_expel_timeout 指定以秒为单位的时间段，称为驱逐超时，组成员在创建怀疑和驱逐可疑成员之间等待。可疑成员被列为UNREACHABLE在此等待期间，但不会从该组的成员列表中删除。

驱逐成员前的等待期仅适用于之前在该组中活跃的成员。从未在组中活跃过的非成员不会获得此等待期，并且会在初始检测期后被删除，因为他们加入的时间太长。

如果 group_replication_member_expel_timeout 设置为0，则没有等待期，可疑会员在5秒检测期结束后立即被驱逐。此设置是 MySQL 8.0.20 及之前的默认设置。这也是不支持 group_replication_member_expel_timeout 系统变量的 MySQL Server 版本的组成员的行为。从 MySQL 8.0.21 开始，该值默认为 5，这意味着在 5 秒检测期后的 5 秒内，可疑成员将被驱逐。组的所有成员都不必具有相同的设置 group_replication_member_expel_timeout, 但建议避免意外开除。任何成员都可以对包括自己在内的任何其他成员产生怀疑，因此有效驱逐超时是设置最低的成员。

group_replication_member_expel_timeout 在以下情况下 考虑增加默认值 ：

您可以指定最长 3600 秒（1 小时）的驱逐超时。请务必确保 XCom 的消息缓存足够大以包含您指定时间段内的预期消息量，加上最初的 5 秒检测期，否则成员无法重新连接。group_replication_message_cache_size 您可以使用系统变量调整缓存大小限制 。有关详细信息，请参阅 第 18.7.6 节，“XCom 缓存管理”。

如果组中的任何成员当前受到怀疑，则无法重新配置组成员身份（通过添加或删除成员或选举新领导者）。如果在一名或多名成员受到怀疑时需要实施组成员更改，并且您希望可疑成员留在组中，请采取任何必要的措施使成员再次活跃（如果可能）。如果你不能让成员重新活跃起来，你想让他们被开除出群，你可以强制怀疑立即超时。通过更改值来做到这一点 group_replication_member_expel_timeout 任何活跃成员的值低于自怀疑产生以来已经过去的时间。然后，可疑成员将立即被开除。

如果复制组成员意外停止并立即重新启动（例如，因为它是用 启动的 mysqld_safe），它会自动尝试重新加入组，如果 group_replication_start_on_boot=on 已设置。在这种情况下，可能会在成员的前任被逐出组之前进行重新启动和重新加入尝试，在这种情况下，成员无法重新加入。从 MySQL 8.0.19 开始，Group Replication 自动使用 Group Communication System (GCS) 功能重试成员的重新加入尝试 10 次，每次重试之间有 5 秒的间隔。这应该涵盖大多数情况，并留出足够的时间让前任从小组中被驱逐，让成员重新加入。请注意，如果 group_replication_member_expel_timeout 系统变量设置为在成员被驱逐之前指定更长的等待时间，则自动重新加入尝试可能仍然不会成功。

有关避免 group_replication_member_expel_timeout 系统变量不可用时不必要的驱逐的替代缓解策略，请参阅 第 18.3.2 节，“组复制限制”。