Jusene's Blog

Mysql 高可用架构 MHA

字数统计: 2k阅读时长: 8 min
2017/08/20 Share

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,并再次检测其状态。

CATALOG
  1. 1. MHA
  2. 2. MHA 工具
  3. 3. 配置MHA
    1. 3.1. 准备MySQL Replication环境
    2. 3.2. 安装配置MHA