mysql高可用方案MHA介绍

概述

MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用.在宕机的时间内(通常10—30秒内),完成故障切换,部署MHA,可避免主从一致性问题,节约购买新服务器的费用,不影响服务器性能,易安装,不改变现有部署。

还支持在线切换,从当前运行master切换到一个新的master上面,只需要很短的时间(0.5-2秒内),此时仅仅阻塞写操作,并不影响读操作,便于主机硬件维护。

在有高可用,数据一致性要求的系统上,MHA 提供了有用的功能,几乎无间断的满足维护需要。

优点

1 master自动监控和故障转移

在当前已存在的主从复制环境中,MHA可以监控master主机故障,并且故障自动转移。

即使有一些slave没有接受新的relay log events,MHA也会从最新的slave自动识别差异的relay log
events,并apply差异的event到其他slaves。因此所有的slave都是一致的。MHA秒级别故障转移(9-12秒监测到主机故障,任
选7秒钟关闭电源主机避免脑裂,接下来apply差异relay logs,注册到新的master,通常需要时间10-30秒即total
downtime)。另外,在配置文件里可以配置一个slave优先成为master。因为MHA修复了slave之间的一致性,dba就不用去处理一致
性问题。

当迁移新的master之后,并行恢复其他slave。即使有成千上万的slave,也不会影响恢复master时间,slave也很快完成。

DeNA公司在150+主从环境中用MHA。当其中一个master崩溃,MHA4秒完成故障转移,这是主动/被动集群解决方案无法完成的。

2 互动(手动)master故障转移

MHA可以用来只做故障转移,而不监测master,MHA只作为故障转移的交互。

3 非交互式故障转移

非交互式的故障转移也提供(不监控master,自动故障转移)。这个特性很有用,特别是你已经安装了其他软件监控master。比如,用Pacemaker(Heartbeat)监测master故障和vip接管,用MHA故障转移和slave提升。

4 在线切换master到不同主机

在很多情况下,有必要将master转移到其他主机上(如替换raid控制器,提升master机器硬件等等)。这并不是master崩溃,但
是计划维护必须去做。计划维护导致downtime,必须尽可能快的恢复。快速的master切换和优雅的阻塞写操作是必需的,MHA提供了这种方式。优
雅的master切换,
0.5-2秒内阻塞写操作。在很多情况下0.5-2秒的downtime是可以接受的,并且即使不在计划维护窗口。这意味着当需要更换更快机器,升级高版
本时,dba可以很容易采取动作。

5 master crash不会导致主从数据不一致性

当master crash后,MHA自动识别slave间relay logevents的不同,然后应用与不同的slave,最终所有slave都同步。结合通过半同步一起使用,几乎没有任何数据丢失。

其他高可用方案

6 MHA部署不影响当前环境设置

MHA最重要的一个设计理念就是尽可能使用简单。使用与5.0+以上主从环境,其他HA方案需要改变mysql部署设置,MHA不会让dba做这些部署配置,同步和半同步环境都可以用。启动/停止/升级/降级/安装/卸载 MHA都不用改变mysql主从(如启动/停止)。

当你需要升级MHA到新版本时,不需要停止mysql,仅仅更新HMA版本,然后重新启动MHAmanger即可。

MHA
支持包含5.0/5/1/5.5(应该也支持5.6,翻译文档时MHA开发者没更新对于5.6版本)。有些HA方案要求特定的mysql版本(如
mysqlcluster,mysql with global transaction id
等),而且你可能不想仅仅为了MasterHA而迁移应用。很多情况下,公司已经部署了许多传统的mysql应用,开发或dba不想花太多时间迁移到不同
的存储引擎或新的特性(newer bleeding edge distributions 不知道这个是否该这么翻译)。

7 不增加服务器费用

MHA 包含MHA Manager和MHA node。MHA
node运行在每台mysql服务器上,Manager可以单独部署一台机器,监控100+以上master,总服务器数量不会有太大增加。需要注意的是
Manager也可以运行在slaves中的一台机器上。

8 性能无影响

当监控master,MHA只是几秒钟(默认3秒)发送ping包,不发送大的查询。主从复制性能不受影响

9 适用任何存储引擎

Mysql不仅仅适用于事务安全的innodb引擎,在主从中适用的引擎,MHA都可以适用。即使用遗留环境的mysiam引擎,不进行迁移,也可以用MHA。

与其他HA方案比较

Doing everything manually

Mysql replication 是同步或半同步。当master崩溃时,很有可能一些slave还没有接受最新的relay log
events,这意味着每一个slave都相互处在不同的状态。人为修复一致性问题显得不再平凡。没有一致性问题,主从也可能不会启动(如
duplicate key error)。花费1个多小时重新启动主从复制显得不同寻常。

Single master and single slave

在单一主从情况下,一些slave 落后与其他slave的情况将不会发生。其中一个master崩溃,可以轻松的让应用转移到一个新的master上面,提供对外服务,故障迁移很简单。

Master, one candidate master, and multiple slaves双主多从

双主多从的架构也很常见。主master挂掉,备用master将接替主master提供服务。某些情况配置为多主架构。

M(RW)-----M2(R) M(RW), promoted from M2

| |

+----+----+ --(master crash)--> +-x--+--x-+

S(R) S2(R) S(?) S(?)

(Fromwhich position should S restart replication?)

但是这并不作为master故障转移方案。当前master挂掉,剩余slave不一定接受全部relay log events,修复数据一致性还是问题。

这种架构使用广泛,但是不是所有人都能深刻理解上述问题。当前master挂掉,slave变得不统一或者slave不能从新的master复制数据。

也许双master,其中一个master只读,每个master都至少有一个slave也许可能解决问题。

M(RW)--M2(R)

| |

S(R) S2(R)

Pacemaker + DRBD

Pecemaker(Heartbeat)+DRBD+Mysql是一个通用方案。但是这个方案也有以下问题

1
费用问题,特别是跑大量主从环境。Pecemaker+DRBD是主动/被动的解决方案,因此需要一台被动服务器对外不提供任何应用服务。基本的需要四台
mysql服务器,one active master,one passive master,two slaves。

2
宕机时间(downtime)。Pacemaker+DRBD是主备集群,主master挂掉,备用master启用。这可能花费长的时间,特别是没有用
innodb plugin。即使用innodb
plugin,花费几分钟开始在备用master上接受连接也不寻常。另外,因为备用master上数据/文件缓存是空的,恢复时间,热身(填充数据到
data buffer pool)花费不可忽视的时间。实践中,需要一台或更多slave提供足够的读服务。在热身时间内,空缓存导致写性能降低

3 写问题下降或一致性问题。为了让主动/被动集群真正的工作,每次提交(commit)后,必须刷新事务日志(binary
log和innodb
log),也就是必须设置innodb-flush-log-at-trx-commit=1,sync-binlog=1。设置sync-
binlog=1会降低写性能,因为fsync()函数被序列化(sync-binlog=1,group
commit失效)。大部分案例中,不设置sync-binlog=1.如果没有设置sync-binlog=1,活动master
crash,新的master(先前被动服务器)可能会丢失一些已经发送到slave的binary
log events。假如 master 挂掉,slave A接受到mysqld-bin.000123,位置1500。binlog
data刷新到硬盘的位置在1000,那么新的master数据也只能mysqld-bin.000123的1000处,然后在启动时创建一个新的
binary log mysqld-bin.000124。如果发生这种情况,slave A不能继续复制,因为新的master
没有mysqld-bin.000123位置1500.

4 复杂。对多数人来说,安装/初始化pacemake和DRBD不是容易的事情。相对于其他案例,初始化DRBD需要重新创建系统
区也不容易。要求dba在DRBD和linux内核层有足够的技能。如果dba执行了一个错误命令(如执行drbdadm–overwrite-
data-of-peer primary
在被动节点),那么将会损坏活动的数据。重要的是另外一旦硬盘io层出现问题,多数dba处理这种问题不是容易的。

MySQL Cluster

Mysql cluster是真正的高可用解决方案,但是必须得用NDB存储引擎。如果你用innodb,将不能发挥mysql cluster集群优势。

Semi-Synchronous Replication

半同步复制大大降低了binlog
event仅仅存在于崩溃master上的这种风险。这非常有用的能避免数据丢失。但是半同步不能解决所有一致性问题,只能保证一个(不是所
有)slave接受到master端的commit的binlog events,其他slave也许还没有接受全部的binlog
events。不能apply不同的binlog events 从新的slave到 其他slave上,也不能保证相互一致性

Global Transaction ID

GlobalTransaction ID所要达到的目的跟MHA相同,但它覆盖更多。MHA只是两级复制,但是global
transaction id覆盖任何级别的复制环境,即使第两级复制失败,dba也能覆盖第三级。Check Google‘sglobal
transaction id project for details。

来源: http://blog.csdn.net/wulantian/article/details/11770159

来自为知笔记(Wiz)

时间: 2024-10-15 08:46:40

mysql高可用方案MHA介绍的相关文章

MySQL高可用方案MHA自动Failover与手动Failover的实践及原理

集群信息 角色                             IP地址                 ServerID      类型 Master                         192.168.244.10   1                 写入 Candicate master          192.168.244.20   2                 读 Slave                           192.168.244.

(转)MySQL高可用方案MHA的部署和原理

背后深层次的逻辑: MHA Node则运行在每个mysql节点上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它自动将最新数据的slave提升为master,然后将其它所有的slave指向新的master. 在MHA自动故障切换过程中,MHA试图保存master的二进制日志,从而最大程度地保证数据不丢失,当这并不总是可行的,譬如,主服务器硬件故障或无法通过ssh访问,MHA就没法保存二进制日志,这样就只进行了故障转移但丢失了最新数据.可结合MySQL 5.

MySQL高可用之MHA—MHA介绍

MHA简介 MHA是由日本人yoshinorim(原就职于DeNA现就职于FaceBook)开发的比较成熟的MySQL高可用方案.MHA能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性.目前淘宝也正在开发相似产品TMHA,目前已支持一主一从. MHA架构 MHA由MHA Manager和MHA Node组成.如下图 MHA Manager 运行一些工具,比如masterha_manager工具实现自动监控MySQL Master和实现master故障切换,其它工具实现手动实

MySQL高可用之MHA的搭建

MySQL MHA架构介绍: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正的高可用. 该软件由两部分组成:MHA Manag

Heartbeat+DRBD+MySQL高可用方案

Heartbeat+DRBD+MySQL高可用方案 =============================================================================== 概述: =============================================================================== 方案介绍  1.方案介绍及优缺点 ★方案介绍 本方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性,数

[转载] MySQL高可用方案选型参考

原文: http://imysql.com/2015/09/14/solutions-of-mysql-ha.shtml?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 本次专题是 MySQL高可用方案选型,这个专题想必有很多同学感兴趣. 高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题. 可选MySQL高可用方案 MySQL的各种高可用方案,大多是基于以下几种基础来部署的: 基于主从复制:

Heartbeat+DRBD+MySQL高可用方案【转】

转自Heartbeat+DRBD+MySQL高可用方案 - yayun - 博客园 http://www.cnblogs.com/gomysql/p/3674030.html 1.方案简介 本方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性,数据的一致性由DRBD这个工具来保证.默认情况下只有一台mysql在工作,当主mysql服务器出现问题后,系统将自动切换到备机上继续提供服务,当主数据库修复完毕,又将服务切回继续由主mysql提供服务. 2.方案优缺点 优点:安全性高.稳

五大常见的MySQL高可用方案【转】

1. 概述 我们在考虑MySQL数据库的高可用的架构时,主要要考虑如下几方面: 如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断. 用作备份.只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致. 当业务发生数据库切换时,切换前后的数据库内容应当一致,不会因为数据缺失或者数据不一致而影响业务. 关于对高可用的分级在这里我们不做详细的讨论,这里只讨论常用高可用方案的优缺点以及高可用方案的选型. 2. 高可用方

MySQL高可用方案选型参考

本次专题是 MySQL高可用方案选型,这个专题想必有很多同学感兴趣. 高可用的意义以及各种不同高可用等级相应的停机时间我就不必多说了,直接进入主题. 可选MySQL高可用方案 MySQL的各种高可用方案,大多是基于以下几种基础来部署的: 基于主从复制: 基于Galera协议: 基于NDB引擎: 基于中间件/proxy: 基于共享存储: 基于主机高可用: 在这些可选项中,最常见的就是基于主从复制的方案,其次是基于Galera的方案,我们重点说说这两种方案.其余几种方案在生产上用的并不多,我们只简单