MySQL基于MHA高可用理论篇,MySQL高可用之MHA切换测

作者:计算机知识

 

MySQL高可用之MHA 

MHA简介

MHA是由新加坡人yoshinorim(原就职于DeNA现就职于FaceBook)开采的比较成熟的MySQL高可用方案。MHA能够在30秒内达成故障切换,并能在故障切换中,最大恐怕的保险数据壹致性。近来Tmall也正值开垦相似产品TMHA,近来已扶助一主一从。
 
MHA架构
MHA由MHA Manager和MHA Node组成,如下图所示:

图片 1

 
MHA Manager:
运作一些工具,举个例子masterha_manager工具实现全自动监察和控制MySQL Master和落到实处master故障切换,别的工具完毕手动完成master故障切换、在线mater转移、连接检查等等。三个Manager能够管理多个master-slave集群
 
MHA Node: 布署在享有运营MySQL的服务器上,无论是master依旧slave。主要效率有八个。
    Ⅰ、保存贰进制日志
           倘诺能够访问故障master,会拷贝master的二进制日志

     II、应用差距中继日志
          从全数新型数据的slave上扭转差距中继日志,然后采取差距日志。

     III、清除中继日志
          在比十分大憩SQL线程的景观下删除中继日志
 
MHA专门的学问规律

图片 2

当master出现故障时,通过对照slave之间I/O线程读取masterbinlog的职位,选择最周边的slave做为latestslave。别的slave通过与latest slave相比较变化差别中继日志。在latest slave上应用从master保存的binlog,同时将latest slave进步为master。最终在任何slave上利用相应的差别中继日志并起头从新的master开头复制。
 
在MHA达成Master故障切换进程中,MHA Node会试图访问故障的master(通过SSH),假如得以访问(不是硬件故障,比方InnoDB数据文件损坏等),会保留2进制文件,以最大程度保险数据不丢掉。MHA和半协助实行理并答复制一同行使会大大降低数据丢失的危险。
 
日前高可用方案
Heartbeat DRBD:

  • 支付:须要相当增多处于精疲力尽状态的master server(并不管理利用流量)

  • 属性:为了兑现DRBD复制景况的高可用,innodb-flush-log-at-trx-commit和sync-binlog必须安装为一,那样会产生写质量降低。

  • 1致性:在master上必不可缺的binlog时间大概会丢掉,那样slave就不能够举办复制,导致发生多少一致性难点

 
MySQL Cluster:
MySQL Cluster真正完成了高可用,但是使用的是NDB存款和储蓄引擎,并且SQL节点有单点故障难点。
 
半一并复制(5.5 )

  • 半联合进行理并答复制大大减弱了“binlog events只存在故障master上”的题目。

  • 在付出时,保障至少贰个slave(并不是享有的)接收到binlog,由此有的slave大概未有吸收到binlog。

全局工作ID

  • 在二进制文件中增添全局职业ID(global transaction id)必要改动binlog格式,在伍.1/伍.五版本中不支持。

  • 在行使方面有大多艺术可以直线全局专门的工作ID,不过仍防止不了复杂度、质量、数据丢失也许一致性的主题材料。

 
PXC:
PXC达成了服务高可用,数据同步时是出新复制。不过仅帮衬InnoDB引擎,全数的表都要有主键。锁争辨、死锁难题相对较多等等问题。
 
MHA的优势 壹、故障切换快
在主从复制集群中,只要从库在复制上未有延迟,MHA日常能够在数秒内实现故障切换。九-10秒内检查到master故障,能够挑选在7-10秒关闭master以幸免出现裂脑,几分钟内,将差异中继日志(relay log)应用到新的master上,因而总的宕机时间一般为十-30秒。恢复生机新的master后,MHA并行的过来其他的slave。即便在有数万台slave,也不会潜移默化master的东山再起时间。

DeNA在超过一四十两个MySQL(首要5.0/伍.壹版本)主从景况下行使了MHA。当mater故障后,MHA在四秒内就做到了故障切换。在古板的能动/被动集群消除方案中,肆秒内做到故障切换是不大概的。
 
二、master故障不会招致数据区别等
当这段时间的master出现故障是,MHA自动识别slave之间对接日志(relay log)的例外,并选取到全部的slave中。那样有着的salve能够保险同步,只要具备的slave处于存活状态。和Semi-Synchronous Replication一同使用,(大致)能够保证未有多少丢失。

叁、无需修改当前的MySQL设置
MHA的筹算的要害条件之1正是不择花招地大概易用。MHA专门的学业在守旧的MySQL版本五.0和将来版本的主从复制遇到中。和其余高可用化解办法比,MHA并不须要更换MySQL的配备境况。MHA适用于异步和半齐声的主从复制。
 
开发银行/结束/进级/降级/安装/卸载MHA没有须要转移(包扩运维/甘休)MySQL复制。当需求提高MHA到新的本子,不需求结束MySQL,仅仅替换成新本子的MHA,然后重启MHA Manager就好了。
 
MHA运维在MySQL 伍.0从头的原生版本上。一些别的的MySQL高可用化解方案要求一定的版本(比方MySQL集群、带全局专门的职业ID的MySQL等等),但并不只为了master的高可用才迁移应用的。在大多景观下,已经布署了相比旧MySQL应用,并且不想单独为了落到实处Master的高可用,花太多的日子迁移到不一样的积攒引擎或更新的前方发行版。MHA专门的职业的包含伍.0/伍.1/伍.伍的原生版本的MySQL上,所以并无需迁移。

四、不必要扩张大气的服务器
MHA由MHA Manager和MHA Node组成。MHA Node运营在必要故障切换/苏醒的MySQL服务器上,由此并不须要额外扩展服务器。MHA Manager运行在特定的服务器上,由此要求扩张一台(完成高可用需求二台),不过MHA Manager能够监督多量(乃至上百台)单独的master,因而,并没有供给扩大大气的服务器。即便在一台slave上运转MHA Manager也是足以的。综上,实现MHA并没用额外增加大气的劳务。

五、无品质降低
MHA适用与异步或半联合的MySQL复制。监察和控制master时,MHA仅仅是每隔几秒(暗许是3秒)发送一个ping包,并不发送重查询。能够博得像原生MySQL复制同样快的天性。

六、适用于任何存储引擎
MHA可以运营在只要MySQL复制运维的积累引擎上,并不止限制于InnoDB,尽管在科学迁移的理念意识的MyISAM引擎情形,同样能够行使MHA。

 

来自为知笔记(Wiz)

MySQL高可用类别之MHA(一)

MHA,即Master High Availability Manager and Tools for MySQL,是东瀛的一个人MySQL专家选用Perl语言编写的1个本子管理工科具,该工具仅适用于MySQL Replication(贰层)情况,意在有限帮衬Master主库的高可用性。

MySQL高可用系统

MySQL高可用,看名称就会想到其意义正是当MySQL主机或劳动发生其余故障时能够即时有其余主机顶替其行事,并且最低必要是要保障数据一致性。因此,对于几个MySQL高可用系统供给达到的对象有以下几点:

(一)、数据①致性保障这几个是最中央的还要也是前提,假设主备的数额差异样,那么切换就无法开始展览,当然这里的一致性也是一个针锋绝对的,不过要完结最后1致性。

(二)、故障火速切换,当master故障时这里能够是机械故障恐怕是实例故障,要确认保证工作能在最长时间切换来备用节点,使得业务受影响时间最短。

(三)、简化日常爱护,通过高可用平台来机关实现高可用的布局、维护、监察和控制等职分,能够最大程度的解放DBA手动操作,升高普通运营功用。

(四)、统1管理,当复制集众多的事态下,能够合并保管高可用实例消息、监察和控制新闻、切换音信等。

(5)、高可用的布局要对现成的数据库架构无影响,假诺因为铺排高可用,要求改动只怕调度数据库架构则会导致资金扩大。

当前MySQL高可用方案得以毫无疑问程度上完成数据库的高可用,举例MMM,heartbeat drbd,NDB Cluster等。还有玛丽亚DB的Galera Cluster,以及MySQL 伍.7.17 Group Replication等。这么些高可用软件各有所长。在举行高可用方案选用时,首借使看工作对数据一致性方面包车型客车供给。最后由于对数据库的高可用和高可信的渴求,近日引入应用MHA架构,因为MySQL GP还不能够在生育应用,可是相信之后逐年就能够被用到生育遭遇的。

Preface

一、简介

读书贰个高可用小软件,不但要掌握其效果,还要理解其框架结构及职业规律。

MHA才具介绍

MHA(Master High Availability)这段日子在MySQL高可用方面是一个对峙成熟的化解方案,它由日本DeNA集团youshimaton(现就职于Instagram公司)开荒,是壹套精美的当作MySQL高可用性情状下故障切换和大旨进步的高可用软件。在MySQL故障切换进程中,MHA能成就在0~30秒之内自动完毕数据库的故障切换操作,并且在进展故障切换的进度中,MHA能在最大程度上保障数据的一致性,以达成确实意义上的高可用。除了failover之外,MHA还协理在线master切换,特别安全和火速,大概只需求(0.伍 ~ 二秒)的围堵写时间。

该软件由两片段构成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager能够独立布置在一台独立的机器上管理多个master-slave集群,也得以安排在一台slave节点上。MHA Node运营在每台MySQL服务器上,MHA Manager会定期探测集群中的master节点,当master出现故障时,它能够活动将新型数据的slave升高为新的master,然后将具有其余的slave重新指向新的master。整个故障转移进度对应用程序完全透明。

日前MHA首要支撑一主多从的架构,要搭建MHA,要求3个复制集群中务必至少有三台数据库服务器,1主二从,即一台充当master,1台充当备用master,此外一台充当slave。当然,如果你处于资金怀想,也得以选用五个节点的MHA,1主1从(实地衡量过的)。

小结一下,MHA提供了如下效果:

(一)master自动监察和控制,故障转移1体化(Automated master monitoring and failover)

(贰)MHA能够在一个复制组中监督master的景况,如果挂了,就足以活动的做failover。

(三)MHA通过具有slave的差别relay-log来保险数据的一致性。

(肆)MHA在做故障转移,日志补偿这几个动作的时候,平时只须求10~30秒。

(5)平日情状下,MHA会选取新型的slave作为new master,不过你也得以钦点哪些是候选maser,那么新master公投的时候,就从那几个host里面挑。

(陆)导致复制情况中断的一致性难题,在MHA中是不会发生的,请放心使用。

在MHA自动故障切换进程中,MHA试图从宕机的主服务器上保存2进制日志,最大程度的保险数据的不丢掉,但那并不总是实惠的。比方,若是主服务器硬件故障或不能够透过ssh访问,MHA没法保存二进制日志,只实行故障转移而不见了前卫的多少。使用MySQL 伍.五及以上版本的半联合复制,能够大大下降数据丢失的风险。MHA能够与半联合实行复制结合起来。借使唯有3个slave已经收取了新式的二进制日志,MHA能够将最新的二进制日志应用于其余兼具的slave服务器上,由此能够保障全体节点的多少壹致性。

(七)手工业-交互式master故障转移(Interactive manually initiated Master Failover)

MHA能够配备成手工业-交互式方式举行故障转移,不辅助监督master的境况。

(捌)非交互式master故障转移 (Non-interactive master failover)

非交互式,自动的故障转移,不提供监督master状态功用,监察和控制能够付出其余零件做(如:Pacemaker heartbeat)。

(9)在线master切换 (Online switching master to a different host)

借让你有更加快,越来越好的master,安顿要将老master替换来新的master,那么这一个意义特别符合那样的景观。

那不是master真的挂掉了,只是我们有大多须要要开始展览master例行维护。

MHA的优点

  1. master failover和slave promotion非常便捷。

二. 自行探测,多种检查实验,切换进度中支持调用其余脚本的接口。

  1. master crash不会招致数据分裂样,自动补齐数据,维护数据一致性。

  2. 没有要求修改复制的其他设置,轻巧易陈设,对现存架构无影响。

  3. 不必要扩充大多13分的机器来配置MHA,援助多实例聚集管理。

  4. 不曾其余性质影响。

  5. 支撑在线切换。

  6. 跨存储引擎,协助任何引擎。

合法介绍:https://code.google.com/p/mysql-master-ha

 

1. 架构

从架构上来讲,MHA分为如下两大片段:

(1) Node

我们了然,MHA是依靠MySQL Replication景况的,在该情况中,不管是Master剧中人物,照旧Slave角色,都可以称作Node,是被监察和控制管理的对象节点。

Node服务器上急需设置MHA Node包。

(2) Manager

Manager为MHA架构中的处理者,提议铺排在一台独立的服务器上,当然也可安插在有个别Slave上,但该Slave恒久不要被挑选成为新的Master,不然故障切换后的MHA架构就失去了高可用性。

Manager服务器须求安装MHA Manager包,并完善2个主配置文件。

1个Manager可管理多套MySQL Replication情形。

MHA专门的学问流程

下图突显了哪些通过MHA Manager管理多组主从复制,能够将MHA职业原理计算为如下:

图片 3

壹、MHA如何监督master和故障转移?

一.一 验证复制设置以及确认当前master状态

老是全数hosts,MHA自动来确认当前master是哪些,配置文件中不必要点名哪个是master。

借使内部有其余1个slave挂了,脚本立时退出,结束监察和控制。

即使有1部分至关重要的剧本未有在MHA Node节点安装,那么MHA在这几个阶段终止,且结束监察和控制。

1.2 监控master

监控master,直到master挂了。

其壹阶段,MHA不会监察和控制slave,Stopping/Restarting/Adding/Removing操作在slave上,不会影响当下的MHA监察和控制进度。当您加多大概去除slave的时候,请更新好布局文件,最棒重启MHA。

壹.3 检验master是或不是失利

假设MHA Manger1回间隔时间都无法连接master server,就能够进去这一个阶段。

倘使您设置了secondary_check_script ,那么MHA会调用脚本做二遍检测来判别master是不是是真的挂了。

接下去的步子,便是masterha_master_switch的劳作流程了。

1.肆 双重验证slave的布局

倘若发掘其余违规的复制配置(有个别slave的master不是同三个),那么MHA会截止监察和控制,且报错。能够安装ignore_fail忽略。

这一步是地处安全着想,很有比非常的大只怕,复制的配备文件已经被改掉了,所以double check是比较推荐的做法。

自己批评最后一回failover(故障转移)的意况

只要上三回的failover报错,恐怕上壹遍的failover停止的太近(暗中同意三天),MHA结束监察和控制,甘休failover,那么在masterha_manager命令中装置ignore_last_failover,wait_on_failover_error来退换那1检查实验。这么做,也是由于安全着想。频仍的failover,检查下是还是不是网络出难点,大概其余错误吧?

一.5 关掉失败的master的服务器(可选)

一经在配置文件中定义了master_ip_failover_script and/or shutdown_script ,MHA会调用那么些的脚本。

闭馆dead master,幸免脑裂(值得提道)。

一.陆 恢复生机一台新master

从crashed master服务器上保存binlog到Manager(要是能够的话

若是dead master可以SSH的话,拷贝binary logs从最新的slave上的end_log_pos(Read_Master_Log_Pos)地点上马拷贝。

选举新master

一般依据配置文件的装置来调整选出何人,借使想设置有些候选master,设置candidate_master=一;若是想设置有个别host,长久都不会选出,设置no_master=一;确认最新的slave (那台slave拥有新型的relay-log)。

平复和晋升新master

依据老master binlog生成差距日志,应用日志到new master,假设这一步发生错误(如:duplicate key error),MHA截至恢复生机,并且别的的slave也停下苏醒。

2)MHA怎么着在线火速切换master?

上面包车型客车手续,正是masterha_master_switch—master_state=alive做的事体。

二.一 验证复制设置以及确认当前master状态

连天配置文件中列出的具备hosts,MHA自动来确认当前master是哪位,配置文件中不必要点名哪个是master。

施行 flush tables 命令在master上(可选). 那样能够缩小FLUSH TABLES WITH READ LOCK的时光。

既不监察和控制master,也不会failover。

反省下边包车型地铁口径是还是不是满意。

A. IO线程是或不是在全体slave上都以running。

B. SQL线程是不是在享有slave上都以running。

C. Seconds_Behind_Master 是不是低于二秒(—running_updates_limit=N)。

D. master上是或不是未有长的换代语句大于二秒。

2.2 确认新master

新master要求安装: –new_master_host参数。

本来的master和新的master必须求有雷同的复制过滤条件(binlog-do-db and binlog-ignore-db)。

2.3 当前master停写

假设您在布局中定义了master_ip_online_change_script,MHA会调用它。能够透过安装SET GLOBAL read_only=一来周到的拦截写入。

在老master上实践FLUSH TABLES WITH READ LOCK来阻拦全数的写(–skip_lock_all_tables能够忽略这一步)。

二.肆 等候别的slave追上如今master,同步无延迟

调用那一个函数MASTE翼虎_LOG_POS()。

2.5 确保新master可写

进行SHOW MASTE揽胜 STATUS来明确新master的binary log文件名和position。

如果设置了master_ip_online_change_script,会调用它。能够创制写权限的用户,SET GLOBAL read_only=0。

2.6 让其他slave指向新master

并行试行CHANGE MASTECR-V, START SLAVE。

    I've installed MasterHA yesterday,Now let's test the master-slave switch and failover feature.

二. 职业规律

相较于任何HA软件,MHA的意在保证MySQL Replication中Master库的高可用性,其最大特征是能够修复四个Slave之间的异样日志,最终使全数Slave保持数据一致,然后从中选拔1个充当新的Master,并将其他Slave指向它。

主导职业流程大约如下:

(一) Manager按期监察和控制Master,监控时间间隔由参数ping_interval决定,缺省为3分钟3回;可使用其自身的监督作用,也可调用第一方软件来监督;MHA自己提供了二种监察和控制措施:SELECT(实行SELECT 1)和CONNECT(创立连接/断开连接),由于参数ping_type决定,缺省为SELECT方式。

(2) 当监测到Master故障时,调用SSH脚本对富有Node实行一遍检查,包罗如下多少个地点:

――MySQL实例是或不是足以连接;

――Master服务器是还是不是足以SSH连通;

――检查SQL Thread的状态;

――检查哪些Server死掉了,哪些Server是活动的,以及活动的Slave实例;

MySQL基于MHA高可用理论篇,MySQL高可用之MHA切换测试。――检查Slave实例的布署及复制过滤规则;

――最终退出监察和控制脚本并回到代表特殊含义代码。

(三) 初始Master故障切换,包括如下多少个子阶段:

――Phase 1: Configuration Check Phase

在这么些阶段,若有个别Slave实例的SQL Thread结束了,则会活动运行它;并再度肯定活动的Servers及Slaves。

――Phase 2: Dead Master Shutdown Phase

在这些等第,首先调用master_ip_failover_script,若HA是依赖VIP实现的,则关闭VIP,即使基于目录数据库达成的,则修改映射记录。

接下来调用shutdown_script脚本强制关闭主机,以幸免服务重启时,发生脑裂。

――Phase 3: Master Recovery Phase

又包涵如下二个子阶段:

Phase 3.1: Getting Latest Slaves Phase

反省各样Slave,获取这段日子的和最旧的binary log file和position,并检讨种种Slave成为Master的优先级,依赖于candidate_master、no_master、[server_xxx]梯次、binary log差别量等成分。

Phase 3.2: Saving Dead Master's Binlog Phase

若dead master所在服务器依旧得以因此SSH连通,则提取dead master的binary log,提取日志的起源就是上一步获取的最新的binary log file和position,直到最终一条事件日志,并在dead master本地的职业目录(由参数remote_workdir决定)中开创文件保留那么些提取到的日记,然后将该文件拷贝到Manager服务器的专门的学问目录下(由参数manager_workdir决定)。

理当如此,若dead master系统就无法连接,也就不存在差其余binary log了。

其余,MHA还要对种种Slave节点实行健检,首倘诺SSH连通性。

Phase 3.3: Determining New Master Phase

接下去调用apply_diff_relay_logs命令复苏Slave的差异日志,那么些差别日志指的是各类Slave之间的relay log。

平复达成后,全体的Slave数据是一致的,此时就足以依据优先级选拔New Master了。

Phase 3.3: New Master Diff Log Generation Phase

此地是生成dead master和new master之间的差别日志,将在Phase 三.二封存的binary log拷贝到New Master的劳作目录中(remote_workdir)。

Phase 3.4: Master Log Apply Phase

将上一步拷贝的出入日志复苏到New Master上,若发生错误,也可手动复苏。

下一场拿走New Master的binlog name和position,以便别的Slave从那一个新的binlog name和position初阶复制。

最后会敞开New Master的写权限,就要read_only参数设置为0。

――Phase 4: Slaves Recovery Phase

Phase 4.1: Starting Parallel Slave Diff Log Generation Phase

生成Slave与New Slave之间的差别日志,并将该日志拷贝到各Slave的劳作目录下,那有个别日志dead master和new master之间差别的这有个别日志,因为各类Slave在Phase 叁.三等第已经一齐了。

Phase 4.2: Starting Parallel Slave Log Apply Phase

在逐1Slave上利用这1部分差距日志,然后经过CHANGE MASTER TO命令将这么些Slave指向新的New Master,最后初叶复制(start slave)。

――Phase 5: New master cleanup phase

理清New Master其实正是复位slave info,即打消原来的Slave消息。

由来整个Master故障切换进程连成一气。

MHA组件介绍

MHA软件由两部分组成,Manager工具包和Node工具包,具体的表明如下。

Manager工具包主要包蕴以下多少个工具:

(1)masterha_check_ssh    #自己商议MHA的SSH配置处境;

(2)masterha_check_repl    #反省MySQL复制场景;

(3)masterha_manger    #启动MHA;

(4)masterha_check_status  #检验当前MHA运市价况;

(5)masterha_master_monitor  #检验master是不是宕机;

(6)masterha_master_switch    #决定故障转移(自动恐怕手动);

(7)masterha_conf_host    #丰硕或删除配置的server音讯;

Node工具包(那么些工具通常由MHA Manager的本子触发,没有供给人工操作)首要不外乎以下多少个工具:

(1)save_binary_logs      #保留和复制master的贰进制日志;

(2)apply_diff_relay_logs  #识别差别的衔接日志事件并将其距离的事件选取于其余的slave;

(3)purge_relay_logs      #铲除中继日志(不会阻塞SQL线程);

注意:为了尽只怕的滑坡主库硬件损坏宕机产生的数目丢失,因而在布置MHA的还要建议配置成MySQL半一齐复制。关于半一起复制原理各位自个儿开始展览查看(不是必须)。

转自:

 

3. 功能

从官网的介绍来看,MHA具备如下多少个功效:

(一) Master自动监察和控制和故障转移

基于现存的MySQL主从复制情形,MHA能够监察和控制Master,当发掘其故障时,自动实行切换。

在八个Slave情形中,如果个别Slave未有收受到新型的relay log events,MHA则会自行从新型的极度Slave上搜索差异的relay log events,并将这个出入事件选择到有延迟的Slave上,最后维持全体的Slave数据一致。平常状态下,MHA可在九-1二秒内监测到Master故障,7-10秒内关闭主机以幸免脑裂,然后费用几秒时间使用差距的relay log,整个进程一般只需10-30秒就能够产生。

既然MHA能够自动修复四个Slaves之间的距离日志,所以并非操心数据一致性难题。当Master故障时,MHA会从三个Slave中自由选用八个担任新的Master;当然,也可在布置文件中钦赐某二个Slave优先成为Master。

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

能够只行使MHA的故障转移职能,而不监察和控制Master,当其故障时,手动调用MHA来张开故障切换。

(三)非交互式自动故障转移

MHA还支持非交互式的Master故障切换(不监察和控制Master,但落到实处机关故障切换),那么些特点其实是将Master的督察和VIP接管交给第二方工具来做,譬喻Heartbeat,MHA只担任Master故障转移和Slave之间的数额同步。

(四) 在线切换Master到区别的主机

在稍微景况下,举个例子退换Raid调节器,晋级主机硬件等,则必要将其上的Master实例迁移到别的主机上,MHA扶助高速的Master切换和局促的写操作阻塞,日常只需0.五-二秒的downtime,那是足以承受的,也利于了DBA的操作。

Framework

二、搭建意况

系统意况

OS:CentOS 5.8 (x86_64) 内核:2.6.18-308.el5 DB:MySQL 5.5.17

hostname IP MySQL Role MHA Role

node1 192.168.3.27 master node
node2 192.168.3.28 slave1 (备用) node
node3 192.168.3.25 slave2 node
mmm 192.168.3.26 manager

 

1.安装MHA

MHA的安装包也囊括Manager和Node两片段,其中Node包不但要在有着的Node节点上安装,而且还需在Manager节点上设置,因为Manager模块内部正视Node模块,
Manager包则只需在Manager节点安装就能够。
从MHA官网
Manager包:mha4mysql-manager-0.55-1.el5.noarch.rpm
Node包:mha4mysql-node-0.54-1.el5.noarch.rpm

MHA是运用perl语言编写的一个剧本管理工科具,所以要求安装1多元perl倚重包。

1、在颇具节点上安装perl语言信赖包
# rpm -ivh MySQL-shared-compat-5.5.17-1.rhel5.x86_64.rpm
# rpm -ivh perl-DBI-1.52-2.el5.x86_64.rpm
# rpm -ivh perl-DBD-MySQL-3.0007-2.el5.x86_64.rpm

(以下正视包为Manager节点必要)
# rpm -ivh perl-Params-Validate-0.95-1.el5.rf.x86_64.rpm
# rpm -ivh perl-Log-Dispatch-2.26-1.el5.rf.noarch.rpm
# rpm -ivh perl-Config-Tiny-2.12-1.el5.rf.noarch.rpm
# rpm -ivh perl-Parallel-ForkManager-0.7.5-2.2.el5.rf.noarch.rpm

在富有节点及manager上设置node包
# rpm -ivh mha4mysql-node-0.54-1.el5.noarch.rpm

在manager节点上设置manager包
# rpm -ivh mha4mysql-manager-0.55-1.el5.noarch.rpm

水到渠成安装后,会在/usr/bin目录下转移如下一名目繁多命令工具:
/usr/bin/masterha_check_repl
/usr/bin/masterha_conf_host
/usr/bin/masterha_master_switch
/usr/bin/masterha_check_ssh
/usr/bin/masterha_manager
/usr/bin/masterha_secondary_check
/usr/bin/masterha_check_status
/usr/bin/masterha_master_monitor
/usr/bin/masterha_stop

Hostname IP Port Identity OS Version MySQL Version
zlm2 192.168.1.101 3306 master CentOS 7.0 5.7.21
zlm3 192.168.1.102 3306 slave/mha-manager CentOS 7.0 5.7.21
null 192.168.1.200 null vip null null

2.配置MHA

接下去就足以布置MHA配置文件了,只需在Manager服务器上操作;RPM包安装时,缺省不会转移该配置文件,可手动生成,也可从MHA Manager源码安装包中找寻配置文件模板,及1密密麻麻调用脚本。

创制专门的学问目录
在Node上创设三个单独的工作目录,用于remote_workdir参数来存放相关日志文件,缺省为/var/tmp,若未创制,MHA也会自行创制,但这亟需有开创权限。
# mkdir -p /mha/appl
在Manager上创办职业目录,用于manager_workdir参数,个中存放日志文件和一层层脚本文件等。
# mkdir -p /mha/appl
# mkdir -p /mha/scripts

配置masterha_default.cnf文件
那是全局配置文件,缺省为/etc/masterha_default.cnf,适用于2个Manager管理多套MySQL Replication的情形,在[server_default]下定义一些多套复制碰着通用的Global Scope类型的参数。本例唯有一套MySQL Replication,所以也可不用配置该公文,而是在对应的运用配置文件(appl.conf)下的[server_default]中定义相关参数。
施行MHA相关命令时,会在/etc目录下搜索该配置文件,若找不到,纵然不会有何错误,但会交到三个告诫,如“[warning] Global configuration file /etc/masterha_default.cnf not found.”。
为此能够在/etc目录下创建八个名称叫masterha_default.cnf的空文件,本例不准备这么做,而是在中间布置部分通用的[server_default]类参数,如下:

# vi /etc/masterha_default.cnf
[server default]
user = root
password = mysql --mysql密码
ssh_user = root
repl_user = repl
repl_password = repl_pwd
ping_interval = 3
ping_type = SELECT

配置appl.conf文件
那是针对性每一套MySQL Replication应用特别的布局文件,若管理多套MySQL Replication,可配备多少个公文,当中包涵[server_default]和[server_xxx]五个项目,分别用于配置App Scope、Local Scope类型的参数。
# vi /etc/appl.cnf

[server default]
manager_workdir = /mha/appl
manager_log = /mha/appl/manager.log
remote_workdir = /mha/appl

#master_ip_failover_script=/mha/scripts/master_ip_failover

[server1]
hostname = 192.168.3.27
master_binlog_dir = /data/lib/mysql
candidate_master = 1

[server2]
hostname = 192.168.3.28
master_binlog_dir = /data/lib/mysql
candidate_master =1

[server3]
hostname = 192.168.3.25
no_master = 1

Procedure

3.布署SSH等效连接

因为MHA管理节点以及各种Node节点之间要求无密码登6并举行相关脚本,所以供给配备各样节点之间的SSH等效性,如下:
――生成密钥文件(各类节点均需实行)

# mkdir -p ~/.ssh
# cd .ssh
# /usr/bin/ssh-keygen -t rsa (提醒处直接回车就可以)
# /usr/bin/ssh-keygen -t dsa (提醒处直接回车就能够)
进行到位后,在/root/.ssh 目录下会生产八个密钥文件。

――任性3个节点实施就可以(本例选取在manager节点施行)

# ssh 192.168.3.27 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.27 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.28 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.28 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.25 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.25 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.26 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
# ssh 192.168.3.26 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
# scp ~/.ssh/authorized_keys 192.168.3.27:.ssh/
# scp ~/.ssh/authorized_keys 192.168.3.28:.ssh/
# scp ~/.ssh/authorized_keys 192.168.3.25:.ssh/

――修改authorized_keys文件的权力为600(全部节点均需实行)
# chmod 600 ~/.ssh/authorized_keys

――测试一下
在各节点实施如下命令,测试一下,看是还是不是不晋升密码就可以展现,不可是注解SSH配置不成事。
# ssh 192.168.3.26 hostname
# ssh 192.168.3.26 date

其余,还可利用MHA提供的工具命令来检查,如下:
[[email protected] .ssh]# /usr/bin/masterha_check_ssh --conf=/etc/appl.cnf
Fri Jul 18 16:52:12 2014 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Fri Jul 18 16:52:12 2014 - [info] Reading application default configurations from /etc/appl.cnf..
Fri Jul 18 16:52:12 2014 - [info] Reading server configurations from /etc/appl.cnf..
Fri Jul 18 16:52:12 2014 - [info] Starting SSH connection tests..
Fri Jul 18 16:52:13 2014 - [debug]
Fri Jul 18 16:52:12 2014 - [debug] Connecting via SSH from [email protected](192.168.3.27:22) to [email protected](192.168.3.28:22)..
Fri Jul 18 16:52:12 2014 - [debug] ok.
Fri Jul 18 16:52:12 2014 - [debug] Connecting via SSH from [email protected](192.168.3.27:22) to [email protected](192.168.3.25:22)..
Fri Jul 18 16:52:12 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug]
Fri Jul 18 16:52:12 2014 - [debug] Connecting via SSH from [email protected](192.168.3.28:22) to [email protected](192.168.3.27:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug] Connecting via SSH from [email protected](192.168.3.28:22) to [email protected](192.168.3.25:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug]
Fri Jul 18 16:52:13 2014 - [debug] Connecting via SSH from [email protected](192.168.3.25:22) to [email protected](192.168.3.27:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [debug] Connecting via SSH from [email protected](192.168.3.25:22) to [email protected](192.168.3.28:22)..
Fri Jul 18 16:52:13 2014 - [debug] ok.
Fri Jul 18 16:52:13 2014 - [info] All SSH connection tests passed successfully.

从中能够见见,该命令会从利用配置文件中读取相关音讯(IP和SSH_USELacrosse),然后在壹一Node之间相互验证,保障能够通过SSH方式相互登入(用于共同差距日志)。

 

4.配置hosts解析

这一步的指标是在hostname和ip之间提供3个解析门路,配置方式很简短,正是将逐壹节点的主机名及对应的IP地址写入/etc/hosts文件,全体节点均需配置,且保持一致,如下:
# vi /etc/hosts
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.3.27 node1
192.168.3.28 node2
192.168.3.25 node3
192.168.3.26 mmm
为了方便,在三个节点配置,然后拷贝到其它节点就能够;配置达成后,能够相互ping一下主机名,看能还是不可能成功深入分析。

Test 1:Manual master switchover

5.搭建MySQL主从复制

遵照规划,在node壹、node二、node3上设置MySQL数据库,并搭建成一主二从的MySQL Replication结构;具体操作不做验证了,可参照他事他说加以考查 对于MHA来讲,搭建MySQL Replication须要小心以下几点:
 read_only――是还是不是限制Slave实例为只读状态,缺省为0,即不限制,MHA供给安装为一。
 relay_log_purge――那么些参数用于限制中继日志应用完事后是还是不是删除,缺省为1,即利用完现在立时删除;在MHA中,Manager就是通过那个日记来一头各类Slave之间的数量差别的,所以必须设置为0,即不删除中继日志。
 log_bin――是不是展开二进制日志,若有个别Slave也许被增选成为新的Master,则必须开启;若某些Slave被限定长久不会产生新的Master,能够绝不开启。

打响搭建后,通过MHA命令检查一下,确定保障准确。

[[email protected] scripts]# /usr/bin/masterha_check_repl --conf=/etc/appl.cnf
Mon Jul 21 10:40:12 2014 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Mon Jul 21 10:40:12 2014 - [info] Reading application default configurations from /etc/appl.cnf..
Mon Jul 21 10:40:12 2014 - [info] Reading server configurations from /etc/appl.cnf..
Mon Jul 21 10:40:12 2014 - [info] MHA::MasterMonitor version 0.55.
Mon Jul 21 10:40:12 2014 - [info] Dead Servers:
Mon Jul 21 10:40:12 2014 - [info] Alive Servers:
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.28(192.168.3.28:3306)
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.25(192.168.3.25:3306)
Mon Jul 21 10:40:12 2014 - [info] Alive Slaves:
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.28(192.168.3.28:3306) Version=5.5.17-log (oldest major version between slaves) log-bin:enabled
Mon Jul 21 10:40:12 2014 - [info] Replicating from 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] Primary candidate for the new Master (candidate_master is set)
Mon Jul 21 10:40:12 2014 - [info] 192.168.3.25(192.168.3.25:3306) Version=5.5.17 (oldest major version between slaves) log-bin:disabled
Mon Jul 21 10:40:12 2014 - [info] Replicating from 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] Not candidate for the new Master (no_master is set)
Mon Jul 21 10:40:12 2014 - [info] Current Alive Master: 192.168.3.27(192.168.3.27:3306)
Mon Jul 21 10:40:12 2014 - [info] Checking slave configurations..
Mon Jul 21 10:40:12 2014 - [warning] relay_log_purge=0 is not set on slave 192.168.3.28(192.168.3.28:3306).
Mon Jul 21 10:40:12 2014 - [warning] log-bin is not set on slave 192.168.3.25(192.168.3.25:3306). This host can not be a master.
Mon Jul 21 10:40:12 2014 - [info] Checking replication filtering settings..
Mon Jul 21 10:40:12 2014 - [info] binlog_do_db= , binlog_ignore_db=
Mon Jul 21 10:40:12 2014 - [info] Replication filtering check ok.
Mon Jul 21 10:40:12 2014 - [info] Starting SSH connection tests..
Mon Jul 21 10:40:13 2014 - [info] All SSH connection tests passed successfully.
Mon Jul 21 10:40:13 2014 - [info] Checking MHA Node version..
Mon Jul 21 10:40:14 2014 - [info] Version check ok.
Mon Jul 21 10:40:14 2014 - [info] Checking SSH publickey authentication settings on the current master..
Mon Jul 21 10:40:14 2014 - [info] HealthCheck: SSH to 192.168.3.27 is reachable.
Mon Jul 21 10:40:14 2014 - [info] Master MHA Node version is 0.54.
Mon Jul 21 10:40:14 2014 - [info] Checking recovery script configurations on the current master..
Mon Jul 21 10:40:14 2014 - [info] Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data/lib/mysql --output_file=/mha/appl/save_binary_logs_test --manager_version=0.55 --start_file=mysql-bin.000004
Mon Jul 21 10:40:14 2014 - [info] Connecting to [email protected](192.168.3.27)..
Creating /mha/appl if not exists.. ok.
Checking output directory is accessible or not..
ok.
Binlog found at /data/lib/mysql, up to mysql-bin.000004
Mon Jul 21 10:40:14 2014 - [info] Master setting check done.
Mon Jul 21 10:40:14 2014 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Mon Jul 21 10:40:14 2014 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='root' --slave_host=192.168.3.28 --slave_ip=192.168.3.28 --slave_port=3306 --workdir=/mha/appl --target_version=5.5.17-log --manager_version=0.55 --relay_log_info=/data/lib/mysql/relay-log.info --relay_dir=/data/lib/mysql/ --slave_pass=xxx
Mon Jul 21 10:40:14 2014 - [info] Connecting to [email protected](192.168.3.28:22)..
Checking slave recovery environment settings..
Opening /data/lib/mysql/relay-log.info ... ok.
Relay log found at /data/lib/mysql, up to mysql-relay-bin.000006
Temporary relay log file is /data/lib/mysql/mysql-relay-bin.000006
Testing mysql connection and privileges.. done.
Testing mysqlbinlog output.. done.
js5011799com登录 ,Cleaning up test file(s).. done.
Mon Jul 21 10:40:14 2014 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='root' --slave_host=192.168.3.25 --slave_ip=192.168.3.25 --slave_port=3306 --workdir=/mha/appl --target_version=5.5.17 --manager_version=0.55 --relay_log_info=/data/lib/mysql/relay-log.info --relay_dir=/data/lib/mysql/ --slave_pass=xxx
Mon Jul 21 10:40:14 2014 - [info] Connecting to [email protected](192.168.3.25:22)..
Creating directory /mha/appl.. done.
Checking slave recovery environment settings..
Opening /data/lib/mysql/relay-log.info ... ok.
Relay log found at /data/lib/mysql, up to mysql-relay-bin.000008
Temporary relay log file is /data/lib/mysql/mysql-relay-bin.000008
Testing mysql connection and privileges.. done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Mon Jul 21 10:40:15 2014 - [info] Slaves settings check done.
Mon Jul 21 10:40:15 2014 - [info]
192.168.3.27 (current master)
--192.168.3.28
--192.168.3.25

Mon Jul 21 10:40:15 2014 - [info] Checking replication health on 192.168.3.28..
Mon Jul 21 10:40:15 2014 - [info] ok.
Mon Jul 21 10:40:15 2014 - [info] Checking replication health on 192.168.3.25..
Mon Jul 21 10:40:15 2014 - [info] ok.
Mon Jul 21 10:40:15 2014 - [warning] master_ip_failover_script is not defined.
Mon Jul 21 10:40:15 2014 - [warning] shutdown_script is not defined.
Mon Jul 21 10:40:15 2014 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

注:借使有荒唐,根据检查的不当提醒,举行相应的改变设置()。

从中能够见见,该命令首先从主配置文件和选取配置文件中读取相关参数,然后检查各种Slave的情景、参数配置、SSH连通性、施行save_binary_logs、apply_diff_relay_logs命令等操作,确认保证末了的唤起为“MySQL Replication Health is OK”,不然须要再行检讨MySQL Replication配置。
除此以外,在那之中交付了三个警示,提醒未有定义master_ip_failover_script、shutdown_script,那几个暂时不论,在背后环节再详尽表达。

 

三、测试

因而地点一雨后春笋步骤,成功搭建及安插了MHA,上边我们就来大致试用一下,并开始展览一下成效测试。

Check state of MHA-manager on zlm3.

1.命令工具

MHA提供的指令工具包涵Manager工具和Node工具,简要介绍如下:
Manager工具
/usr/bin/masterha_check_repl ――检查MySQL Replication是还是不是正规;
/usr/bin/masterha_conf_host ――增多或删除配置的Server音信;
/usr/bin/masterha_master_switch ――用于手动Master切换;
/usr/bin/masterha_check_ssh ――检查种种Node之间SSH登入是或不是正规;
/usr/bin/masterha_manager ――开启MHA
/usr/bin/masterha_secondary_check ――检查多路由陈设;
/usr/bin/masterha_check_status ――检查MHA是不是开启并寻常运转;
/usr/bin/masterha_master_monitor ――手动开启监察和控制,运行MHA时会自动运维监察和控制
/usr/bin/masterha_stop ――关闭MHA
Node工具
/usr/bin/save_binary_logs ――保存和复制master的2进制日志;
/usr/bin/apply_diff_relay_logs ――识别差别的交接日志事件并应用于别的Slave;
/usr/bin/filter_mysqlbinlog ――去除不须求的Rollback事件(MHA已不复利用该工具);
/usr/bin/purge_relay_logs ――清除中继日志(不会堵塞SQL线程);
备考:Node端工具平常由MHA Manager的本子触发调用,无需DBA操作。

本文由bwin必赢发布,转载请注明来源

关键词: 数据库技术 MySQL 高可用 必赢棋