MySQL高可用系列之MHA(一)

MHA · ruyi · 于 5个月前发布 · 405 次阅读

MHA,即Master High Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQL Replication(二层)环境,目的在于维持Master主库的高可用性。

一、简介

            本文将带大家学习一个高可用软件MHA,不但要熟悉其功能,还要了解其架构及工作原理。

1.  架构

从架构上来说,MHA分为如下两大部分:

(1) Node

          我们知道,MHA是基于MySQL Replication环境的,在该环境中,不管是Master角色,还是Slave角色,都称为Node,是被监控管理的对象节点。

Node服务器上需要安装MHA Node包。

(2) Manager

Manager为MHA架构中的管理者,建议部署在一台独立的服务器上,当然也可部署在某个Slave上,但该Slave永远不要被选择成为新的Master,否则故障切换后的MHA架构就失去了高可用性。

Manager服务器需要安装MHA Manager包,并完善一个主配置文件。

一个Manager可管理多套MySQL Replication环境。

2.  工作原理

        相较于其它HA软件,MHA的目的在于维持MySQL Replication中Master库的高可用性,其最大特点是可以修复多个Slave之间的差异日志,最终使所有Slave保持数据一致,然后从中选择一个充当新的Master,并将其它Slave指向它。

基本工作流程大致如下:

(1) Manager定期监控Master,监控时间间隔由参数ping_interval决定,缺省为3秒钟一次;可利用其自身的监控功能,也可调用第三方软件来监控;MHA自身提供了两种监控方式:SELECT(执行SELECT 1)和CONNECT(创建连接/断开连接),由于参数ping_type决定,缺省为SELECT方式。

(2) 当监测到Master故障时,调用SSH脚本对所有Node执行一次检查,包括如下几个方面:

――MySQL实例是否可以连接;

――Master服务器是否可以SSH连通;

――检查SQL Thread的状态;

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

――检查Slave实例的配置及复制过滤规则;

――最后退出监控脚本并返回代表特殊意义代码。

(3) 开始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

又包括如下3个子阶段:

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 3.2保存的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 3.3阶段已经同步了。

Phase 4.2: Starting Parallel Slave Log Apply Phase

在各个Slave上应用这部分差异日志,然后通过CHANGE MASTER TO命令将这些Slave指向新的New Master,最后开始复制(start slave)。

――Phase 5: New master cleanup phase

清理New Master其实就是重置slave info,即取消原来的Slave信息。

至此整个Master故障切换过程完成。

3.  功能

从官方网站的介绍来看,MHA具有如下几个功能:

(1) Master自动监控和故障转移

           基于现有的MySQL主从复制环境,MHA可以监控Master,当发现其故障时,自动进行切换。

           在多个Slave环境中,如果个别Slave没有接受到最新的relay log events,MHA则会自动从最新的那个Slave上查找差异的relay log events,并将这些差异事件应用到有延迟的Slave上,最终保持所有的Slave数据一致。通常情况下,MHA可在9-12秒内监测到Master故障,7-10秒内关闭主机以避免脑裂,然后花费几秒时间应用差异的relay log,整个过程通常只需10-30秒即可完成。

        既然MHA可以自动修复多个Slaves之间的差异日志,所以不用担心数据一致性问题。当Master故障时,MHA会从多个Slave中随机选择一个充当新的Master;当然,也可在配置文件中指定某一个Slave优先成为Master。

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

           可以只使用MHA的故障转移功能,而不监控Master,当其故障时,手动调用MHA来进行故障切换。

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

          MHA还支持非交互式的Master故障切换(不监控Master,但实现自动故障切换),这个特性其实是将Master的监控和VIP接管交给第三方工具来做,比如Heartbeat,MHA只负责Master故障转移和Slave之间的数据同步。

(4) 在线切换Master到不同的主机

           在有些情况下,比如更换Raid控制器,升级主机硬件等,则需要将其上的Master实例迁移到其它主机上,MHA支持快速的Master切换和短暂的写操作阻塞,通常只需0.5-2秒的downtime,这是可以接受的,也方便了DBA的操作。

二、搭建环境

系统环境

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官网http://code.google.com/p/mysql-master-ha/downloads/list下载合适的安装包,可以是源码包,也可以是RPM包,本例采用RPM包,如下:
Manager包:mha4mysql-manager-0.55-1.el5.noarch.rpm
Node包:mha4mysql-node-0.54-1.el5.noarch.rpm

MHA是采用perl语言编写的一个脚本管理工具,所以需要安装一系列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

2.配置MHA

       接下来就可以配置MHA配置文件了,只需在Manager服务器上操作;RPM包安装时,缺省不会生成该配置文件,可手动生成,也可从MHA Manager源码安装包中查找配置文件模板,及一系列调用脚本。

创建工作目录
在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,适用于一个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

3.配置SSH等效连接

         因为MHA管理节点以及各个Node节点之间需要无密码登录并执行相关脚本,所以需要配置各个节点之间的SSH等效性,如下:
――生成密钥文件(各个节点均需执行)

# mkdir -p ~/.ssh      
# cd .ssh
# /usr/bin/ssh-keygen -t rsa (提示处直接回车即可)
# /usr/bin/ssh-keygen -t dsa (提示处直接回车即可)
执行完成后,在/root/.ssh 目录下会生产四个密钥文件。

――任意一个节点执行即可(本例选择在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提供的工具命令来检查,如下:
[root@mmm .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 root@192.168.3.27(192.168.3.27:22) toroot@192.168.3.28(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 root@192.168.3.27(192.168.3.27:22) toroot@192.168.3.25(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 root@192.168.3.28(192.168.3.28:22) toroot@192.168.3.27(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 root@192.168.3.28(192.168.3.28:22) toroot@192.168.3.25(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 root@192.168.3.25(192.168.3.25:22) toroot@192.168.3.27(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 root@192.168.3.25(192.168.3.25:22) toroot@192.168.3.28(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_USER),然后在各个Node之间相互验证,保证可以通过SSH方式相互登录(用于同步差异日志)。 

4.配置hosts解析

         这一步的目的是在hostname和ip之间提供一个解析途径,配置方法很简单,就是将各个节点的主机名及对应的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一下主机名,看能否成功解析。


5.搭建MySQL主从复制

        按照规划,在node1、node2、node3上安装MySQL数据库,并搭建成一主二从的MySQL Replication结构;具体操作不做说明了,可参考http://blog.csdn.net/dbaxiaosa/article/details/22421969  对于MHA来说,搭建MySQL Replication需要注意以下几点:
 read_only――是否限制Slave实例为只读状态,缺省为0,即不限制,MHA要求设置为1。
 relay_log_purge――这个参数用于限制中继日志应用完之后是否删除,缺省为1,即应用完之后立即删除;在MHA中,Manager就是通过这些日志来同步各个Slave之间的数据差异的,所以必须设置为0,即不删除中继日志。
 log_bin――是否开启二进制日志,若某个Slave可能被选择成为新的Master,则必须开启;若某个Slave被限制永远不会成为新的Master,可以不用开启。

成功搭建后,通过MHA命令检查一下,确保无误。

[root@mmm 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 root@192.168.3.27(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 root@192.168.3.28(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.
    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 root@192.168.3.25(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,下面我们就来简单试用一下,并进行一下功能测试。

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的二进制日志;
/usr/bin/apply_diff_relay_logs             ――识别差异的中继日志事件并应用于其它Slave;
/usr/bin/filter_mysqlbinlog                  ――去除不必要的Rollback事件(MHA已不再使用该工具);
/usr/bin/purge_relay_logs                  ――清除中继日志(不会阻塞SQL线程);
备注:Node端工具通常由MHA Manager的脚本触发调用,无需DBA操作。

2.开启MHA

       在开启MHA之前,可以先通过masterha_check_repl检查一下MySQL Replication是否正常,通过masterha_check_ssh检查一下各个node之间SSH登录是否正常,这在前面均已试用该命令。
开启MHA的命令为masterha_manager,其用法如下:
[root@mmm scripts]# /usr/bin/masterha_manager --help
Usage:
    masterha_manager --global_conf=/etc/masterha_default.cnf
    --conf=/usr/local/masterha/conf/app1.cnf

    See online reference
    (http://code.google.com/p/mysql-master-ha/wiki/masterha_manager) for
    details.

可见其只有两个参数,--global_conf缺省为/etc/masterha_default.cnf,本例中符合缺省要求,所以可以不指定,为了方便,通过如下命令使其后台运行。如下:
[root@mmm appl]# /usr/bin/masterha_manager --conf=/etc/appl.cnf &
[1] 5674
[root@mmm appl]# Mon Jul 21 10:56:32 2014 - [info] Reading default configuratoins from /etc/masterha_default.cnf..
Mon Jul 21 10:56:32 2014 - [info] Reading application default configurations from /etc/appl.cnf..
Mon Jul 21 10:56:32 2014 - [info] Reading server configurations from /etc/appl.cnf..

为了使MHA持续运行在服务器端,可通过如下命令使其不挂起运行在后台:

[root@mmm appl]# nohup /usr/bin/masterha_manager --conf=/etc/appl.cnf &
[1] 5905
[root@mmm appl]# nohup: appending output to `nohup.out'

MHA开启之后,会在其工作目录下生成如下两个文件:
[root@mmm appl]# ls
appl.master_status.health  manager.log

其中appl.master_status.health为Master实例的健康监控文件,MHA开启时生成,关闭后消失,里面内容如下:
[root@mmm appl]# more appl.master_status.health 
5674    0:PING_OK       master:192.168.3.27

而manager.log为MHA的日志文件,其内容较多,执行masterha_check_repl命令时的输入内容类似。


可通过masterha_check_status命令检查MHA是否在运行,比如:
[root@mmm appl]# /usr/bin/masterha_check_status --conf=/etc/appl.cnf 
appl (pid:5905) is running(0:PING_OK), master:192.168.3.27

若MHA正常运行,则提示如上,否则提示:appl is stopped(2:NOT_RUNNING).

对于一个正在运行的MHA,可通过masterha_stop命令关闭,如下:
[root@mmm appl]# /usr/bin/masterha_check_status --conf=/etc/appl.cnf 
appl is stopped(2:NOT_RUNNING).


3.Master自动故障转移及差异日志恢复

》模拟复制不同步,造成数据差异
――关闭node3的复制线程,然后在Master主库(node1)上创建一张表,以此造成node3数据不同步

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> use test;
Database changed
mysql> CREATE TABLE student(s_id INT,s_name VARCHAR(10),PRIMARY KEY(s_id));
Query OK, 0 rows affected (0.01 sec)

――关闭node2的复制进线程,
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into student(s_id,s_name) values(1,'aaa');
Query OK, 1 row affected (0.01 sec)

通过这个模拟,现在node1(Master)上有一张student表,并有一条数据;node2(slave1)上有student这张表,但里面没有数据;node3(slave2)上还没有student这张表,所以这套复制环境的3个节点目前是不同步的。


》关闭node1(Master)的mysqld进程,模拟MySQL实例故障
[root@node1 data]# service mysql stop;
Shutting down MySQL...                                     [  OK  ]

此时检查node2,发现已恢复了差异数据(一条记录),停掉了原来的复制线程,被选择为新的Master,并赋予写操作权限。
mysql> select * from student;
+------+--------+
| s_id | s_name |
+------+--------+
|    1 | aaa    |
+------+--------+
1 row in set (0.00 sec)

mysql> show slave status \G;
Empty set (0.00 sec)

mysql> show variables like 'read_only%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

检查node3,发现差异数据也被恢复(student表和一条记录),并将master_host指向新的Master(node2)

mysql> use test;
Database changed
mysql> select * from student;
+------+--------+
| s_id | s_name |
+------+--------+
|    1 | aaa    |
+------+--------+
1 row in set (0.00 sec)

mysql> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.3.28  (这里指向了新的master:node2)
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000005
          Read_Master_Log_Pos: 520069
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 253
        Relay_Master_Log_File: mysql-bin.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 520069
              Relay_Log_Space: 409
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 28
1 row in set (0.00 sec)


从中可以看到,当MHA监控到Master实例故障时,自动恢复了Master与Slave以及Slaves之间的差异日志,然后从两个Slave实例中选择node2充当新的Master,并将另一个Slave实例node2重新指向到新的Master实例node2开始复制,组成新的MySQL Replication结构。而原来的Master则被排除在新的MySQL Replication结构之外,即使其恢复正常,也不会被自动加入。

4.手动Master故障切换

        开启MHA后,自动启动监控功能,当监测到Master故障时,自动实现切换。
另外,在没有开启MHA的情况下,我们还可以执行交互式的手动切换、非交互式的自动切换,及在线切换Master到不同主机等操作,这些都是通过masterha_master_switch命令工具实现的。
该命令用法如下:

[root@mmm appl]# /usr/bin/masterha_master_switch --help
Usage:
    # For master failover

    masterha_master_switch --master_state=dead
    --global_conf=/etc/masterha_default.cnf
    --conf=/usr/local/masterha/conf/app1.cnf --dead_master_host=host1

    # For online master switch

    masterha_master_switch --master_state=alive
    --global_conf=/etc/masterha_default.cnf
    --conf=/usr/local/masterha/conf/app1.cnf

    See online reference
    (http://code.google.com/p/mysql-master-ha/wiki/masterha_master_switch)
    for details.

从中可以看到,该命令有# For master failover、# For online master switch两个用法,区别在于前者需要指定Master的状态为dead,后者需要指定Master的状态为alive。

下面通过两个示例来体会一下:

》 For master failover
现在的Master为node2,手动停止mysqld实例 
[root@node2 ~]# service mysql stop
Shutting down MySQL...                                     [  OK  ]
下面手动执行Master故障切换,这个切换过程是交互式的,期间需要输入指令来确认;另外,由于MHA没有启动,也就不会自动监控Master实例状态,所以需要指定master_state为dead,并且指定dead master的host、ip、port等信息,如下:

[root@mmm ~]# /usr/bin/masterha_master_switch --master_state=dead --conf=/etc/appl.cnf --dead_master_host=node2

》 For online master switch
这个功能是指Master实例运行正常,但出于运维工作(比如:更换硬件等),需要将其上的Master切换到另一主机上。
切换过程都一样,期间也需要交互,只不过指定master_state=alive即可,如下:
# /usr/bin/masterha_master_switch --master_state=alive --conf=/etc/appl.cnf
通过这两个示例,我们知道,不管是自动Master故障切换,还是手动交互式Master切换,以及在线切换Master到另外主机,其切换过程和步骤都是一样的。

 

        至此MHA成功搭建完毕,该小节告一段落,通过前面的学习,我们了解了MHA这一高可用工具的Master故障切换功能及实现原理,但若在实际生产环境中采用它,还存在许多问题,需要进一步的改进与配置。我们先来探讨一下上面这套环境中存在的问题,及MHA提供的解决办法。

问题: 前端应用连接问题

        理论上来说,后端数据库故障切换,对前端应用应该是透明的;也就是说:当Master从一台主机切换到另一台主机上时,前端应用不需要做任何额外的操作,主要体现为数据库连接串变化。

        对于这个问题,通常有两种解决方案:一是引入VIP,当数据库切换时,VIP随之切换;常用的HA软件中,大多是采用VIP实现的,比如Oracle RAC,SQL Server群集、Heartbeat等。二是采用全局目录数据库,即将应用和数据库之间的连接映射为一个列表,当数据库切换时,更改这个映射列表。MHA并不限制用户使用那种方式,只是通过master_ip_failover_script配置参数提供了一个接口。 若采用VIP的方式来实现,可引入第三方软件,比如Keplived等,也可自行编写一个VIP切换脚本。


> 本文由 [ruyi](http://www.dba-china.com/member/ruyi) 创作,采用 [知识共享署名 3.0 中国大陆许可协议](http://creativecommons.org/licenses/by/3.0/cn) 进行许可。 可自由转载、引用,但需署名作者且注明文章出处。


共收到 0 条评论
没有找到数据。
评论文章 (需要登录)