mysql搭建MHA高可用解析

1. MHA能做什么?

主库宕机处理过程
1. 监控节点 (通过配置文件获取所有节点信息)
   系统,网络,SSH连接性
   主从状态,重点是主库

2. 选主
(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
(3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主.
    1. 默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重,也会失效.
    2. 如果check_repl_delay=0的化,即使落后很多日志,也强制选择其为备选主
3. 数据补偿
(1) 当SSH能连接,从库对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用(save_binary_logs )
(2) 当SSH不能连接, 对比从库之间的relaylog的差异(apply_diff_relay_logs) 
4. Failover
将备选主进行身份切换,对外提供服务
其余从库和新主库确认新的主从关系
5. 应用透明(VIP)
6. 故障切换通知(send_reprt)
7. 二次数据补偿(binlog_server)
8. 自愈自治(待开发...)
9. 故障提醒

1.1 MHA高可用本次配置的节点说明

1. mha要求数据库节点至少是1主2从的独立实例, 不支持单机多实例的场景
2. mha的管理节点, 最好是使用一台独立的机器, 本次把管理节点和其中一台从库放到的同一台机器上.
3. 本次配置使用的节点说明:
　　192.168.0.106的3320端口mysql作为主库;
　　192.168.0.105的3321端口mysql作为从库之一;
　　192.168.0.103的3322端口mysql作为从库之一,管理节点也在这台机器上;
4. mha提供有两个端, 一个是管理端(103机器上), 一个是node端(node端必须在所有节点上安装).

2. MHA软件的构成

mha由管理软件和node软件两部分组成, 说明如下:

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工具包主要包括以下几个工具：
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志（不会阻塞SQL线程）

 2.1 MHA的failover如何实现?

流程: 启动 - 故障 - 转移 - 业务恢复
1. mha通过masterha_manager脚本启动mha的功能.
2. 在manager启动之前, 会自从检查ssh互信(masterha_check_ssh)和主从状态(masterha_check_repl)
3. mha_manager通过masterha_master_monitor脚本来探测主库是否存活,探测频率受配置文件中的ping_interval的值来控制, 以秒为单位.
4. masterha_master_monitor探测主库3次无心跳则判定为主库宕机.
5. 进行选主的过程:
　　算法一:
　　读取配置文件中是否有强制选主的参数,参数如下
　　candidate_master=1　　# 写在[servern]块中, 按照权重指定备选主. manager有默认检测数据差异的机制,如差异过大,即使配置次参数也不生效,而会通过其它算法选主
　　check_repl_delay=0　　# 写在[servern]块中, 强制选为主, 即不论数据差异有多大.
　　算法二:
　　自动判断所有从库的日志量, 将最接近主库数据的从库作为主库.如果所有从库的日志量都一样则按照算法三选主.
　　算法三:
　　按照配置文件先后顺序进行选主
6. 数据补偿:
　　判断主库ssh的连通性.
　　情况一: ssh能连时,调用save_binary_logs脚本,立即保存缺失部分的binlog到各个从节点来恢复.
　　情况二: ssh不能连,调用apply_diff_relay_logs脚本,计算各从库relaylog的差异,只能把所有从库中数据最多的从库数据同步给所有从库.
6.1提供额外的数据补偿的能力
　　该功能需要单独配置,默认是没有的, 详见2.4中的配置说明

7. 解除从库身份

8. 剩余从库和新主库构建主从

9. 应用透明配置(vip,装有manager软件的节点)
　　该功能需要单独配置, 默认是没有的, 详见2.2中的配置说明

10.故障提醒(邮件提醒)
　　该功能需要单独配置, 默认是没有的, 详见2.3中的配置说明

11.手动恢复1主2从
　　mha在完成一次failover后就会结束掉. 我们需要重新配置好主从, 修改好配置文件, 开启数据补充进程(如有), 然后就可以重新启动mha了

#1 mha故障恢复
启动原来的主节点

#2 在配置的manager_log路径下mha的日志中有恢复1主两从的change master to 参数
这里是继续使用的mha自动切主的那台机器作为主库
grep "CHANGE MASTER TO" /var/log/mha/app1/manager
CHANGE MASTER TO MASTER_HOST='192.168.0.105', MASTER_PORT=3321, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
start slave;
执行以上语句在原来的主库上

#3 恢复manager上的配置文件
mha完成failover后会把原主库信息从配置文件中删掉, 我们需要在添加上(当然此时作为从库了)

#4 开启数据补充
详见2.4中配置

#5 启动mha,查看状态

 2.2 应用透明配置(vip, 装有manager软件的节点)

2.2.1修改master_ip_failover脚本, 该脚本度娘上多的是

　　vim /usr/local/bin/master_ip_failover　　# 脚本位置自定义即可;修改以下4行即可,虚拟机中是eth0,服务器不一定是
　　　　my $vip = '192.168.0.100/24'; # 要把哪个地址设为vip地址,是对外提供服务的网段地址.24位子网掩码
　　　　my $key = "1";
　　　　my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
　　　　my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";

注意脚本内有中文需转换下,并给该脚本执行权限：
[root@db03 ~]# dos2unix /usr/local/bin/master_ip_failover
dos2unix: converting file /usr/local/bin/master_ip_failover to Unix format ...
[root@db03 ~]# chmod +x /usr/local/bin/master_ip_failover

获取脚本: https://www.cnblogs.com/quzq/p/12969734.html

2.2.2更改manager配置文件:

vi /etc/mha/app1.cnf
在server default块下添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover

2.2.3主库上手工生成第一个vip地址(106那台机器上)

手工在主库上绑定vip，注意一定要和配置文件中的ethN一致，我的是eth0:1(1是key指定的值)
ifconfig eth0:1 192.168.0.100/24
如果报错eth0:1: ERROR while getting interface flags: No such device
则查看下机器的网卡信息,改成对应的就可以. 修改后master_ip_failover脚本中也需要修改.

2.2.4重启mha,并查看状态

masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/app1.cnf
命令的作用参考后面的安装mha部分.

 2.3 配置邮件提醒:

2.3.1 需要send_report脚本, 上官网找或度娘, 一大片.

vim /usr/local/bin/send_report

my $smtp='smtp.126.com';
my $mail_from='xxxx@126.com';
my $mail_user='xxxx@126.com';
my $mail_pass='xxxx';
#my $mail_to=['to1@qq.com','to2@qq.com'];
my $mail_to='xxxx@qq.com';
以上配置项说明在脚本中有注释,可参考
添加执行权限, chmod +x send_report
获取脚本: https://www.cnblogs.com/quzq/p/12969754.html

2.3.2 修改配置文件

vi /etc/mha/app1.cnf
在server default块下添加：
report_script=/usr/local/bin/send_report

2.3.3 重启并查看状态

masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/app1.cnf
命令的作用参考后面的安装mha部分.

 2.4 数据补偿配置

2.4.1 所谓的数据补偿,也就是额外添加的一个node节点, 该节点不会参与mha的选主, 但是必须要求该节点部署的数据库支持gtid功能

1. 在192.168.0.101机器上初始化了一套同版本的mysql, 配置文件中也添加好了配置项, 也配置了systemctl启动.
2. 在该机器上也装了node软件,并根据下面的需要创建了目录.
3. 仅此而已, 没有启动该数据库, 初始化后没有任何操作. (只不过有个/etc/my.cnf文件,里边配置了基本的参数, 不知是否有影响)
.......

2.4.2 manager软件所在机器修改配置文件

binlogserver配置：
找一台额外的机器，必须要有5.6以上的版本，支持gtid并开启
vim /etc/mha/app1.cnf 

[binlog1]
no_master=1　　# 表示不参与选主
hostname=192.168.0.101　　# 该地址不是主库的, 而是用于同步主库二进制的机器地址
master_binlog_dir=/data/master_binlog_back　　# 存放同步过来的日志目录

2.4.2 在101机上创建对应的目录, 开始拉取binlog日志

mkdir /data/master_binlog_back
cd /data/master_binlog_back

mysqlbinlog -R --host=192.168.0.106 --port=3320 --user=mha --password=mha --raw --stop-never master20-bin.000001 &
注意：执行mysqlbinlog命令必须是在配置的master_binlog_back目录下, 不然启动mha会出错(Binlog setting check failed!)
拉取日志的起点,直接按照目前主库在用的日志文件就好.

3. MHA安装步骤

3.1 所有节点都建立软连接

# 建立软连接, 安装目录/bin/{mysqlbinlog,mysql} 链接到/usr/bin/{mysqlbinlog,mysql}
# 3台虚拟机上都执行以下软连接
ln -s /opt/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /opt/mysql/bin/mysql /usr/bin/mysql
注意, 以上两个软连接到的目录不可变,mha只会到/usr/bin/下找.

3.2 所有节点配置互相及验证

# 配置互相, 互信是为了后续数据补偿时免交互
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys    # 密钥管理中规定的名称, 非mha要求
scp -r /root/.ssh 192.168.0.105:/root
scp -r /root/.ssh 192.168.0.103:/root


# 各节点测试(3台虚拟机都执行以下操作)
ssh 192.168.0.106
ssh 192.168.0.105
ssh 192.168.0.103

3.3 下载mha的node软件包, 在所有节点安装

# 下载软件,把manager软件放到3322端口机器上, 所有节点都下载安装node软件
mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
mha4mysql-manager-0.56-0.el6.noarch.rpm
mha4mysql-node-0.56-0.el6.noarch.rpm


# 安装软件包(3虚拟机都安装,root目录下)
yum install perl-DBD-MySQL -y　　# 安装依赖
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm　　# 所有节点安装node软件

3.4 主库上创建用户(3320端口, 主从节点规划参考上面1.1中)

grant all privileges on *.* to mha@'192.168.0.%' identified by 'mha';

3.5 3322节点安装manager软件

yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes  # (安装有可能失败, 多试两次)
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

3.6 manager所在节点定义目录及编辑配置文件

创建配置文件目录(可自定制)
 　　mkdir -p /etc/mha
创建日志目录(可自定制)
 　　mkdir -p /var/log/mha/app1

编辑mha配置文件(配置文件名称可自定制)
　　vim /etc/mha/app1.cnf

[server default]
manager_log=/var/log/mha/app1/manager    # 这个是核心日志,mha运行期间的日志
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/master20/mhabinlog    # 主库的binlog位置,mha中建议所有节点的二进制位置都配置统一
user=mha
password=mha
ping_interval=2    # 定义的监测时间间隔,默认检测3次.
repl_password=123
repl_user=repl
ssh_user=root    #设定的互相账户, 可以使用其它账户
[server1]
hostname=192.168.0.106
port=3320
[server2]
hostname=192.168.0.105
port=3321
[server3]
hostname=192.168.0.103    #以上3各节点的配置顺序决定着主库宕机后谁来接替主库, 默认从上往下
port=3322
一套manager是可以管理多个主从架构的, 就是使用配置文件来区分多个不同的架构.

3.7 (装有manager软件的节点)上互相和主从状态检查, 可不做, 启动时会自动检查

masterha_check_ssh  --conf=/etc/mha/app1.cnf
    # Sat May 23 22:23:46 2020 - [info] All SSH connection tests passed successfully.
masterha_check_repl  --conf=/etc/mha/app1.cnf
    # MySQL Replication Health is OK.

3.8 开启mha(装有manager软件的节点)

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

参数及说明:
开启命令中指定的日志文件只记录启动过程中的日志, 不是用来指定核心日志位置的.
--remove_dead_master_conf  # 表示当master宕机后会自动把master信息从配置文件中去掉
--ignore_last_failover    # 忽略最后一次切换, mha默认两次切换有时间限制, 加上该参数即可随时想切换就切换

3.8 mha状态查看及关闭

# 查看mha状态(装有manager软件的节点)
masterha_check_status --conf=/etc/mha/app1.cnf

# 关闭mha(装有manager软件的节点)
masterha_stop --conf=/etc/mha/app1.cnf