对故障检测和网络分区的响应

组复制的故障检测机制旨在识别不再与组通信的组成员，并在它们似乎有故障时将其驱逐出去。具有故障检测机制会增加该组包含大多数正常工作的成员的机会，因此会正确处理来自客户端的请求。

通常，所有小组成员都定期与所有其他小组成员交换消息。如果组成员在5秒钟内未收到来自特定伙伴的任何消息，则在此检测时间段结束时，它会怀疑该成员。如果怀疑超时，则认为可疑成员已失败，并被从该小组开除。被驱逐的成员将从其他成员看到的成员资格列表中删除，但是它不知道自己已被从该组驱逐出，因此它将自己视为在线且其他成员无法访问。如果该成员实际上并没有发生故障（例如，由于暂时的网络问题而刚刚断开连接），并且能够恢复与其他成员的通信，

可以在过程中的许多点上配置组成员（包括失败的成员本身）对这些情况的响应。默认情况下，如果怀疑成员失败，则会发生以下行为：

1. 创建可疑对象后，它会立即超时（其生存期设置为0），因此，一旦发现过期的可疑对象，就会将其驱逐出境。该成员可能会在超时后再存活几秒钟，因为定期检查是否有过期的嫌疑。
2. 如果被驱逐的成员恢复通信并意识到自己被驱逐了，则它不会尝试重新加入该团体并接受其驱逐。
3. 当被驱逐成员接受驱逐时，它将切换为超级只读模式并等待操作员注意。（从MySQL 8.0.12到8.0.15的发行版中是例外，其中默认是成员自行关闭。从MySQL 8.0.16起，行为已更改为与MySQL 5.7中的行为匹配。）

设置这些默认值是为了优先考虑组的正确操作和对请求的正确处理。但是，在速度较慢的网络或瞬态故障率较高的网络中，它们可能会带来不便，因为在这些情况下，操作员可能需要经常干预以固定被驱逐的成员。它们还不允许在预期的网络故障或计算机速度变慢的情况下计划继续操作该组。您可以使用本节中描述的“组复制”配置选项来永久或临时更改这些行为，以适合您的系统要求和优先级。

尚未失败的成员可能会由于网络分区而失去与部分（而非全部）复制组的联系。例如，在一组5个服务器（S1，S2，S3，S4，S5）中，如果（S1，S2）与（S3，S4，S5）之间存在断开连接，则存在网络分区。第一组（S1，S2）现在占少数，因为它不能联系超过一半的组。由于少数群体中的大多数成员无法访问，因此少数群体成员中处理的所有交易均被阻止，因此该群体无法达到法定人数。有关此方案的详细说明，请参见“网络分区”。在这种情况下，默认行为是少数群体和多数群体中的成员都保留在组中，继续接受交易（尽管他们被少数群体中的成员阻止），并等待操作员干预。此行为也是可配置的。

请注意，如果组成员位于不支持相关设置的较早版本的MySQL Server上，或者具有不同的默认版本，则它们会根据上述默认行为对自己和其他组成员起作用。例如，一个不支持group_replication_member_expel_timeout系统变量的成员在检测到过期的怀疑后就将其驱逐，并且即使其他成员支持系统变量并且设置了更长的超时，此驱逐也将被其他成员接受。

退出超时

您可以使用group_replication_member_expel_timeout MySQL 8.0.13中提供的系统变量，在创建怀疑与驱逐可疑成员之间留出更多时间。

当另一个成员对它的怀疑（或对自身的怀疑）超时时，该成员将被开除。默认情况下，group_replication_member_expel_timeout将其设置为0，这意味着没有等待时间，并且在5秒钟的检测时间结束后，可疑成员应立即被驱逐出境。在驱逐机制检测并实施驱逐之前，可能还需要短时间。如果组成员是不支持此设置的旧版本的MySQL Server，则这是其对其他成员或其本身的行为。

为避免在速度较慢的网络上不必要的驱逐，或在预期的瞬态网络故障或计算机速度减慢的情况下，可以将超时值指定为大于零，最长不超过3600秒（1小时）。处于此状态的可疑成员被列为UNREACHABLE，但未从组的成员资格列表中删除。如果可疑成员在怀疑超时之前再次变为活动状态，它将重新加入该组，应用其余组成员缓冲的所有消息，然后进入ONLINE状态。

如果超过了超时时间，可疑成员将在怀疑超时后立即被驱逐出境。如果成员能够恢复通信并收到将其驱逐的视图，则表示该成员已被驱逐。默认情况下，被驱逐成员将遵循由指定的退出动作group_replication_exit_state_action。或者，您可以使用group_replication_autorejoin_tries MySQL 8.0.16中提供的系统变量，使成员自动尝试重新加入该组。

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

如果当前怀疑某个组中的任何成员，则无法重新配置该组成员身份（通过添加或删除成员或选举新的领导者）。如果需要在一个或多个成员受到怀疑的情况下执行组成员身份更改，并且您希望可疑成员保留在组中，请尽可能执行使该成员再次活动的所有必要操作。如果您无法使成员再次活跃并且希望将他们从小组中驱逐出局，则可以强制怀疑立即超时。通过更改的值来执行此操作group_replication_member_expel_timeout任何活动成员的值都应小于产生怀疑以来已过去的时间。然后，可疑成员立即被驱逐出境。

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

有关在group_replication_member_expel_timeout系统变量不可用的情况下避免不必要的驱逐的替代缓解策略，请参见“组复制限制”。

多数用户超时

默认情况下，由于网络分区而处于少数群体的成员不会自动离开组。您可以使用系统变量group_replication_unreachable_majority_timeout来设置成员与大多数组成员失去联系后等待，然后退出该组的秒数。设置超时意味着您无需主动监视网络分区之后位于少数组中的服务器，并且可以避免由于以下原因而导致出现裂脑情况（具有两个版本的组成员身份）的可能性不适当的干预。

group_replication_unreachable_majority_timeout经过指定的超时后，该成员和少数组中的其他成员已处理的所有未决事务将回滚，并且该组中的服务器将移至该ERROR状态。默认情况下，少数成员将遵循由指定的退出动作group_replication_exit_state_action。或者，您可以使用group_replication_autorejoin_tries MySQL 8.0.16中提供的系统变量，使成员自动尝试重新加入该组。

在决定是否设置不可逾越的多数超时时，请考虑以下几点：

• 在一个对称组中，例如一个有两个或四个服务器的组，如果两个分区都包含相同数量的服务器，则两个组都将自己视为少数并进入ERROR状态。在这种情况下，该组没有功能分区。
• 存在少数群体时，少数群体处理的任何事务都会被接受，但会被阻止，因为少数群体服务器无法达到法定人数，除非STOP GROUP_REPLICATION在这些服务器上发出任何仲裁或达到不可逾越的多数群体超时。
• 如果您没有设置无法到达的多数超时，则少数组中的服务器将永远不会ERROR自动进入状态，您必须手动停止它们。
• 如果在检测到失去多数之后在少数组中的服务器上设置了无法到达的多数超时，则该设置无效。

如果您不使用group_replication_unreachable_majority_timeout系统变量，则在“网络分区”中描述了在进行网络分区时操作员发明的过程。该过程涉及检查哪些服务器正在运行，并在必要时强制使用新的组成员身份。

自动重新加入

该group_replication_autorejoin_tries系统变量，它可从MySQL 8.0.16，使得已被驱逐或已达可达广大超时尝试自动重新加入该组的成员。您可以指定成员重新加入组的尝试次数，而不仅仅是在恢复通讯后立即接受其驱逐。如果您可以忍受过时的读取并希望最大程度地减少手动干预的可能性，请激活自动重新加入，尤其是在瞬态网络问题经常导致成员被驱逐的情况下。

当成员被驱逐或多数成员无法达到超时时，它将尝试重新加入（使用当前插件选项值），然后继续进行进一步的自动重新加入尝试，直至达到指定的尝试次数。自动重新加入尝试失败后，成员将在下一次尝试之前等待5分钟。如果指定的尝试次数已用尽，而该成员没有重新加入或停止，则该成员将继续执行group_replication_exit_state_action系统变量指定的操作。

在自动重新加入过程中，被驱逐成员保持超级只读模式，并ERROR在其复制组视图上显示状态。请记住，虽然成员仍处于超级只读模式，但是尽管无法在该成员上进行写操作，但随着时间的流逝，陈旧读取的可能性会越来越高。如果确实要干预使成员脱机，则可以随时使用STOP GROUP_REPLICATION语句或关闭服务器来手动停止成员。

您可以使用性能模式监视自动重新加入过程。在执行自动重新加入过程时，“性能模式”表将events_stages_current显示“正在进行自动重新加入过程”事件，以及迄今为止在该过程实例中（WORK_COMPLETED字段中）尝试进行的重试次数。该events_stages_summary_global_by_event_name表显示了服务器实例启动自动重新加入过程的次数（在该COUNT_STAR字段中）。该events_stages_history_long表显示了每个自动重新加入过程的完成时间（在TIMER_END现场）。

退出动作

该group_replication_exit_state_action系统变量，它可从MySQL 8.0.12和MySQL 24年7月5日，指定了集团复制确实当成员离开该集团无意由于错误或问题，并要么无法自动归队或不尝试。请注意，在被驱逐成员的情况下，该成员直到重新连接到该群组才知道自己被驱逐了，因此仅当该成员设法重新连接或该成员对自己和自己提出怀疑时，才采取指定的操作。开除自己。

按照影响顺序，退出操作如下：

1. 如果READ_ONLY是退出动作实例MySQL的切换通过设置系统变量超只读模式super_read_only来ON。当成员处于超级只读模式时，即使客户端具有SUPER特权，客户端也无法进行任何更新。但是，客户端仍然可以读取数据，并且由于不再进行更新，因此，陈旧读取的可能性会随着时间的推移而增加。因此，使用此设置，您需要主动监视服务器的故障。这是MySQL 8.0.15的默认退出操作。执行此退出操作后，成员的状态显示为ERROR在小组看来。
2. 如果OFFLINE_MODE是退出动作实例通过设置系统变量切换MySQL来离线模式offline_mode来ON。当成员处于脱机模式时，已连接的客户端用户将在其下一个请求时断开连接，并且除具有CONNECTION_ADMIN或SUPER特权的客户端用户外，不再接受连接。组复制还将系统变量设置super_read_only为ON，因此，即使客户端已与客户端连接，也无法进行任何更新。SUPER特权。此退出操作可防止更新和过时的读取（具有指定权限的客户端用户的读取除外），并使代理工具（如MySQL Router）能够识别服务器不可用并重定向客户端连接。它还使实例保持运行状态，以便管理员可以尝试解决问题而不关闭MySQL。MySQL 8.0.18提供了此退出操作。采取此退出操作后，该成员的状态显示为ERROR在该组的视图中（不是OFFLINE，这表示该成员具有“组复制”功能可用，但当前不属于某个组）。
3. 如果ABORT_SERVER是exit动作，则实例关闭MySQL。指示成员关闭自身可以防止所有陈旧的读取和客户端更新，但这意味着MySQL Server实例不可用，必须重新启动，即使不采取此步骤也可以解决问题。当将系统变量添加到MySQL 8.0.15（含）时，此退出操作是MySQL 8.0.12的默认操作。采取此退出操作后，该成员将从组视图中的服务器列表中删除。

请记住，无论设置了哪种退出操作，都需要操作员干预，因为已经用尽了自动重新尝试（或从未尝试过）并且已从组中驱逐的前成员，如果不重新启动组，则不允许重新加入。复制。退出操作仅影响客户端是否仍然可以读取无法重新加入组的服务器上的数据，以及服务器是否保持运行状态。

重要

如果在成员成功加入组之前发生故障，则不会执行所指定的退出操作。如果在本地配置检查期间失败，或者加入成员的配置与组的配置不匹配，就是这种情况。在这些情况下，系统变量将保留其原始值，并且服务器不会关闭MySQL。为确保当组复制未启动时服务器无法接受更新，因此我们建议在启动时在服务器的配置文件中进行设置，该组复制将更改为group_replication_exit_state_actionsuper_read_onlysuper_read_only=ONOFF成功启动后在主要成员上运行。当服务器配置为在服务器引导（group_replication_start_on_boot=ON）上启动组复制时，此保护措施尤其重要，但是在使用START GROUP_REPLICATION命令手动启动组复制时，此保护措施也很有用。

如果成员成功加入组后失败，则将执行指定的退出操作。在以下情况下就是这种情况：

1. 应用程序错误-复制应用程序中存在错误。此问题不可恢复。
2. 无法进行分布式恢复-存在一个问题，这意味着无法完成组复制的分布式恢复过程（该过程使用远程克隆操作和从二进制日志的状态转移）。组复制会在这种情况下自动重试分布式恢复，但如果没有其他选择可完成该过程，则复制将停止。有关详细信息，请参见“分布式恢复的容错”。
3. 组配置更改错误-如“配置在线组”所述，在使用UDF进行组范围的配置更改期间发生错误。
4. 主要选举错误-如“单主要模式”中所述，在单主要模式下为组选举新的主要成员时发生错误。
5. 不可达的多数超时-成员与多数组成员失去联系，少数成员失去联系，并且由group_replication_unreachable_majority_timeout系统变量设置的超时已到期。
6. 从组中驱逐成员-对该成员提出了怀疑，并且group_replication_member_expel_timeout系统变量设置的任何超时都已到期，并且该成员已恢复与该组的通信并发现它已被驱逐。
7. 超出自动重试次数- group_replication_autorejoin_tries失去多数或驱逐后，系统变量设置为指定自动重试次数，并且成员完成了此尝试次数，但未成功。

下表总结了每种情况下的故障情况和措施：

组复制失败情况下的退出操作