#### 18.7.7.1 驱逐超时

您可以使用[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)系统变量，可从 MySQL 8.0.13 获得，以允许在创建怀疑和驱逐嫌疑成员之间有额外的时间。当一台服务器没有收到来自另一台服务器的消息时，就会产生怀疑，如中所述[第 18.1.4.2 节，“故障检测”](group-replication-failure-detection.html).

在组复制组成员怀疑另一个成员（或自身）之前，有一个初始的 5 秒检测期。当另一个成员对它的怀疑（或它自己对自己的怀疑）超时时，一个组成员就会被开除。在此之后，在驱逐机制检测并执行驱逐之前，可能会经过更短的一段时间。[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)指定组成员在创建怀疑和驱逐可疑成员之间等待的时间段（以秒为单位），称为驱逐超时。疑似成员被列为`无法到达`在此等待期间，但不会从组的成员列表中删除。

-   如果可疑成员在等待期结束时怀疑超时之前再次变为活动状态，则该成员将应用由 XCom 消息缓存中剩余组成员缓冲的所有消息并进入`在线的`状态，无需操作员干预。在这种情况下，该成员被该组视为相同的化身。

-   如果可疑成员仅在怀疑超时并能够恢复通信后才变为活动状态，则它会收到一个被驱逐的视图，并且此时意识到它已被驱逐。您可以使用[`group_replication_autorejoin_tries`](group-replication-options.html#sysvar_group_replication_autorejoin_tries)系统变量，可从 MySQL 8.0.16 获得，以使成员此时自动尝试重新加入组。从 MySQL 8.0.21 开始，默认情况下会激活此功能，并且成员会尝试 3 次自动重新加入。如果自动重新加入过程不成功或未尝试，则被驱逐的成员将遵循指定的退出操作[`group_replication_exit_state_action`](group-replication-options.html#sysvar_group_replication_exit_state_action).

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

    如果[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)设置为0，没有等待期，5秒检测期结束后，疑似成员将立即被开除。此设置是 MySQL 8.0.20 之前的默认设置，包括 MySQL 8.0.20。这也是不支持 MySQL 服务器版本的组成员的行为[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)系统变量。从 MySQL 8.0.21 开始，该值默认为 5，这意味着可疑成员在 5 秒检测期后 5 秒有责任驱逐。一个组的所有成员都必须具有相同的设置[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout), 但建议这样做是为了避免意外驱逐。任何成员都可以对任何其他成员产生怀疑，包括自己，因此有效的驱逐超时是具有最低设置的成员的超时。

    考虑增加[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)在以下情况下从默认设置：

-   网络很慢，并且默认的 5 或 10 秒前驱逐时间不足以让组成员始终交换至少一条消息。

-   网络有时会出现短暂的中断，您希望在这些时候避免不必要的驱逐和主要成员更改。

-   网络不受您的直接控制，您希望尽量减少操作员干预的需要。

-   预计会出现临时网络中断，您不希望部分或全部成员因此而被驱逐。

-   单个机器正在减速，您不希望它被从组中驱逐。

    您可以指定最长为 3600 秒（1 小时）的驱逐超时。重要的是要确保 XCom 的消息缓存足够大以包含您指定时间段内的预期消息量，加上最初的 5 秒检测周期，否则成员无法重新连接。您可以使用[`group_replication_message_cache_size`](group-replication-options.html#sysvar_group_replication_message_cache_size)系统变量。有关详细信息，请参阅[第 18.7.6 节，“XCom 缓存管理”](group-replication-performance-xcom-cache.html).

    如果组中的任何成员当前受到怀疑，则无法重新配置组成员身份（通过添加或删除成员或选举新的领导者）。如果在一名或多名成员受到怀疑时需要实施群组成员资格更改，并且您希望可疑成员留在群组中，请采取任何必要的措施使成员再次处于活动状态（如果可能）。如果您无法使成员再次活跃并且您希望他们被驱逐出组，您可以立即强制怀疑超时。通过改变值来做到这一点[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)对任何活跃成员的值低于自怀疑产生以来已经过去的时间。然后，嫌疑成员将立即被开除。

    如果复制组成员意外停止并立即重新启动（例如，因为它以`mysqld_safe`)，它会自动尝试重新加入组，如果[`group_replication_start_on_boot=on`](group-replication-options.html#sysvar_group_replication_start_on_boot)已设置。在这种情况下，重新启动和重新加入的尝试可能发生在成员的前一个化身被逐出组之前，在这种情况下，成员无法重新加入。从 MySQL 8.0.19 开始，Group Replication 自动使用 Group Communication System (GCS) 功能为成员重试重新加入尝试 10 次，每次重试之间的间隔为 5 秒。这应该涵盖大多数情况，并留出足够的时间将前一个转世从组中驱逐出去，让成员重新加入。请注意，如果[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)系统变量设置为在成员被驱逐之前指定更长的等待时间，自动重新加入尝试可能仍然不会成功。

    对于替代缓解策略，以避免不必要的驱逐，其中[`group_replication_member_expel_timeout`](group-replication-options.html#sysvar_group_replication_member_expel_timeout)系统变量不可用，请参阅[第 18.3.2 节，“组复制限制”](group-replication-limitations.html).
