中国科学院大学计算机硕士，曾在新浪爱彩数据库组带DBA团队，现居新加坡。wx: lihui_dba
分类： Mysql/postgreSQL
2017-03-15 10:27:19
MHA以最少的停机时间（通常在10-30秒内）执行自动化master故障转移和slave升级。 MHA可防止复制一致性问题，并节省不得不购买额外服务器的费用。 所有这些都具有零性能降级，没有复杂性（易于安装），并且不需要更改现有部署。
MHA还提供定时（计划内（scheduled））在线master切换，安全地将当前运行的master更改为新master，只需几秒钟（0.5-2秒）的停机时间（仅阻塞写入）。
MHA提供以下功能，并且在许多需要高可用性、数据完整性和master接近不停机维护的部署中是有用的。
l 自动master监控和故障转移
MHA可以在现有复制环境中监控MySQL的master，在检测到master故障时执行自动master故障转移。 MHA通过识别来自最新slave的relay log时间的差异并将其应用于所有其他slave，包括那些仍未接收到最新的中继日志事件的slave，从而保证所有从机的一致性。 MHA通常可以在几秒钟内执行故障切换：9-12秒检测master故障，可选地7-10秒钟关闭主机以避免脑裂，几秒钟将中继日志应用到新的master。 总停机时间通常为10-30秒。 可以在配置文件中将特定slave指定为候选master（设置优先级）。 由于MHA维护slave之间的一致性，任何slave都可以升级成为新的master。 不会发生复制失败导致的一致性问题。
l 交互（手动启动）master故障转移
MHA可以配置为手动启动（非自动），交互式故障转移，而无需监视master。
l 非交互式master故障转移
还支持非交互式，自动master故障转移，而无需监控master。 当MySQL master软件监控已在使用时，此功能特别有用。 例如，您可以使用Pacemaker（heartbeat）检测master失败和虚拟IP地址接管，同时使用MHA进行master故障转移和提升slave。
l 在线切换master到不同的主机
如果经常需要将现有master迁移到其他服务器，例如当前主机具有H / W RAID控制器或RAM问题时，或者当您要升级为更快的服务器时。这不是master崩溃了，但需要计划内的维护时间。 计划内的master维护应尽可能快地完成，因为它需要部分停机时间（阻塞master写操作）。 另一方面，您应该非常小心地阻塞/杀死当前运行的会话，因为不同的master之间可能会发生数据一致性问题（即“updating master1, updating master 2, committing master1, 在committing master 2时出现错误”将导致数据不一致）。 快速master切换和阻塞写入都是需要的。
MHA在写入阻塞的0.5-2秒内提供了优雅的master切换。 0.5-2秒的写入阻塞时间通常是可以接受的，因此即使没有分配预定的维护时间窗口，也可以切换master。 诸如升级到更高版本，更快的服务器等等的动作变得更容易。
master故障转移不像看起来那样简单。 采用最典型的MYSQL部署情况下，拥有多个slave的单个master。 如果master崩溃，您需要选择一个最新的slave，将其升级为新的master，并让其他slave从新master开始复制。 这实际上不是微不足道（trivial）的。 即使可以识别最新的slave，其他slave很可能还没有接收到所有的二进制日志事件。 如果在复制开始时连接到新master，那些slave将丢失事务。 这将导致一致性问题。 为了避免这些一致性问题，需要识别丢失的二进制日志事件（尚未到达所有slave），并且在新（提升的）master上启动复制之前依次应用于每个从节点。 这种操作可能非常复杂并且难以手动执行。 这在我在MySQL会议和2011年世博会幻灯片的演示文稿（特别是在下面的第10页）中进行了说明。
图：主故障转移：什么让它很难？
目前大多数MySQL Replication用户别无选择，只能在主机崩溃后手动执行故障转移。 一个或多个小时的停机时间都不一定能完成故障转移。 并不是所有的slave都将能接收到相同的中继日志事件，导致稍后不得不校正一致性问题。 即使主机崩溃很少发生，但是当发生时就会非常痛苦。
MHA旨在尽快完全自动化master故障转移和恢复过程，而无需任何被动（备用）服务器。 恢复包括确定新master，识别slave之间的差异中继日志事件，向新master应用必要的事件，同步其他slave，并让它们从新master开始复制。 MHA通常可以在10-30秒的停机时间内进行故障转移（10秒检测master故障，可选7-10秒关闭master主机以避免脑裂，几秒或更长时间用于恢复），根据复制延迟。
MHA提供自动和手动故障转移命令。 自动故障切换命令“ masterha_manager （MHA Manager）”由master monitoring和master failover组成。 masterha_manager永久监控master服务器的可用性。 如果MHA Manager无法访问主服务器，它会自动启动非交互式故障转移过程。
手动故障转移命令“ masterha_master_switch ”首先检查以确定master实际上已dead。 如果master真的挂掉了， masterha_master_switch选择其中一个slave作为新master（您可以选择首选master），并启动恢复和故障转移。 在内部它做的更多，但是你只执行一个命令，而不必自己执行复杂的master恢复和故障转移操作。
有关详细信息，请参阅Other_HA_Solutions页。
有关详细信息，请参阅架构页。
有关详细信息，请参阅优势页。
有关详细信息，请参阅UseCases页面。
MySQL复制是异步或半同步的。 当master崩溃时，可能一些slave没有收到最新的中继日志事件，这意味着每个slave都可能处于不同的状态。手动修复一致性问题并不简单。 但是没有修复一致性问题，复制可能无法启动（即duplicate key error）。 花费一个多小时手动重新启动复制并不罕见。
如果你有一个master，只有一个slave，“some slaves behind the latest slave”情况永远不会发生。 当master崩溃时，只需让应用程序将所有流量发送到新的master。所以故障转移很容易。
但有很多非常严重的问题。 首先，您无法横向扩展读流量。 在许多情况下，您可能希望在其中一个从服务器上执行大的操作，例如备份，数据分析，批处理作业。 这些可能会导致从服务器上的性能问题。 如果你只有一个slave，slave崩溃的话，master必须处理所有这样的流量。
第二个问题是可用性。 如果master崩溃，则只剩下一个服务器（新master），因此它成为单点。 要创建新的slave，您需要进行在线备份，在新硬件上恢复，并立即启动slave。 但是这些操作通常需要几个小时（甚至超过一天完全赶上复制）。 在一些关键应用程序中，您可能不会接受数据库在这么长时间内成为单点。 并且在主服务器上进行在线备份会显著增加i / o负载，因此在高峰期进行备份是很危险的。
第三个问题是缺乏可扩展性。 例如，当您要在远程数据中心上创建只读数据库时，需要至少两个slave，一个是本地数据中心上的slave，另一个是远程数据中心上的slave。 如果你只有一个slave，你不能构建这个架构。
单个slave在许多情况下实际上是不够的。
使用“一个maser，一个候选master，多个slave”架构也很常见。 如果当前master崩溃，则候选master是新master的主要目标。 在某些情况下，它被配置为只读master：多master配置。
但这并不总是作为master故障转移解决方案。 当当前master崩溃时，其余slave可能未收到所有中继日志事件，因此仍需要像其他解决方案一样在slave之间维护一致性问题。
如果您无法接受一致性问题，但想立即恢复服务怎么办？ 只需启动候选master作为新主节点，并放弃所有其余的从节点。 之后，您可以通过从新的master上进行联机备份来创建新的slave。 但是这种方法具有与上述“Single master and single slave”方法相同的问题。 其余slave不能用于读取或冗余目的。
这种架构被广泛使用，但没有多少人完全理解上述潜在的问题。 当当前master崩溃时，slave变得不一致，即使您只是让slave从新master开始复制，也不能启动复制。 如果需要保证一致性，则不能使用其余的slave。 这两种方法都有严重的缺点。
顺便提及，“使用两个master（一个是只读的）和每个master具有至少一个slave（如下图）”也是可能的。
当当前master崩溃时，至少有一个slave可以继续复制，但实际上没有那么多用户采用这种架构。 最大的缺点是复杂性。 在该架构中使用三层复制（M-> M2-> S2）。 但是管理三层复制并不容易。 例如，如果中间服务器（M2：候选master）崩溃，则第三层slave（S2）无法继续复制。 在许多情况下，您必须再次设置M2和S2。 还有一点是在此架构中至少需要四个服务器。
使用Pacemaker（Heartbeat）+ DRBD + MySQL是一种非常常见的HA解决方案。 但是这个解决方案也有一些严重的问题。
一个问题是成本，特别是如果你想运行大量的MySQL复制环境。 Pacemaker + DRBD是active/standby解决方案，因此您需要一个不处理任何应用程序流量的passive master。 passive server不能用于读取分流。 通常，您需要至少四个MySQL服务器，一个active master, 一个passive master，两个slave（一个用于报表等）。
第二个问题是停机时间。 由于Pacemaker + DRBD是active/standby集群，因此如果active服务器崩溃，则passive服务器上会发生崩溃恢复。 这可能需要很长时间，特别是如果你不使用InnoDB。 即使您使用InnoDB，standby server通常也需要几分钟或更长时间才能开始接受新的连接。 除了崩溃恢复时间，预热（将数据填充到缓冲池中）在故障转移后需要大量时间，因为在passive server上数据库/文件系统高速缓存是空的。 实际上，您需要一个或多个附加的slave来处理足够的读取流量。 同样重要的是，写入性能在预热期间也会显著下降，因为缓存为空。
第三个问题是写性能下降或一致性问题。 要使active/passive HA cluster真正工作，您必须在每次提交时将事务日志（二进制日志和InnoDB日志）刷新到磁盘。 也就是说，您必须设置innodb-flush-log-at-trx-commit = 1和sync-binlog = 1。 但是目前sync-binlog = 1会导致写性能下降，因为fsync（）在当前MySQL中是序列化的（如果sync-binlog为1，则组提交被破坏）。 在大多数情况下，人们不会设置sync-binlog = 1。 但如果未设置sync-binlog = 1，则当active master崩溃时，新master（先前的passive server）可能会丢失已发送到slave的一些二进制日志事件。 假设master崩溃，slave A接收到mysqld-bin.000123：1500.如果binlog数据刷新到磁盘只到position1000，则新master的mysqld-bin.000123最多只能为1000，并在启动时创建新的二进制日志mysqld-bin.000124。 如果发生这种情况，slave A无法继续复制，因为新master没有mysqld-bin.000123：1500。
第四个问题是复杂性。 许多用户安装/配置Pacemaker和DRBD（特别是DRBD）实际上并不是trivial的。 配置DRBD在许多部署中通常需要重新创建操作系统分区，这并不容易。 你还需要有足够的DRBD和Linux内核知识。 如果执行错误的命令（即在passive node上执行drbdadm - --overwrite-data-of-peer primary），它很容易中断实时数据。 同样重要的是，一旦使用DRBD发生磁盘i / o层问题，修复这个问题对于大多数DBA来说真的很困难。
MySQL Cluster是真正的Highly解决方案，但是你必须使用NDB存储引擎。 当你使用InnoDB（在大多数情况下），你不能利用MySQL集群。
半同步复制大大减少了“binlog events只存在于崩溃的主机”情况的风险。 这是真正有助于避免数据丢失。 但是半同步复制不能解决所有一致性问题。 半同步复制保证至少一个 （不是所有）slave在master提交时接收到二进制日志事件。 还有一些slave可能没有接收到所有二进制日志事件。 如果这些slave没有从最新的slave应用差异的relay log events，那slave就不能保持一致。
MHA负责处理这些一致性问题，因此通过使用半同步复制和MHA，可以实现“几乎没有数据丢失”和“从属一致性”。
全局事务id的目的基本上与MHA试图实现的目的相同，但它涵盖更多。 MHA仅使用两层复制，但全局事务ID可以覆盖任何层的复制环境，因此即使第二层slave失败，您也可以恢复第三层slave。 有关详细信息，请参阅Google的全局事务ID项目 。
从MySQL 5.6开始支持GTID。 Oracle的官方工具mysqlfailover支持使用GTID的master故障转移。 从MHA版本0.56开始，MHA也支持基于GTID的故障转移。 MHA自动检测mysqld是否使用GTID运行，如果启用了GTID，MHA将使用GTID进行故障转移。 如果不是，MHA使用中继日志执行传统故障转移。
当master崩溃时，MHA是这样恢复slave的。
基本算法在2011年MySQL会议和博览会上展示的幻灯片中有所描述，特别是从第13页到第34页。
在slave上的中继日志文件中，master的二进制日志位置写在“end_log_pos”部分（ 示例 ）。
通过比较slave之间的最新end_log_pos，我们可以识别哪些relay log事件不发送到每个slave。 MHA内部使用此机制在内部恢复slave（修复一致性问题）。 除了在MySQL Conf 2011的幻灯片中所涵盖的基本算法之外，MHA还进行了一些优化和增强，例如非常快速地生成差异relay log（与relay log文件大小无关），使恢复可以基于行格式等。
MHA由MHA管理器和MHA节点组成，如下所示。
MHA manager有管理程序，如监控MySQL master，控制master失效转移等。
MHA node具有故障转移助手脚本，如解析MySQL二进制/中继日志，在中继日志需要应用到其他slave时标识中继日志位置，应用事件到目标slave等。MHA node在每个MySQL服务器上运行。
当MHA manager进行故障转移时，MHA manager通过SSH连接MHA node，并在需要时执行MHA node命令。
MHA有几个扩展点。 例如，MHA可以调用任何自定义脚本更新master的IP地址（更新管理master的IP地址的全局编录数据库，更新虚拟IP等）。
(updating global catalog database that manages master's ip address, updating virtual ip, etc)
这是因为如何管理IP地址取决于用户的环境，MHA不想强制一种方法。
当前扩展点如下。 MHA Manager软件包包含示例脚本。
secondary_check_script ：用于检查来自多个网络路由的master的可用性
master_ip_failover_script ：用于更新应用程序使用的master的IP地址
shutdown_script ：强制关闭master
report_script ：用于发送报告
init_conf_load_script ：用于加载初始化配置参数
master_ip_online_change_script ：用于更新master IP地址。 这不用于主故障转移，但用于在线master切换。
MHA通常可以在几秒钟内完成故障切换（9-12秒检测master故障，可选地7-10秒关闭master主机以避免裂脑，几秒钟将差异的relay log应用到新master，因此总停机时间是通常10-30秒），只要slave的复制延迟不严重。 在修复新的master之后，MHA并行地恢复其余的slave。 即使您有数十个slave，它也不影响master的恢复时间，并且您可以非常快速地恢复slave。
DeNA在150+ {master，slaves}环境中使用MHA。 当master中的一个崩溃时，MHA在4秒内完成故障转移。 使用传统的active/passive集群解决方案，无法在4秒内进行故障转移。
当当前master崩溃时，MHA自动识别slave之间差异的relay log event，并应用于每个slave。 所以最后所有slave可以同步，只要所有从服务器都存活。 通过与半同步复制一起使用，（几乎）能保证没有数据丢失。
（MHA使用常规MySQL（5.0或更高版本））
MHA的最重要的设计原则之一是使MHA尽可能的容易使用。 MHA使用现有的传统MySQL 5.0+主从复制环境。 虽然许多其他高可用性解决方案需要更改MySQL部署设置，但MHA不会强制让DBA执行此类任务。 MHA与最常见的两层单master和多slave环境配合工作。 MHA适用于异步和半同步MySQL复制。 启动/停止/升级/降级/安装/卸载MHA可以在不更改（包括启动/停止）MySQL复制的情况下完成。 当您需要将MHA升级到较新版本时，您不需要停止MySQL。 只需更换新的MHA版本和重新启动MHA manager就可以了。
MHA可以使用从MySQL 5.0开始的官方MySQL版本。 一些高可用性解决方案需要特殊的MySQL版本（即MySQL cluster，带有GTID的MySQL等），但是您可能不想迁移仅用于 master HA的应用程序。 在许多情况下，人们已经部署了许多传统的MySQL应用程序，他们不想花太多时间迁移到不同的存储引擎或更新的出血边缘分布（ newer bleeding edge distributions）仅仅是为了master的HA。 MHA使用正常的MySQL版本，包括5.0 / 5.1 / 5.5，所以你不需要迁移。
MHA由MHA管理器和MHA节点组成。 当发生故障转移/恢复时，MHA节点在MySQL服务器上运行，因此不需要额外的服务器。 MHA Manager通常在专用服务器上运行，因此您需要添加一个（或两个）HA服务器，但MHA Manager可以从单个服务器监视大量（甚至100+）主服务器，因此服务器总数不是增加这么多。 请注意，甚至可以在slave之一上运行MHA Manager。 在这种情况下，服务器的总数量根本不增加。
MHA适用于常规异步或半同步MySQL复制。 当监控主服务器时，MHA只是每隔N秒向主机发送ping数据包（默认为3），并且不会执行大量查询。 您可以预料到像MySQL复制一样快速的性能。
MHA可以与任何存储引擎一起工作，只要MySQL复制工作，而不限于InnoDB（崩溃安全，事务存储引擎）。 即使您使用不易迁移的旧版MyISAM环境，也可以使用MHA。
l 专用manager server和多个MySQL（主，从）服务器
由于MHA Manager使用非常少的CPU /内存资源，您可以用单个MHA Manager管理大量（主，从）服务器组。 甚至可以用单个manager服务器管理100+组。
l 在MySQL从服务器之一上面运行MHA Manager
如果您只有一个（主，从）组，您可能不想为MHA Manager分配专用硬件，因为它会增加相对较高的成本。 在这种情况下，在一个slave上运行MHA Manager是有意义的。 请注意，当前版本的MHA Manager通过SSH连接到MySQL slave，即使MySQL服务器位于与MHA Manager相同的主机上，因此您需要在同一台主机上启用SSH公钥认证。
单master，多slave
这是最常用的复制设置。 MHA在这里工作得很好。
单master，多slave（一个在远程数据中心）
在许多情况下，您希望在远程数据中心上部署至少一个slave。 当master崩溃时，您可能不想将远程slave升级为新master，让在本地数据中心上运行的其他slave中的一个成为新的master。 MHA支持这些需求。 在配置文件中设置no_master = 1使slave不会成为新的master。
单master，多slave，一个候选master
在某些情况下，如果当前master崩溃，您可能想要将特定服务器提升为新master。 在这种情况下，在配置文件中设置candidate_master = 1将有所帮助。
多master，多slave
在某些情况下，您可能想要使用多master配置，如果当前master崩溃，您可能想要使只读master成为新master。 MHA Manager支持多主机配置，只要所有非主要的master（本图中的M2）是只读的。
三层复制
在某些情况下，您可能想使用这样的三层复制。 MHA仍可用于master故障转移。 在配置文件中 ，管理master和所有第二层slave（在此图中，在MHA配置文件中添加M，S1，S2和Sr，但不添加Sr2）。 如果当前master（M）发生故障，MHA会自动将第二级slave的其中一个（S1，S2，Sr，并且您也可以设置优先级）提升为新的master，并恢复其余的第二级slave。 第三层slave（Sr2）不由MHA管理，但只要Sr（Sr2的master）存活，Sr2可以继续复制，而不改变任何东西。
如果Sr崩溃，Sr2不能继续复制，因为Sr2的master是Sr.MHA不能用于恢复Sr2。 这要求支持全局事务id。 希望这没有master崩溃所造成的结果严重。
三层复制，多主
也支持此结构。 在这种情况下，host5是第三层slave，因此MHA不管理host5（当主master host1发生故障时，MHA不会在host5上执行CHANGE MASTER）。 当当前master host1关闭时，host2将是新的master，因此host5可以保持从host2的复制而不做任何事情。 这里是配置文件示例。
管理master IP地址
在常见的HA环境中，许多情况下人们在master上分配一个虚拟IP地址。 如果master崩溃，像Pacemaker这样的HA软件将虚拟IP地址接管到备用服务器。
另一个常见的方法是创建一个全局编录数据库，它含有应用程序名称和wiriter/reader IP地址（即{app1_writer，192.168.0.1}，{app2_writer，192.168.0.2}，...）之间的所有映射，而不是使用虚拟IP地址。 在这种情况下，您需要在当前master宕机时更新目录数据库。
这两种方法都有优点和缺点。 MHA不强制一种方法，但让用户可以使用任何IP地址故障转移解决方案。 MHA可以通过在管理器的配置文件中设置master_ip_failover_script参数调用外部脚本来禁用/激活写入IP地址。 您可以更新目录数据库，接管虚拟IP地址，或在脚本中执行任何您想要的操作。 您还可以使用现有的高可用性软件（如Pacemaker）执行IP故障转移。 在这种情况下，MHA本身不进行IP故障转移。
虽然MHA试图从崩溃的主机保存二进制日志，但并不总是可能的。 例如，如果崩溃的master是H / W故障或通过SSH无法访问，MHA无法保存二进制日志，并且必须进行故障转移，而不应用在崩溃的master上存在的二进制日志事件。 这将导致丢失最新的数据。
使用半同步复制大大降低了这种数据丢失的风险。 MHA使用半同步复制，因为它基于MySQL复制机制。 值得注意的是，如果只有一个slave接收到最新的二进制日志事件，MHA可以将事件应用于所有其他slave，因此它们可以彼此一致。
