MySQL高可用MHA原理及测试
文章来源: 陶老师运维笔记- 微信公众号
1. MHA 简介
- MHA 架构介绍：github.com/yoshinorim/…
- github下载地址：github.com/yoshinorim/…
MHA 简介:
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本的youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。 在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA优点：
- master failover和slave promotion非常快速。 2. 自动探测，多重检测，切换过程中支持调用其他脚本的接口。
- master crash不会导致数据不一致，自动补齐数据，维护数据一致性。
- 不需要修改复制的任何设置，简单易部署，对现有架构无影响。
- 不需要增加很多额外的机器来部署MHA，支持多实例集中管理。
- 没有任何性能影响。
- 跨存储引擎，支持任何引擎
MHA不支持的场景:
- 多层次复制 (M1->M2->Slave)
- MySQL5.0.45或更低版本
- 复制规则(replication filteing rules(binlog-do-db,replicate-ignore-db,etc) 必须一致
- Load Data [Local] Infile with SBR 不支持。
2. MHA工作原理
MHA工作原理总结为以下几条： （1）从宕机崩溃的master保存二进制日志事件（binlog events）; （2）识别含有最新更新的slave; （3）应用差异的中继日志(relay log) 到其他slave; （4）应用从master保存的二进制日志事件(binlog events); （5）提升一个slave为新master; （6）使用其他的slave连接新的master进行复制。
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
2.1 主库故障处理场景
主库故障:
- 场景1: 全部从库都有全部binlog event
这是一种最理想的情况，但是事情常不可能这样幸运。
-
场景2:Master有事务没有同步到从库 使用了半同步复制可以避免这个风险。
-
场景3:部分从库缺失binlog event
2.2 问题及困难
主库Failover的困难点,最近的从库还是缺失了主库binlog event。
2.3 问题解决
目标实现:
保存binlog event
找出最近master 的slave:
识别出各从库丢失的event
实施恢复
3. MHA组件架构
3.1 MHA组件架构
-
MHA manager: 管理节点，通常单独部署在一台独立的服务器上，用来管理多个master/slave集群，也可部署在一台slave节点上，每个master/slave集群称为一个application。 MHA Manager会定时探测集群中的master节点，当发现master节点出现故障时，它可以自动将具有最新数据的slave节点提升为新的master节点，然后将所有其它 的slave节点重新指向新的master节点。
-
MHA node: 数据节点，运行在每台MariaDB服务器上（manager/master/slave），它通过监控具备解析和清理logs功能的脚本来加快故障转移。
3.2 软件包功能介绍
Manager工具:
vbscript
复制代码
Manager工具包：
masterha_manger 启动MHA
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_master_monitor 检测master是否宕机
masterha_check_status 检测当前MHA运行状态
masterha_master_switch 控制故障转移（自动或者手动）
masterha_conf_host 添加或删除配置的server信息
Node工具：
sql
复制代码
Node工具（所有集群节点）：
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
3.3 MHA处理过程
scss
复制代码
====== monitor node 监控节点======
(1) 监控所有节点,重点是master
(2) 监控到master宕机(实例(ssh能),主机(ssh不能连))
(3) 监控主从状态
====== failover 故障转移 ======
(3) 对比各节点的GTID号码。
(3) 数据补偿1:如果ssh能连,从节点立即保存自己缺失部分的二进制日志
(4) 选主:对比各节点的GTID号码即可,选一个最接近于主库数据的从节点，恢复缺失的日志，并将从库切换为主库 stop slave reset slave all
(5) 数据补偿2:如果ssh不能连,计算两个从库的relaylog的差异,恢复到数据少的从库中.
(6) 2号从库change master to 到 新主,开启新的主从关系
====== 应用透明=====
(7) 使用vip机制实现应用透明
====== 补充功能 ======
(8) 自动修复主库(加入集群)待开发...
(9) 二次数据补偿的问题 (binlog server)
(10) 提醒功能(send_report)
(11) 权重的问题
4. MHA环境搭建
4.1 环境规划
使用三台机器来做一个简易的MHA环境，MHA软件版本为mha-0.56。
| IP | Port | DB角色 | MHA角色 | 软件版本 |
|---|---|---|---|---|
| 192.124.64.212 | 3307 | DB1 master | mha-node | centos6,mha-0.56 |
| 192.124.64.213 | 3307 | DB2 slave | mha-node | centos6,mha-0.56 |
| 192.124.64.214 | 3307 | DB3 slave | mha-node node-manager | centos6,mha-0.56 |
安装建议：
1.manager可以单独装在任意一台机器上； 2.一个manager可以管理多套mysql集群； 3.建议不要将manager装在主库上（防止主库断电，断网）； 4.所有数据库必须安装node包； 5.manager的依赖有node
4.2 各节点SSH互信
bash
复制代码
#各节点执行如下操作
ssh-keygen -t rsa -P '' -f /root/.ssh/id_rsa
#
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.124.64.213
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.124.64.212
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.124.64.214
4.3 MySQL主从安装
1.安装MySQL
css
复制代码
#使用自已写的脚本安装MySQL
mysql_install -P 3307 -r m -b 2G -v 5.6.27
2.搭建主从关系
ini
复制代码
DB1做为主,DB2,DB3为从库
#授权
grant replication client,replication slave on *.* to 'repl'@'10.%' IDENTIFIED BY 'repl123';
grant all privileges on *.* to mha@'10.%' identified by 'mha123';
#DB2,DB3建立主从关系
CHANGE MASTER TO
MASTER_HOST='192.124.64.212',
MASTER_PORT=3307,
MASTER_USER='repl',
MASTER_PASSWORD='repl123',
MASTER_AUTO_POSITION = 1;
#
start slave ;
show slave status\G
说明：
- 从库建议用命令设为只读 set global read_only=1，不要将该参数写进配置文件中.
- 从库关闭中继日志的清除 set global relay_log_purge=0. MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。
4.4 MHA软件安装
下载软件并安装： 所有节点（数据库master，slave，MHA manager节点）都需要安装MHA node。因为MHA manager也需要依赖MHA node。
bash
复制代码
#软件下载
mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
所有节点安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
#在DB3节点上安装mha-manager
yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
5. MHA配置
为保证MHA正常工作，需要配置MHA的配置文件，为参数设置合理正确的值，这些参数包括服务器IP，数据库用户名密码，工作目录与日志等。 MHA源码安装,则会有两个配置文件模板，在路径 $MHA_BASE/samples/conf/ 下的app1.cnf 和 masterha_default .cnf。
创建目录:
bash
复制代码
mkdir /etc/mha/script -p
创建日志目录
mkdir -p /var/log/mha/
编辑mha配置文件:
ini
复制代码
vim /etc/mha/mysql3307.cnf
[server default]
manager_log=/var/log/mha/mysql3307/manager
manager_workdir=/var/log/mha/mysql3307
master_binlog_dir=/data1/mysql_3307/
user=mha
password=mha123
ping_interval=2
repl_user=repl
repl_password=repl123
ssh_user=root
#master_ip_failover_script=/etc/mha/script/master_ip_failover
#shutdown_script= /etc/mha/script/power_manager
#report_script= /etc/mha/script/send_master_failover_mail
[server1]
hostname=192.124.64.212
port=3307
[server2]
hostname=192.124.64.213
port=3307
[server3]
hostname=192.124.64.214
port=3307
6. 检查状态
1.互信检查
ini
复制代码
$masterha_check_ssh --conf=/etc/mha/mysql3307.cnf
Sat Mar 21 23:14:28 2020 - [warning] Global configuration file /etc/masterha_default .cnf not found. Skipping.
Sat Mar 21 23:14:28 2020 - [info] Reading application default configuration from /etc/mha/mysql3307.cnf..
Sat Mar 21 23:14:28 2020 - [info] Reading server configuration from /etc/mha/mysql3307.cnf..
Sat Mar 21 23:14:28 2020 - [info] Starting SSH connection tests..
...
Sat Mar 21 23:14:29 2020 - [info] All SSH connection tests passed successfully.
2.检查复制
ini
复制代码
masterha_check_repl --conf=/etc/mha/mysql3307.cnf
Sat Mar 21 23:17:00 2020 - [warning] Global configuration file /etc/masterha_default .cnf not found. Skipping.
Sat Mar 21 23:17:00 2020 - [info] Reading application default configuration from /etc/mha/mysql3307.cnf..
Sat Mar 21 23:17:00 2020 - [info] Reading server configuration from /etc/mha/mysql3307.cnf..
Sat Mar 21 23:17:00 2020 - [info] MHA::MasterMonitor version 0.56.
Sat Mar 21 23:17:01 2020 - [info] GTID failover mode = 1
Sat Mar 21 23:17:01 2020 - [info] Dead Servers:
Sat Mar 21 23:17:01 2020 - [info] Alive Servers:
Sat Mar 21 23:17:01 2020 - [info] 192.124.64.212(192.124.64.212:3307)
Sat Mar 21 23:17:01 2020 - [info] 192.124.64.213(192.124.64.213:3307)
Sat Mar 21 23:17:01 2020 - [info] 192.124.64.214(192.124.64.214:3307)
Sat Mar 21 23:17:01 2020 - [info] Alive Slaves:
Sat Mar 21 23:17:01 2020 - [info] 192.124.64.213(192.124.64.213:3307) Version=5.6.27-log (oldest major version between slaves) log-bin:enabled
Sat Mar 21 23:17:01 2020 - [info] GTID ON
Sat Mar 21 23:17:01 2020 - [info] Replicating from 192.124.64.212(192.124.64.212:3307)
Sat Mar 21 23:17:01 2020 - [info] 192.124.64.214(192.124.64.214:3307) Version=5.6.27-log (oldest major version between slaves) log-bin:enabled
Sat Mar 21 23:17:01 2020 - [info] GTID ON
Sat Mar 21 23:17:01 2020 - [info] Replicating from 192.124.64.212(192.124.64.212:3307)
Sat Mar 21 23:17:01 2020 - [info] Current Alive Master: 192.124.64.212(192.124.64.212:3307)
Sat Mar 21 23:17:01 2020 - [info] Checking slave configurations..
Sat Mar 21 23:17:01 2020 - [info] read_only=1 is not set on slave 192.124.64.213(192.124.64.213:3307).
Sat Mar 21 23:17:01 2020 - [info] read_only=1 is not set on slave 192.124.64.214(192.124.64.214:3307).
Sat Mar 21 23:17:01 2020 - [info] Checking replication filtering settings..
Sat Mar 21 23:17:01 2020 - [info] binlog_do_db= , binlog_ignore_db=
Sat Mar 21 23:17:01 2020 - [info] Replication filtering check ok.
Sat Mar 21 23:17:01 2020 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Sat Mar 21 23:17:01 2020 - [info] Checking SSH publickey authentication settings on the current master..
Warning: Permanently added '192.124.64.212' (RSA) to the list of known hosts.
Sat Mar 21 23:17:01 2020 - [info] HealthCheck: SSH to 192.124.64.212 is reachable.
Sat Mar 21 23:17:01 2020 - [info]
192.124.64.212(192.124.64.212:3307) (current master)
+--192.124.64.213(192.124.64.213:3307)
+--192.124.64.214(192.124.64.214:3307)
Sat Mar 21 23:17:01 2020 - [info] Checking replication health on 192.124.64.213..
Sat Mar 21 23:17:01 2020 - [info] ok.
Sat Mar 21 23:17:01 2020 - [info] Checking replication health on 192.124.64.214..
Sat Mar 21 23:17:01 2020 - [info] ok.
Sat Mar 21 23:17:01 2020 - [warning] master_ip_failover_script is not defined.
Sat Mar 21 23:17:01 2020 - [warning] shutdown_script is not defined.
Sat Mar 21 23:17:01 2020 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.
7. 启动MHA
启动MHA:
shell
复制代码
#查看MHA manager监控状态，这里没有运行
# masterha_check_status --conf=/etc/mha/mysql3307.cnf
mysql3307 is stopped(2:NOT_RUNNING).
#启动MHA监控 --remove_dead_master_conf --ignore_last_failover
$nohup masterha_manager --conf=/etc/mha/mysql3307.cnf --remove_dead_master_conf --ignore_last_failover >> /var/log/mha/mysql3307/mha-3307.log 2>&1 &
#检查状态
$masterha_check_status --conf=/etc/mha/mysql3307.cnf
mysql3307 (pid:10265) is running(0:PING_OK), master:192.124.64.212
停止MHA监控:
ini
复制代码
停止MHA监控
masterha_stop --conf=/etc/mha/mysql3307.cnf
8. 测试MHA
8.1 检查当前状态
perl
复制代码
$masterha_check_status --conf=/etc/mha/mysql3307.cnf
mysql3307 (pid:10265) is running(0:PING_OK), master:192.124.64.212
$mysql -h 192.124.64.214 -P 3307 -e "set global relay_log_purge=0"
$mysql -h 192.124.64.214 -P 3307 -e "show global variables like '%relay_log_purge%'"
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| relay_log_purge | OFF |
+-----------------+-------+
$mysql -h 192.124.64.214 -P 3307 -e "show slave status\G" |egrep 'Master_Host|Master_Port|Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master' -i
Master_Host: 192.124.64.212
Master_Port: 3307
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
8.2 测试自动切换
1. 测试主库故障，自动切换。
shell
复制代码
#kill master DB1
$kill mysql_pid;
2. 查看详细日志：
观察manager 日志,末尾必须显示successfully，才算正常切换成功。 tail -f /var/log/mha/mysql3307/manager.log
less
复制代码
cat /var/log/mha/mysql3307/manager
Sat Mar 21 23:24:59 2020 - [info] MHA::MasterMonitor version 0.56.
Sat Mar 21 23:25:01 2020 - [info] GTID failover mode = 1
Sat Mar 21 23:25:01 2020 - [info] Dead Servers:
Sat Mar 21 23:25:01 2020 - [info] Alive Servers:
Sat Mar 21 23:25:01 2020 - [info] 192.124.64.212(192.124.64.212:3307)
Sat Mar 21 23:25:01 2020 - [info] 192.124.64.213(192.124.64.213:3307)
Sat Mar 21 23:25:01 2020 - [info] 192.124.64.214(192.124.64.214:3307)
Sat Mar 21 23:25:01 2020 - [info] Alive Slaves:
Sat Mar 21 23:25:01 2020 - [info] 192.124.64.213(192.124.64.213:3307) Version=5.6.27-log (oldest major version between slaves) log-bin:enabled
Sat Mar 21 23:25:01 2020 - [info] GTID ON
...
----- Failover Report -----
mysql3307: MySQL Master failover 192.124.64.212(192.124.64.212:3307) to 192.124.64.213(192.124.64.213:3307) succeeded
Master 192.124.64.212(192.124.64.212:3307) is down!
Check MHA Manager logs at LeDB-VM-124064214:/var/log/mha/mysql3307/manager for details.
Started automated(non-interactive) failover.
Invalidated master IP address on 192.124.64.212(192.124.64.212:3307)
Selected 192.124.64.213(192.124.64.213:3307) as a new master.
192.124.64.213(192.124.64.213:3307): OK: Applying all logs succeeded.