门牙没了的技术博客

Mysql/大数据

  • 博客访问: 180846
  • 博文数量: 38
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1639
  • 用 户 组: 普通用户
  • 注册时间: 2013-08-20 16:13
个人简介

曾就读于中国科学院大学,现在新浪爱彩系统运维部数据库组搬砖,Mysql DBA。QQ:362931297

文章分类

全部博文(38)

文章存档

2017年(3)

2016年(2)

2015年(7)

2014年(16)

2013年(10)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: Mysql/postgreSQL

本文基于MHA官方文档0.56版wiki翻译而成

原文链接:https://github.com/yoshinorim/mha4mysql-manager/wiki

概述

概述

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故障转移的困难


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页。

MHA架构

有关详细信息,请参阅架构页。

MHA的优点

有关详细信息,请参阅优势页。

用例

有关详细信息,请参阅UseCases页面。

其他解决方案和问题

手动执行所有操作

MySQL复制是异步或半同步的。 当master崩溃时,可能一些slave没有收到最新的中继日志事件,这意味着每个slave都可能处于不同的状态。手动修复一致性问题并不简单。 但是没有修复一致性问题,复制可能无法启动(即duplicate key error)。 花费一个多小时手动重新启动复制并不罕见。

单master和单slave

如果你有一个master,只有一个slave,“some slaves behind the latest slave”情况永远不会发生。 当master崩溃时,只需让应用程序将所有流量发送到新的master。所以故障转移很容易。

但有很多非常严重的问题。 首先,您无法横向扩展读流量。 在许多情况下,您可能希望在其中一个从服务器上执行大的操作,例如备份,数据分析,批处理作业。 这些可能会导致从服务器上的性能问题。 如果你只有一个slave,slave崩溃的话,master必须处理所有这样的流量。


第二个问题是可用性。 如果master崩溃,则只剩下一个服务器(新master),因此它成为单点。 要创建新的slave,您需要进行在线备份,在新硬件上恢复,并立即启动slave。 但是这些操作通常需要几个小时(甚至超过一天完全赶上复制)。 在一些关键应用程序中,您可能不会接受数据库在这么长时间内成为单点。 并且在主服务器上进行在线备份会显著增加i / o负载,因此在高峰期进行备份是很危险的。


第三个问题是缺乏可扩展性。 例如,当您要在远程数据中心上创建只读数据库时,需要至少两个slave,一个是本地数据中心上的slave,另一个是远程数据中心上的slave。 如果你只有一个slave,你不能构建这个架构。


单个slave在许多情况下实际上是不够的。

master,一个候选master和多个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和DRBD


使用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集群

MySQL Cluster是真正的Highly解决方案,但是你必须使用NDB存储引擎。 当你使用InnoDB(在大多数情况下),你不能利用MySQL集群。

半同步复制

半同步复制大大减少了“binlog events只存在于崩溃的主机”情况的风险。 这是真正有助于避免数据丢失。 但是半同步复制不能解决所有一致性问题。 半同步复制保证至少一个 (不是所有)slave在master提交时接收到二进制日志事件。 还有一些slave可能没有接收到所有二进制日志事件。 如果这些slave没有从最新的slave应用差异的relay log events,那slave就不能保持一致。


MHA负责处理这些一致性问题,因此通过使用半同步复制和MHA,可以实现“几乎没有数据丢失”和“从属一致性”。

全局事务ID

全局事务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使用中继日志执行传统故障转移。

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节点组成,如下所示。

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的优势

master故障转移和slave升级可以非常快速地完成

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崩溃不会导致数据不一致

当当前master崩溃时,MHA自动识别slave之间差异的relay log event,并应用于每个slave。 所以最后所有slave可以同步,只要所有从服务器都存活。 通过与半同步复制一起使用,(几乎)能保证没有数据丢失。

无需修改当前MySQL设置

(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。


用例

典型用例

在哪里部署Manager


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,因此它们可以彼此一致。

阅读(17) | 评论(0) | 转发(0) |
0

上一篇:一次奇怪的MySQL复制故障

下一篇:没有了

给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册