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
- 做好半同步主从复制
- 所有节点都要使用ssh**无密码访问（必须为root用户）
- 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-node和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
- 再次切换测试