MySQLHA系列MHA（一）
2015-09-24 16:46
645 查看
MHA，这是Master High Availability Manager and Tools for MySQL，一个日本MySQL专家们使用Perl语言编写的一个脚本管理工具。该工具仅适用于MySQL Replication（二层）环境，目的在于维持Master主库的高可用性。
（1） Node
我们知道，MHA是基于MySQL Replication环境的，在该环境中，无论是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点。
Nodeserver上须要安装MHA Node包。
（2） Manager
Manager为MHA架构中的管理者，建议部署在一台独立的server上。当然也可部署在某个Slave上，但该Slave永远不要被选择成为新的Master，否则故障切换后的MHA架构就失去了高可用性。
Managerserver须要安装MHA Manager包，并完好一个主配置文件。
一个Manager可管理多套MySQL Replication环境。
基本工作流程大致例如以下：
（1） Manager定期监控Master，监控时间间隔由參数ping_interval决定。缺省为3秒钟一次；可利用其自身的监控功能。也可调用第三方软件来监控；MHA自身提供了两种监控方式：SELECT（运行SELECT 1）和CONNECT（创建连接/断开连接），因为參数ping_type决定，缺省为SELECT方式。
（2） 当监測到Master故障时，调用SSH脚本对全部Node运行一次检查，包含例如以下几个方面：
――MySQL实例能否够连接。
――Masterserver能否够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所在server依旧能够通过SSH连通，则提取dead master的binary log。提取日志的起点就是上一步获取的最新的binary log file和position。直到最后一条事件日志，并在dead master本地的工作文件夹（由參数remote_workdir决定）中创建文件保存这些提取到的日志，然后将该文件复制到Managerserver的工作文件夹下（由參数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故障切换过程完毕。
（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
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
创建工作文件夹
在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
――生成密钥文件（各个节点均需运行）
# 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
――測试一下
在各节点运行例如以下命令。測试一下。看是否不提示password就可以显示。否则则说明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) to
root@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) to
root@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) to
root@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) to
root@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) to
root@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) to
root@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方式相互登录（用于同步差异日志）。
# 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一下主机名。看是否能成功解析。
依照规划。在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。以下我们就来简单试用一下，并进行一下功能測试。
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操作。
开启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持续执行在server端，可通过例如以下命令使其不挂起执行在后台：
[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).
》模拟复制不同步。造成数据差异
――关闭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切换脚本。
因为篇幅问题。以上两种方案解决方式，等有时间再继续写入到 MySQL高可用系列之MHA（二）
一、简单介绍
学习一个高可用小软件。不但要熟悉其功能，还要了解其架构及工作原理。1. 架构
从架构上来说，MHA分为例如以下两大部分：（1） Node
我们知道，MHA是基于MySQL Replication环境的，在该环境中，无论是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点。
Nodeserver上须要安装MHA Node包。
（2） Manager
Manager为MHA架构中的管理者，建议部署在一台独立的server上。当然也可部署在某个Slave上，但该Slave永远不要被选择成为新的Master，否则故障切换后的MHA架构就失去了高可用性。
Managerserver须要安装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实例能否够连接。
――Masterserver能否够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所在server依旧能够通过SSH连通，则提取dead master的binary log。提取日志的起点就是上一步获取的最新的binary log file和position。直到最后一条事件日志，并在dead master本地的工作文件夹（由參数remote_workdir决定）中创建文件保存这些提取到的日志，然后将该文件复制到Managerserver的工作文件夹下（由參数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配置文件了。仅仅需在Managerserver上操作；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节点之间须要无password登录并运行相关脚本，所以须要配置各个节点之间的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
――測试一下
在各节点运行例如以下命令。測试一下。看是否不提示password就可以显示。否则则说明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) to
root@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) to
root@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) to
root@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) to
root@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) to
root@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) to
root@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之间提供一个解析途径，配置方法非常easy，就是将各个节点的主机名及相应的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来说。搭建MySQLReplication须要注意下面几点：
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持续执行在server端，可通过例如以下命令使其不挂起执行在后台：
[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切换脚本。
因为篇幅问题。以上两种方案解决方式，等有时间再继续写入到 MySQL高可用系列之MHA（二）
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 高性能mysql(一)优化数据类型
- 游戏服务器开发--阿里云Ubuntu 安装mysql
- mysql读写分离（二）-----主从复制
- mysql用户管理（新增用户及权限管理）
- mysql添加远程访问
- MySQL Meta中的length字段 -- (4) 玩儿MySQL代码
- MySQL必知必会笔记（七）事务处理 全球化和本地化（字符集和校对）
- mysql安装及使用语句
- MySQL必知必会笔记（六）存储过程 游标 触发器
- MySQL必知必会笔记（五）插入数据 创建和操纵表
- MySQL必知必会笔记（四）SELECT语句 联结表 高级联结 组合查询 全文本搜索
- windows-----MySQL下载安装、配置与使用（win7x64）
- MySQL必知必会笔记（三）SELECT语句 计算字段 数据处理函数 汇总函数 分组数据 子查询
- mysql读写分离(一)----------mysql安装
- mysql中的多行查询结果合并成一个
- MySQL必知必会笔记（二）SELECT语句 检索 排序 过滤 通配符搜索 正则表达式搜索
- MySQL必知必会笔记（一）基础知识和基本操作
- mysql case when then end使用方式
- mysql配置文件小优化及主主模式
- MySQL的数据库引擎的类型