Mysql 高可用架构 MHA

MHA

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。MySQL故障切换过程中，MHA能做到在0～30秒之内自动完成数据库的故障切换操作，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

该软件由两部分组成：MHA Manager(管理节点)和MHA Node(数据节点)。MHA Mananger可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点中，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失，但这这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

官方介绍：https://code.google.com/p/mysql-master-ha/

• MHA Manager:通常单独部署在一台独立机器上管理多个 master/slave 集群，每个master/slave 集群称作一个 application;
• MHA node:运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。

(1) 从宕机的master保存二进制日志事件
(2) 通过relay log识别最新的更新的slave
(3) 应用差异的中继日志到其他的slave
(4) 应用从master保存的二进制日志事件
(5) 提升一个slave为新的master
(6) 是其他slave连接新的master进行复制

MHA 工具

Manager提供如下功能

• masterha_check_ssh:MHA 依赖的 SSH 环境检测工具;
• masterha_check_repl:MySQL 复制环境检测工具;
• masterha_manager:MHA 服务主程序;
• masterha_check_status:MHA 运行状态探测工具;
• masterha_master_monitor:MySQL master 节点可用性监测工具; - masterha_master_switch:master 节点切换工具;
• masterha_conf_host:添加或删除配置的节点;
• masterha_stop:关闭 MHA 服务的工具;

Node提供如下功能

• save_binary_logs:保存和复制 master 的二进制日志:
• apply_diff_relay_logs:识别差异的中继日志事件并应用于其它 slave:
• filter_mysqlbinlog:去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具): - purge_relay_logs:清除中继日志(不会阻塞 SQL 线程):

自定义扩展:

• secondary_check_script:通过多条网络路由检测 master 的可用性;
• master_ip_failover_script:更新 application 使用的 masterip; - shutdown_script:强制关闭 master 节点;
• report_script:发送报告;
• init_conf_load_script:加载初始配置参数;
• master_ip_online_change_script:更新 master 节点 ip 地址;

注意：为了尽可能的减少主库硬件损坏宕机造成的数据丢失，尽量配置成节点半同步复制结构。

配置MHA

准备MySQL Replication环境

MHA 对 MySQL 复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显式启用其 read-only 属性，并关闭 relay_log_purge 功能等，这里先对其配置做事先说明。

初始化主节点master配置：
server_id=1
relay-log=relay-bin
log-bin=master-bin

所有slave节点依赖的配置：
server_id=2
relay-log=relay-bin
log-bin=master-bin
relay_log_purge=0
read_only=1

具体配置mysql主从复制过程就不累赘了，确保mysql主从复制io/sql两线程正常工作。

而后，在所有mysql节点授权拥有管理权限的用户可以在本地网络上远程访问，只需授权集群网断主机即可：

1

mysql>grant all on *.* to 'mhaadmin'@'10.211.55.%' identified by 'mhapass';

安装配置MHA

MHA集群中的各节点彼此之间均需要基于ssh互信通信，以实现远程控制及数据管理功能。 简单起见，可在 Manager 节点生成密钥对儿，并设置其可远程连接本地主机后，将私钥文件 及 authorized_keys 文件复制给余下的所有节点即可。

1

~]# ssh-keygen -t rsa -P ''

2

~]# cat .ssh/id_rsa.pub >> .ssh/authorized_keys

3

~]# chmod go= .ssh/authorized_keys

4

5

~]# scp -a .ssh/{id_rsa,authorized_keys} node2:/root/.ssh

6

~]# scp -a .ssh/{id_rsa,authorized_keys} node3:/root/.ssh

安装MHA:
除了源码包，MHA 官方也提供了 rpm 格式的程序包，其下载地址为 https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2 。 CentOS 7 系统可直接使用适 用于 el6 的程序包。另外，MHA Manage 和 MHA Node 程序包的版本并不强制要求一致。

Manager 节点:

1

~]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm

所有节点，包括 Manager:

1

~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm

初始化MHA:
Manger 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件，而所有的 master/slave 集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf，其为可 选配置。如果仅监控一组 master/slave 集群，也可直接通过 application 的配置来提供各服务 器的默认配置信息。而每个 application 的配置文件路径为自定义，例如，本示例中将使用 /etc/masterha/app1.cnf，其内容如下所示。

1

[server default]

2

user=mhaadmin # MySQL Administrator 

3

password=mhapass # MySQL Administrator's password 

4

manager_workdir=/data/masterha/app1 

5

manager_log=/data/masterha/app1/manager.log 

6

remote_workdir=/data/masterha/app1

7

ssh_user=root

8

repl_user=repluser

9

repl_password=replpass

10

ping_interval=1

11

[server1] 

12

hostname=10.211.55.35

13

#ssh_port=22022 

14

candidate_master=1  #定义是否可成为为主节点

15

[server2] 

16

hostname=10.211.55.36

17

#ssh_port=22022 

18

candidate_master=1

19

[server3] 

20

hostname=10.211.55.37

21

#ssh_port=22022 

22

#no_master=1

检查环境：

ssh

1

~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

2

输出信息最后一行类似如下信息，表示其通过检测。

3

[info] All SSH connection tests passed successfully.

repl

1

检查管理的 MySQL 复制集群的连接配置参数是否 OK:

2

~]# masterha_check_repl --conf=/etc/masterha/app1.cnf 

3

输出信息如下所示，最后一行的“Health is OK”信息表示通过检测。 

4

....

5

MySQL Replication Health is OK.

启动MHA:

1

~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf > /data/masterha/app1/manager.log 2>&1 &

启动成功后，可通过如下命令来查看 master 节点的状态。

1

~]# masterha_check_status --conf=/etc/masterha/app1.cnf

2

app1 (pid:4978) is running(0:PING_OK), master:10.211.55.35

如果要停止 MHA，需要使用 masterha_stop 命令。

1

~]# masterha_stop --conf=/etc/masterha/app1.cnf 

2

Stopped app1 successfully.

注意：故障转移完成后，manager 将会自动停止，此时使用 masterha_check_status 命令检测将会遇到错误提示，如下所示。

1

~]# masterha_check_status --conf=/etc/masterha/app1.cnf 

2

app1 is stopped(2:NOT_RUNNING).

提供新的从节点以修复复制集群：
原有 master 节点故障后，需要重新准备好一个新的 MySQL 节点。基于来自于 master 节点 的备份恢复数据后，将其配置为新的 master 的从节点即可。注意，新加入的节点如果为新 增节点，其 IP 地址要配置为原来 master 节点的 IP，否则，还需要修改 app1.cnf 中相应的 ip 地址。随后再次启动 manager，并再次检测其状态。