Linux 使用 MHA 实现 MariaDB 高可用架构

MHA（Master High Availability）是一款开源的 MySQL 的高可用程序，目前在MySQL高可用方面是一个相对成熟的解决方案，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。MHA由日本DeNA公司的youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

MHA主要由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

MHA Manager：
　　通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。
MHA node：
　　运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
　　主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作，如果没有发给新主节点在本地应用后提升为主节点。

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

目前MHA主要支持一主多从的架构。要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。

每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时， Manager 才能顺利的连接进去，实现主从切换功能。

MHA工作原理

• 从宕机崩溃的master保存二进制日志事件（binlog events）；
• 识别含有最新更新的slave；
• 应用差异的中继日志（relay log）到其他slave；
• 应用从master保存的二进制日志事件（binlog events）；
• 提升一个slave为新master；
• 使用其他的slave连接新的master进行复制。

MHA提供了如下功能：

• master自动监控，故障转移一体化(Automated master monitoring and failover)
• MHA可以在一个复制组中监控master的状态，如果挂了，就可以自动的做failover。
• MHA通过所有slave的差异relay-log来保证数据的一致性。
• MHA在做故障转移，日志补偿这些动作的时候，通常只需要10~30秒。
• 通常情况下，MHA会选择最新的slave作为new master，但是你也可以指定哪些是候选maser，那么新master选举的时候，就从这些host里面挑。
• 导致复制环境中断的一致性问题，在MHA中是不会发生的，请放心使用。
• 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5及以上版本的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。
• 手工-交互式master故障转移（Interactive manually initiated Master Failover）
• MHA可以配置成手工-交互式方式进行故障转移，不支持监控master的状态。
• 非交互式master故障转移 （Non-interactive master failover）
• 非交互式，自动的故障转移，不提供监控master状态功能，监控可以交给其他组件做（如：Pacemaker heartbeat）。
• 在线master切换 （Online switching master to a different host）

MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。

Manager：

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

Node：（工具由MHA Manager的脚本自动触发）

• 　　save_binary_logs：保存和复制 master 的二进制日志
• 　　apply_diff_relay_logs：识别差异的中继日志事件并应用于其他 slave
• 　　purge_relay_logs：清除中继日志（不会阻塞 SQL 线程）

自定义扩展：

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

---

实验环境

• manager        server10.2       192.168.10.2
• node1            client10.5         192.168.10.5
• node2            client10.6         192.168.10.6
• node3            client10.7         192.168.10.7

要做到以下几点要求

• 关闭selinux、iptables以及firewalld

• 做好半同步主从复制     参照拙作：https://blog.csdn.net/gaofei0428/article/details/103829676

• 所有节点都要使用ssh密钥无密码访问（必须为root用户） 参照拙作：https://blog.csdn.net/gaofei0428/article/details/104018808

• mha4mysql-manager 和 mha4mysql-node 软件版本必须一致

---

首先检测半同步主从复制状况

• 在 node1、2、3上分别查看半同步复制状况

• server-id=1                                          注意ID值不能有重复
  log-bin=/data/master-log
  relay-log=/data/slave-log
  relay_log_purge=0
  log_slave_updates=1
  read_only=ON
  plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"        启用半同步复制插件
  rpl-semi-sync-master-enabled=1
  rpl-semi-sync-slave-enabled=1

• 查看插件是否启用，确保同步状况正常

• 在 node 各节点上添加授权用户 mhaadmin

• 查看各节点是否可以ssh无密码登录

• 在manager  server10.2上安装 mha4mysql-manager 和 mha4mysql-node

• 在其他节点上安装 mha4mysql-node ，确保版本一致

---

• 在 server 10.2 上配置 manager 

• mkdir /etc/masterha
• vim /etc/masterha/mha.cnf

• [server default]
  user=mhaadmin                                                   //mha管理用户
  password=123456                                                //mha管理用户密码
  manager_workdir=/etc/masterha/app1                  //mha_master自己的工作路径
  manager_log=/etc/masterha/manager.log             // mha_master自己的日志文件
  remote_workdir=/etc/masterha/app1                     //每个远程主机的工作目录在何处                    
  ssh_user=root                                                      // 基于ssh的密钥认证
  repl_user=slave                                                    Mariadb管理帐号和密码
  repl_password=123456
  ping_interval=1                                                    //ping间隔时长
  master_binlog_dir=/data/                                     //二进制日志存放目录
  [server1]                                                              //node节点1
  hostname=192.168.10.5                                      //节点主机地址
  ssh_port=22                                                        //节点的ssh端口
  candidate_master=1                                            //将来可不可以成为master候选节点/主节点
  check_repl_delay=0                                            //忽略复制延迟
  [server2]
  hostname=192.168.10.6
  ssh_port=22
  candidate_master=1
  check_repl_delay=0
  [server3]
  hostname=192.168.10.7
  ssh_port=22
  candidate_master=1
  check_repl_delay=0

---

• 确认无误后，开始MHA检测
• 首先检测ssh互通
• masterha_check_ssh -conf=/etc/masterha/mha.cnf

• 检测复制功能

• masterha_check_repl -conf=/etc/masterha/mha.cnf

• 检测无误，全部通过，下面启动mha
• nohup masterha_manager -conf=/etc/masterha/mha.cnf &> /etc/masterha/manager.log &

• mha (pid:2279) is running(0:PING_OK), master:192.168.10.5

启动正常，显示目前 master 为：192.168.10.5

---

• 手动切换 master

• 首先停止mha
• masterha_stop -conf=/etc/masterha/mha.cnf
• 选择切换到哪个节点
• masterha_master_switch --conf=/etc/masterha/mha.cnf --master_state=alive --new_master_host=192.168.10.6 --new_master_port=3306 --orig_master_is_new_slave --running_updates_limit=10000
• 有提示要选择时，全部选择 yes
• 切换成功后启动MHA，查看状况
• nohup masterha_manager -conf=/etc/masterha/mha.cnf &> /etc/masterha/manager.log &
• masterha_check_status -conf=/etc/masterha/mha.cnf

• 切换成功，显示目前 masterr 为 192.168.10.6
• 下面进行MHA 故障转移测试

• 在 master 节点关闭 mariadb 服务,模拟主节点数据崩溃

• killall -9 mysqld mysqld_safe

• rm -rf /var/lib/mysql/*

• 在 manger 节点查看日志

• tail -100 /etc/masterha/manager.log

• 表示 manager 检测到192.168.10.6节点故障， 而后自动执行故障转移， 将192.168.10.5提升为主节点。

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

• 提供新的从节点以修复复制集群

• 原有 master 节点故障后，需要重新准备好一个新的 Mariadb 节点。基于来自于master 节点的备份恢复数据后，将其配置为新的 master 的从节点即可。

• 注意，新加入的节点如果为新增节点，其 IP 地址要配置为原来 master 节点的 IP，否则就需要修改 mha.cnf 中相应的 ip 地址。

---

• 新节点上线， 故障转换恢复注意事项
• 在生产环境中， 当你的主节点挂了后， 一定要在从节点上做一个备份， 拿着备份文件把主节点手动提升为从节点， 并指明从哪一个日志文件的位置开始复制
• 每一次自动完成转换后， 每一次的(replication health )检测不ok始终都是启动不了必须手动修复主节点， 除非你改配置文件

---

• 就以刚刚关闭的那台主作为新添加的机器，来进行数据库的恢复：
• 原本的 Client10.5 已经成为了新的master，对其进行完全备份，而后把备份的数据发送到新添加的机器上：

• 在新添加的机器上进行半同步主从复制操作

• 回到 manager 上启动 mha 

• 再次切换测试

---

可用启动参数介绍：
--remove_dead_master_conf 该参数代表当发生主从切换后，老的主库的 IP 将会从配置文件中移除。
--manger_log 日志存放位置
--ignore_last_failover 在缺省情况下，如果 MHA 检测到连续发生宕机，且两次宕机间隔不足 8 小时的话，则不会进行 Failover，之所以这样限制是为了避免 ping-pong 效应。该参数代表忽略上次 MHA 触发切换产生的文件，默认情况下，MHA 发生切换后会在日志目录，也就是设置的/data 产生 app1.failover.complete 文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--gnore_last_failover。

 

nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --gnore_last_failover < /dev/null &> /var/log/masterha/app1/manager.log &