【MHA】MySQL高可用MHA介绍1-功能,架构,优势,案例

一 MHA 介绍

1 MHA功能

自动化主服务器监控和故障转移

交互式（手动启动的）主故障转移

非交互式主故障转移

在线切换主机

2 主服务器故障转移的难点

二 MHA架构

1 MHA组件

2 自定义扩展（脚本）

三 MHA优势

1 MHA可以非常快速地进行主故障转移和从服务器晋升。

2 主服务器崩溃不会导致数据不一致。

3 无需修改当前的MySQL设置

4 无需增加大量服务器

5 无性能损耗

6 适用于任何存储引擎

四 MHA典型的使用情况

1 MHA Manager的部署位置

2 复制拓扑结构

一主多从

一主多从（其中有个从库Sr在远程的数据中心）

一主多从（其中有个从库S0设置为候选主）

多主多从

三层级联复制

三层级联复制，多主配置

3 管理主机IP地址

4 与半同步复制一起使用

一 MHA 介绍

MHA（Master High Availability）执行自动化的主服务器故障转移和从服务器提升，最小化停机时间，通常在10-30秒内完成。MHA可以防止复制一致性问题，并节省了获取额外服务器的费用。所有这些操作都不会造成性能下降，没有复杂性（易于安装），也不需要对现有部署进行任何更改。

MHA还提供了定期在线主服务器切换功能，安全地将当前运行的主服务器切换到新主服务器，仅需几秒钟的停机时间（仅阻止写入）。

1 MHA功能

MHA提供了以下功能，并且在许多需要高可用性、数据完整性和近乎不间断的主服务器维护的部署中非常有用。

自动化主服务器监控和故障转移

MHA可以监控现有复制环境中的MySQL主服务器，在检测到主服务器故障时执行自动化主服务器故障转移。MHA通过识别来自最新从服务器的差异中继日志事件，并将其应用于所有其他从服务器，包括那些仍未接收到最新中继日志事件的从服务器，从而保证所有从服务器的一致性。MHA通常可以在几秒内执行故障转移：9-12秒用于检测主服务器故障，可选择性地7-10秒用于关闭主服务器以避免分裂脑，然后再花几秒钟将差异中继日志应用于新主服务器。总停机时间通常为10-30秒。可以在配置文件中指定特定的从服务器作为候选主服务器（设置优先级）。由于MHA在从服务器之间保持一致性，因此任何从服务器都可以晋升为新主服务器。通常会导致突然复制失败的一致性问题不会发生。

交互式（手动启动的）主故障转移

MHA可以配置为手动启动的交互式故障转移，而无需监控主服务器。

非交互式主故障转移

还支持无需监控主服务器的非交互式自动主故障转移。当已经使用MySQL主软件监视时，此功能特别有用。例如，您可以使用Pacemaker（心跳）来检测主服务器故障和虚拟IP地址接管，同时使用MHA进行主服务器故障转移和从服务器提升。

在线切换主机

经常需要将现有主机迁移到不同的机器，例如当前主机存在硬件RAID控制器或RAM问题，或者想要用更快的机器替换它时。这不是主服务器崩溃，而是需要计划的主服务器维护。应尽快执行计划的主服务器维护，因为它涉及部分停机（主写入被禁用）。另一方面，您应该非常小心地阻止/终止当前运行的会话，因为不同主服务器之间可能会发生一致性问题（例如，“更新主1，更新主2，提交主1，在提交主2时出现错误”将导致数据不一致）。需要快速的主切换和优雅的阻塞写入。

MHA在0.5-2秒的写入阻塞时间内提供优雅的主切换。通常可以接受0.5-2秒的写入停机时间，因此即使没有分配计划的维护窗口，也可以切换主服务器。诸如升级到更高版本、更快的机器等操作变得更加容易。

2 主服务器故障转移的难点

主服务器故障转移并不像看起来那么简单。以最典型的MySQL部署案例为例，一个主服务器对应多个从服务器。如果主服务器崩溃，您需要选择其中一个最新的从服务器，将其晋升为新主服务器，并让其他从服务器从新主服务器开始复制。这实际上并不简单。即使最新的从服务器可以被识别出来，其他从服务器很可能尚未接收到所有的二进制日志事件。如果这些从服务器在开始复制时连接到新主服务器，它们将丢失事务。这将导致一致性问题。为了避免这些一致性问题，需要先识别并逐个应用尚未到达所有从服务器的丢失的二进制日志事件，然后才能在新（晋升的）主服务器上启动复制。这个操作可能非常复杂且难以手动执行。我在2011年的MySQL会议和博览会上的演示幻灯片中有详细说明（特别是在第10页）。

目前，大多数MySQL复制用户在主服务器崩溃时别无选择，只能手动执行故障转移。完成故障转移通常需要一小时或更长时间的停机时间并不罕见。很可能并非所有从服务器都接收到相同的中继日志事件，导致稍后可能需要纠正的一致性问题。即使主服务器崩溃的情况很少见，但一旦发生，可能会非常痛苦。

MHA旨在尽快完全自动化主服务器故障转移和恢复程序，而无需任何被动（备用）机器。恢复过程包括确定新主服务器，识别从服务器之间的差异中继日志事件，将必要的事件应用于新主服务器，同步其他从服务器，并让它们从新主服务器开始复制。通常情况下，MHA可以在10-30秒的停机时间内执行故障转移（10秒用于检测主服务器故障，可选择性地7-10秒用于关闭主服务器以避免分裂脑，几秒钟或更长时间用于恢复），具体取决于复制延迟。

MHA提供了自动和手动故障转移命令。自动故障转移命令“masterha_manager（MHA Manager）”包括主服务器监控和主服务器故障转移。masterha_manager会持续监控主服务器的可用性。如果MHA Manager无法连接到主服务器，它将自动启动非交互式故障转移过程。

手动故障转移命令“masterha_master_switch”最初会检查主服务器是否真的死机。如果主服务器确实死机，masterha_master_switch将从从服务器中选择一个作为新主服务器（您可以选择首选主服务器），并启动恢复和故障转移。内部执行的操作更多，但您只需执行一个命令，而不必自己执行复杂的主服务器恢复和故障转移操作。

二 MHA架构

当主数据库发生崩溃时，MHA会按照以下步骤恢复其余的从数据库。

基本算法在2011年MySQL会议与博览会上的幻灯片中有所描述，特别是从第13页到第34页。

在从数据库的中继日志文件中，主数据库的二进制日志位置被写入“end_log_pos”部分（示例）。通过比较从数据库之间的最新end_log_pos，我们可以确定哪些中继日志事件没有发送到每个从数据库。MHA通过使用这种机制在内部恢复从数据库（修复一致性问题）。除了MySQL Conf 2011幻灯片中涵盖的基本算法外，MHA还进行了一些优化和增强，例如快速生成差异中继日志（与中继日志文件大小无关），使恢复与基于行的格式配合使用等等。

1 MHA组件

MHA由MHA Manager和MHA Node组成，如下所示。

MHA Manager有管理程序，例如监控MySQL主数据库，控制主故障转移等。

MHA Node具有故障转移辅助脚本，例如解析MySQL二进制/中继日志，识别应将中继日志应用于其他从数据库的中继日志位置，将事件应用于目标从数据库等。MHA Node在每个MySQL服务器上运行。

当MHA Manager执行故障转移时，MHA Manager通过SSH连接到MHA Node，并在需要时执行MHA Node命令。

2 自定义扩展（脚本）

MHA Manager有管理程序，例如监控MySQL主数据库，控制主故障转移等。

当MHA Manager执行故障转移时，MHA Manager通过SSH连接到MHA Node，并在需要时执行MHA Node命令。

自定义扩展 MHA具有几个扩展点。例如，MHA可以调用任何自定义脚本来更新主数据库的IP地址（更新管理主机IP地址的全局目录数据库，更新虚拟IP等）。这是因为如何管理IP地址取决于用户的环境，而MHA不想强制使用一种方法。

当前的扩展点如下。MHA Manager包括示例脚本。

secondary_check_script：用于从多个网络路由检查主数据库的可用性
master_ip_failover_script：用于更新应用程序使用的主数据库IP地址
shutdown_script：用于强制关闭主数据库
report_script：用于发送报告
init_conf_load_script：用于加载初始配置参数
master_ip_online_change_script：用于更新主数据库IP地址。这不是用于主故障转移，而是用于在线主切换。

三 MHA优势

1 MHA可以非常快速地进行主故障转移和从服务器晋升。

通常情况下，MHA可以在几秒钟内完成故障转移（9-12秒用于检测主服务器故障，可选择关闭主服务器以避免脑裂需要7-10秒，几秒钟用于将差异中继日志应用于新主服务器，因此总的停机时间通常为10-30秒），只要从服务器没有严重延迟复制。在恢复新的主服务器后，MHA会并行恢复其余的从服务器。即使您有成百上千个从服务器，也不会影响主服务器的恢复时间，您可以非常快速地恢复从服务器。

DeNA在150多个{主服务器，从服务器}环境中使用了MHA。当其中一个主服务器崩溃时，MHA在4秒内完成了故障转移。使用传统的主备集群解决方案从未能在4秒内完成故障转移。

2 主服务器崩溃不会导致数据不一致。

当当前主服务器崩溃时，MHA会自动识别从服务器之间的差异中继日志事件，并将其应用于每个从服务器。因此，只要所有从服务器都处于活动状态，最终所有从服务器都可以同步。通过与半同步复制一起使用，（几乎）可以保证几乎没有数据丢失。

3 无需修改当前的MySQL设置

（MHA与常规的MySQL（5.0或更高版本）配合使用）

MHA的设计原则之一是尽可能使MHA易于使用。只要可能，MHA就可以与现有的传统MySQL 5.0+主从复制环境配合使用。尽管许多其他高可用性解决方案需要更改MySQL部署设置，但MHA不会强制DBA执行此类任务。MHA适用于最常见的两层单主服务器和多个从服务器环境。MHA适用于异步和半同步MySQL复制。启动/停止/升级/降级/安装/卸载MHA可以在不更改（包括启动/停止）MySQL复制的情况下完成。当您需要将MHA升级到较新版本时，无需停止MySQL。只需替换为较新的MHA版本并重新启动MHA Manager即可。

MHA可以与正常的MySQL版本一起使用，从MySQL 5.0开始。一些HA解决方案需要特殊的MySQL版本（例如MySQL Cluster，带有全局事务ID的MySQL等），但您可能不想为了主服务器高可用性而迁移应用程序。在许多情况下，人们已经部署了许多传统的MySQL应用程序，并且他们不希望花费太多时间迁移到不同的存储引擎或更新的最新版本分发版本。MHA与包括5.0/5.1/5.5在内的正常MySQL版本一起使用，因此您不需要迁移。

4 无需增加大量服务器

MHA由MHA Manager和MHA Node组成。当发生故障转移/恢复时，MHA Node在MySQL服务器上运行，因此不需要额外的服务器。MHA Manager通常在专用服务器上运行，因此您需要添加一个（或两个用于高可用性）服务器，但MHA Manager可以从单个服务器监控大量（甚至100多个）主服务器，因此服务器总数不会增加太多。请注意，甚至可以在其中一个从服务器上运行MHA Manager。在这种情况下，总服务器数根本不会增加。

5 无性能损耗

MHA与正常的异步或半同步MySQL复制配合使用。当监控主服务器时，MHA只是每N秒（默认为3秒）向主服务器发送ping数据包，而不发送大量查询。您可以期望与正常的MySQL复制一样快的性能。

6 适用于任何存储引擎

只要MySQL复制工作，MHA即可与任何存储引擎配合使用，不限于InnoDB（崩溃安全的，事务性存储引擎）。即使您使用的是难以迁移的传统MyISAM环境，您也可以使用MHA。

四 MHA典型的使用情况

1 MHA Manager的部署位置

专用的Manager服务器和多个MySQL（主服务器，从服务器）服务器

由于MHA Manager使用的CPU/内存资源非常少，您可以从单个MHA Manager管理大量的（主服务器，从服务器）对。甚至可以从单个管理服务器管理100多对（主服务器，从服务器）。

在MySQL从服务器上运行MHA Manager

如果您只有一个（主服务器，从服务器）对，您可能不希望为MHA Manager分配专用的硬件，因为这会增加相对较高的成本。在这种情况下，在一个从服务器上运行MHA Manager是有意义的。请注意，当前版本的MHA Manager即使MySQL服务器位于与MHA Manager相同的主机上，也是通过SSH连接到MySQL从服务器的，因此您需要启用相同主机上的SSH公钥身份验证。

2 复制拓扑结构

一主多从

        M(RW)                                       M(RW), promoted from S1
         |                                           |
  +------+------+        --(master crash)-->   +-----+------+
S1(R)  S2(R)  S3(R)                          S2(R)        S3(R)

这是最常见的复制设置。MHA在这里运行得非常好。

一主多从（其中有个从库Sr在远程的数据中心）

        M(RW)                                        M(RW), promoted from S1
         |                                            |
  +------+------+        --(master crash)-->   +------+------+
S1(R)  S2(R)  Sr(R,no_master=1)              S2(R)         Sr(R,no_master=1)

在许多情况下，您希望至少在远程数据中心部署一个从服务器。当主服务器崩溃时，您可能不希望将远程从服务器提升为新的主服务器，而是让本地数据中心中的其他从服务器之一成为新的主服务器。MHA支持这样的需求。在配置文件中设置no_master=1可以确保从服务器永远不会成为新的主服务器。

一主多从（其中有个从库S0设置为候选主）

        M(RW)-----S0(R,candidate_master=1)           M(RW), promoted from S0
         |                                            |
  +------+------+        --(master crash)-->   +------+------+
S1(R)         S2(R)                          S1(R)         S2(R)

在某些情况下，如果当前的主服务器崩溃，您可能希望将特定的服务器提升为新的主服务器。在这种情况下，在配置文件中设置candidate_master=1将会有所帮助。

多主多从

       M(RW)<--->M2(R,candidate_master=1)           M(RW), promoted from M2
        |                                            |
 +------+------+        --(master crash)-->   +------+------+
S(R)         S2(R)                          S1(R)      S2(R)

在某些情况下，您可能希望使用多主配置，并且如果当前主服务器崩溃，您可能希望将只读主服务器变为新的主服务器。只要所有非主要主服务器（在此图中为M2）都是只读的，MHA Manager就支持多主配置。

三层级联复制

        M(RW)                                        M(RW), promoted from S1
         |                                            |
  +------+------+        --(master crash)-->   +------+------+
S1(R)  S2(R)  Sr(R)                          S2(R)         Sr(R)
                |                                            |
                +                                            +
               Sr2                                          Sr2

在某些情况下，您可能希望使用三层复制，就像这样。即使如此，MHA仍然可以用于主服务器故障转移。在配置文件中，管理主服务器和所有第二层从服务器（在此图中，将M、S1、S2和Sr添加到MHA配置文件中，但不添加Sr2）。如果当前主服务器（M）失败，MHA会自动将第二层从服务器（S1、S2、Sr中的一个，您也可以设置优先级）提升为新的主服务器，并恢复其余的第二层从服务器。第三层从服务器（Sr2）不受MHA管理，但只要Sr（Sr2的主服务器）处于活动状态，Sr2就可以继续复制而无需更改任何内容。

如果Sr崩溃，Sr2无法继续复制，因为Sr2的主服务器是Sr。MHA无法用于恢复Sr2。这就是全局事务ID支持的地方。希望这比主服务器崩溃不太严重。

三层级联复制，多主配置

       M1(host1,RW) <-----------------> M2(host2,read-only)
         |                                |
  +------+------+                         +
S1(host3,R)   S2(host4,R)               S3(host5,R)

=> After failover

                 M2(host2,RW)
                   |
    +--------------+--------------+
  S1(host3,R)    S2(host4,R)    S3(host5,R)

这种结构也受支持。在这种情况下，主机5是一个第三层从服务器，因此MHA不管理主机5（当主服务器主机1失败时，MHA不会在主机5上执行CHANGE MASTER）。当当前主服务器主机1宕机时，主机2将成为新的主服务器，因此主机5可以继续从主机2进行复制而无需做任何操作。以下是配置文件示例

[server default]
multi_tier_slave=1

[server1]
hostname=host1
candidate_master=1

[server2]
hostname=host2
candidate_master=1

[server3]
hostname=host3

[server4]
hostname=host4

[server5]
hostname=host5

3 管理主机IP地址

在常见的高可用环境中，许多情况下人们会在主服务器上分配一个虚拟IP地址。如果主服务器崩溃，诸如Pacemaker之类的HA软件会接管虚拟IP地址到备用服务器。

另一种常见的方法是创建一个全局目录数据库，其中包含所有应用程序名称和写入者/读取者IP地址之间的映射（例如{app1_writer，192.168.0.1}，{app2_writer，192.168.0.2}，…），而不是使用虚拟IP地址。在这种情况下，当当前主服务器失效时，您需要更新目录数据库。

这两种方法都有优点和缺点。MHA不强制使用一种方法，而是让用户可以使用任何IP地址故障转移解决方案。MHA有一个选项，可以通过在管理器的配置文件中设置master_ip_failover_script参数来调用外部脚本来停用/激活写入IP地址。您可以在脚本中更新目录数据库，接管虚拟IP地址，或执行任何您想要的操作。您还可以使用现有的HA软件（如Pacemaker）来执行IP故障转移。在这种情况下，MHA本身不执行IP故障转移。