在这个由三部分组成的博客系列中，我们在第一部分中介绍了MySQL托管的高可用性（HA）框架，并在第二部分中讨论了MySQL半同步复制的细节。现在在第三部分中，我们将回顾框架如何处理一些重要的MySQL故障情况并进行恢复以确保高可用性。
MySQL失败场景
场景1 - Master MySQL关闭
- Corosync和Pacemaker框架检测到主MySQL不再可用。如果可能的话，Pacemaker会降级主资源并尝试通过重新启动MySQL服务来恢复。
- 此时，由于复制的半同步性质，至少一个从设备已接收在主设备上提交的所有事务。
- 起搏器等待，直到所有收到的交易都应用于奴隶并让奴隶报告他们的促销分数。分数计算以如下方式进行：如果从属设备与主设备完全同步则得分为“0”，否则为负数。
- Pacemaker选择已报告0分的奴隶，并提升该奴隶，该奴隶现在担任允许写入的主MySQL角色。
- 从属升级后，资源代理会触发DNS重新路由模块。模块使用新主服务器的IP地址更新代理DNS条目，从而促进所有应用程序写入重定向到新主服务器。
- Pacemaker还设置可用的从站以开始从这个新主站复制。
因此，每当主MySQL出现故障时（无论是由于MySQL崩溃，操作系统崩溃，系统重启等），我们的HA框架都会检测到它并促使合适的从服务器接管主服务器的角色。这可确保系统继续可供应用程序使用。
场景2 - Slave MySQL关闭
- Corosync和Pacemaker框架检测到从属MySQL不再可用。
- Pacemaker尝试通过尝试在节点上重新启动MySQL来恢复资源。如果它出现，它将作为从属添加回当前主服务器并继续复制。
- 如果恢复失败，Pacemaker会将资源报告为已关闭 - 基于可生成的警报或通知。如有必要，ScaleGrid支持团队将处理此节点的恢复。
在这种情况下，对MySQL服务的可用性没有影响。
场景3 - 网络分区 - 网络连接在主节点和从节点之间分解
这是任何分布式系统中的经典问题，其中每个节点认为其他节点已关闭，而实际上，仅断开节点之间的网络通信。这种情况通常被称为裂脑情景，如果处理不当，可能会导致多个节点声称自己是主MySQL，从而导致数据不一致和损坏。
让我们用一个例子来回顾一下我们的框架如何处理集群中的裂脑情景。我们假设由于网络问题，集群已分为两组 - 一组中的主机和另一组中的两个机箱，我们将其表示为[（M），（S1，S2）]。
- Corosync检测到主节点无法与从节点通信，并且从节点可以相互通信，但不能与主节点通信。
- 主节点将无法提交任何事务，因为半主机可以提交之前，半同步复制需要来自至少一个从服务器的确认。与此同时，由于缺乏基于Pacemaker设置'no-quorum-policy = stop'的法定人数，Pacemaker在主节点上关闭了MySQL。仲裁在这里意味着大多数节点，或3节点集群设置中的两个节点。由于在此群集的分区中只运行一个主节点，因此会触发no-quorum-policy设置，从而导致MySQL主服务器关闭。
- 现在，分区上的Pacemaker [（S1），（S2）]检测到群集中没有可用的主服务器并启动促销过程。假设S1与主服务器是最新的（由半同步复制保证），则它将被提升为新主服务器。
- 应用程序流量将重定向到此新的主MySQL节点，从属S2将开始从新主节点复制。
因此，我们看到MySQL HA框架有效地处理裂脑情况，确保在主节点和从节点之间网络连接中断时数据的一致性和可用性。
以上是关于使用半同步复制和 Corosync 加 Pacemaker堆栈的MySQL高可用性（HA）框架的3部分博客系列。在ScaleGrid，我们在AWS上为MySQL提供高度可用的托管，在Azure上提供MySQL，这是基于本博客系列中介绍的概念实现的。请访问ScaleGrid控制台，免费试用我们的解决方案。
原文：https://scalegrid.io/blog/mysql-high-availability-framework-explained-part-3/
本文：http://pub.intelligentx.net/mysql-high-availability-framework-explained-part-iii-failure-scenarios
讨论：请加入知识星球或者小红圈【首席架构师圈】