MHA动态管理主从复制并结合zabbix完成监控

Posted 2020-08-07

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MHA动态管理主从复制并结合zabbix完成监控相关的知识，希望对你有一定的参考价值。

MHA节点：会通过监控到的master节点故障时，会提升其中用于最新数据的slave节点成为新的master节点，在此期间，MHA会通过其他从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点的在线切换功能，即按需切换master/slave节点。

注：不过，这个正常使用在centos6上面创建是没有问题的，但是要是centos7上面安装没什么问题，基本使用也可以，但是不知道在生产环境中的坑有没有，所以还望大家甄别。

实验环境：四台centos7

主机ip 功用部署简略主机名

172.16.1.1 MHA manager mha mha.zou.com 同时zabbix主和客户端

172.16.1.5 mariadb master master master.zou.com

172.16.1.7 slave slave1 slave1.zou.com

172.16.1.9 slave slave2 slave2.zou.com

一、前提准备

设置完每个主机的主机名，并在每台主机的hots文件里写入：

172.16.1.1 mha.zou.com mha

172.16.1.5 master.zou.com master

172.16.1.7 slave1.zou.com slave1

172.16.1.9 slave2.zou.com slave2

各方面测试主机名可以互相ping通，如：

[[email protected] ~]# ping slave2

PING slave2.zou.com (172.16.1.9) 56(84) bytes of data.

64 bytes from slave2.zou.com (172.16.1.9): icmp_seq=1 ttl=64 time=2.15 ms

时间同步设置

我们可以使用 chrony搭建时间同步服务器，这个在主从复制基于ssl我们已经提到了这里用另一个简单的方法，直接通过命令去向某个时间服务器上同步即可，可以结合crontab

下面这条命令4台服务器都要执行

~】# ntpdate 172.16.0.1

之后在每台上面crontab -e 加入01 * * * * /usr/sbin/ntpdate 172.16.0.1 来保证时间同步

设置用户基于秘钥登录（无需密码）

注：这里要确保每个节点之间彼此都可以无密码操作，所以比较麻烦

mha连接各节点基于秘钥

[[email protected] ~]# ssh-keygen -t rsa -P ‘‘

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]2

master连接个点基于秘钥

[[email protected] ~]# ssh-keygen -t rsa -P ‘‘

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]2

slave1连接各个节点基于秘钥

[[email protected] ~]# ssh-keygen -t rsa -P ‘‘

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]master

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]salve2

slave2连接各个节点基于秘钥

[[email protected] ~]# ssh-keygen -t rsa -P ‘‘

[[email protected] ~]# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

注：其实这个4个服务器彼此之间使用秘钥认证可以使用同一对私钥要公钥来进行认证，这样方便用ansible来进行推送

二、mysql主从复制配置

配置各节点的my.cnf，并成功启动服务

[[email protected] ~]# vim /etc/my.cnf

innodb_file_per_table=ON

skip_name_resolve=ON

server_id=1

log_bin=bin-log

relay_log=relay-log

[[email protected] ~]# systemctl start mariadb.service

主节点授权

MariaDB [(none)]> grant replication client,replication slave on *.* to ‘repluser‘@‘172.16.1.%‘ identified by ‘123.comer‘;

MariaDB [(none)]> flush privileges;

从节点配置

[[email protected] ~]# vim /etc/my.cnf

server_id=101

log_bin=bin-log

relay_log=relay-log

skip_name_resolve=ON

innodb_file_per_table=ON

read_only=ON

[[email protected] ~]# systemctl start mariadb.service

从节点找主节点

MariaDB [(none)]> change master to master_host=‘172.16.1.5‘,master_user=‘repluser‘,master_password=‘123.comer‘,master_log_file=‘bin-log.000005‘,master_log_pos=497;

另一个从节点配置

[[email protected] ~]# vim /etc/my.cnf

server_id=201

log_bin=bin-log

relay_log=relay-log

skip_name_resolve=ON

innodb_file_per_table=ON

read_only=ON

[[email protected] ~]# systemctl start mariadb.service

另一个从节点找主节点

MariaDB [(none)]> change master to master_host=‘172.16.1.5‘,master_user=‘repluser‘,master_password=‘123.comer‘,master_log_file=‘bin-log.000005‘,master_log_pos=497;

之后两个从节点，先后start slave

MariaDB [(none)]> start slave;

主从复制没有问题后，在主节点授权用户给mha程序使用（因为主从已成，这里执行，从的也就成了）

MariaDB [(none)]> grant all on *.* to ‘mhaadmin‘@‘172.16.1.%‘ identified by ‘mhapass‘;

MariaDB [(none)]> flush privileges;

三、安装MHA

注：我这里使用的是适用于centos6的，主要是现在MHA活跃比较慢，还没有出支持centos7的，但是整体的使用在配置和使用上面没有问题，就是不知道再生产环境中会出什么差错，如果要使用MHA的话，建议还是暂时使用centos6比较好；这里实验继续走的是centos7上面的配置

安装包如下：代码项目在github当中

mha4mysql-node-0.56-0.el6.noarch.rpm 所有节点节点安装，安装需要epel源

mha4mysql-manager-0.56-0.el6.noarch.rpm 只有manager节点安装，安装需要epel源

主节点安装：

[[email protected] ~]# yum install mha4mysql-*.rpm

[[email protected] ~]# mkdir /etc/masterha

[[email protected] ~]# vim /etc/masterha/app1.conf

每一个独立的应用程序应该使用各自的应用配置

[server default]

user=mhaadmin 这个和授权mha程序使用的用户和密码有关，要和主节点定义一致

password=mhapass

manager_workdir=/data/masterha/app1

manager_log=/data/masterha/app1/manager.log

remote_workdir=/data/masterha/app1

ssh_user=root

repl_user=repluser 这个是和mysql主从复制时的授权用户和密码有关系

repl_password=123.comer

ping_interval=2 多长时间ping一次主节点，看是否宕机

[server1]

hostname=172.16.1.5

candidate_master=1 是否可以为主节点，第一个配置即为主节点

[server2]

hostname=172.16.1.7

candidate_master=1 是否可以成为主节点，主的挂了，它可以补上

[server3]

hostname=172.16.1.9

candidate_master=1

测试配置文件是否有问题（这里主要是测试基于秘钥ssh的认证）

[[email protected] ~]# masterha_check_ssh --conf=/etc/masterha/app1.conf

出现Mon Sep 5 21:21:07 2016 - [info] All SSH connection tests passed successfully.则基本没有问题，这里如果落下某行，只要是ssh基于秘钥认证没问题还是不会报错，所以还要当心，不要写错，同时有问题时，注意去里面拍错，查看其它配置是否有误

各节点安装相关mha-node包

[[email protected]master ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y

[[email protected] ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y

在主节点上检查repl配置是否成功

[[email protected] ~]# masterha_check_repl --conf=/etc/masterha/app1.conf

MySQL Replication Health is NOT OK!有错，

报错如下：

Mon Sep 5 21:33:11 2016 - [error][/usr/share/perl5/vendor_perl/MHA/Server.pm, ln393] 172.16.1.9(172.16.1.9:3306): User repluser does not exist or does not have REPLICATION SLAVE privilege! Other slaves can not start replication from this host.

出现这个问题，主要是我们在一开始授权用户的时候，从节点还没有开启复制呢，所以没有办法复制到从节点，这里的做法儿有两种，都不难

第一种：

在主节点上删除‘repluser用户，也就是刚才主从复制的授予复制权限的用户，之后再重新建一遍，这次就可以复制到从节点了，因为主从复制已经ok了

第二种：

在从节点上直接在执行上面主从复制时的sql语句，每个可以成为主节点的从节点上面都要执行

因为我上面一主两从的candidate_master都为1，都可以成为主节点，于是其他两个从节点都要执行：

slave1上面

MariaDB [(none)]> grant replication client,replication slave on *.* to ‘repluser‘@‘172.16.1.%‘ identified by ‘123.comer‘;

slave2上面

MariaDB [(none)]> grant replication client,replication slave on *.* to ‘repluser‘@‘172.16.1.%‘ identified by ‘123.comer‘;

再次检查配置

[[email protected] ~]# masterha_check_repl --conf=/etc/masterha/app1.conf

.....

MySQL Replication Health is OK.

好了，没有问题了

启动进程，因为没有程序脚本，只能送往后台，同时剥离终端与进程的关系

[[email protected] masterha]# nohup master_manager --conf=/etc/masterha/app1.conf > /data/masterha/app1/manager.log 2>&1 &

[1] 16767

查看日志文件是否正常收录日志

[[email protected] masterha]# tail /data/masterha/app1/manager.log

这里会报告：

[warning] master_ip_failover_script is not defined. 没有定义浮动ip，如果发生了主节点挂了，这需要我们手动执行ip改变，但是如果使用脚本写个浮动ip，哪个为主就在哪配置，

[warning] secondary_check_script is not defined. 没有第二监测脚本，这个脚本是相当于stonish设备的，当监测到节点挂了，就采取行动

四、测试故障转移

（1）在master节点上面关闭mariadb服务

[[email protected] ~]# killall -9 mysqld mysqld_safe

查看日志：

[[email protected] masterha]# tail /data/masterha/app1/manager.log

当有主从复制的主节点发生宕机的时候会有从的提升为主的

同时在终端上面出现[1]+ 完成 nohup masterha_manager --conf=/etc/masterha/app1.conf > /data/masterha/app1/manager.log 2>&1

上面红色是出现说明我们的mha完成了任务，尴尬的是如果再有主节点挂了，就不能完成自动切换了，因为这个进程已经跑完了，所以我们还要设置机制让这个后台进程再次执行一遍，重新启动，而且启动并不是单纯的执行上面红色的nohup开头的命令，此时的mha的配置文件因为主从发生了变化，这个配置文件也应该调整一下主从节点的配置信息，把原先的主改为从，把从成为主的服务配置由从该外主

所以

当原先的主节点再次上线（如今已经为从，准确来说是执行完change master to 之后）

上线：[[email protected] ~]# systemctl start mariadb.service

（新）主节点完全备份，恢复数据到（旧主）节点上面，之后在chage master to....

[[email protected] ~]# mysql <new_latest.sql 这是在新主节点行备份来的，记得备份时刷新二进制日志，同时查看备份后主节点的状态

在新的主节点上查看

从加主复制：

MariaDB [(none)]> change master to master_host=‘172.16.1.7‘,master_user=‘repluser‘,master_password=‘123.comer‘,master_log_file=‘bin-log.000004‘,master_log_pos=422;

MariaDB [(none)]> start slave;

MariaDB [(none)]> show slave status/G

可以创建个库或者插入个表，测试一下主的变化了，这个新加进来的从是否会发生变化

之后在mha上再次启动健康转移服务：

[[email protected] masterha]# nohup masterha_manager --conf=/etc/masterha/app1.conf > /data/masterha/app1/manager.log 2>&1 &

[1] 17568

[[email protected] masterha]# tail -20 /data/masterha/app1/manager.log

Mon Sep 5 22:21:48 2016 - [info] Connecting to [email protected](172.16.1.9:22)..

Checking slave recovery environment settings..

Opening /var/lib/mysql/relay-log.info ... ok.

Relay log found at /var/lib/mysql, up to relay-log.000002

Temporary relay log file is /var/lib/mysql/relay-log.000002

Testing mysql connection and privileges.. done.

Testing mysqlbinlog output.. done.

Cleaning up test file(s).. done.

Mon Sep 5 22:21:49 2016 - [info] Slaves settings check done.

Mon Sep 5 22:21:49 2016 - [info]

172.16.1.7(172.16.1.7:3306) (current master)

+--172.16.1.5(172.16.1.5:3306)

+--172.16.1.9(172.16.1.9:3306)

Mon Sep 5 22:21:49 2016 - [warning] master_ip_failover_script is not defined.

Mon Sep 5 22:21:49 2016 - [warning] shutdown_script is not defined.

Mon Sep 5 22:21:49 2016 - [info] Set master ping interval 2 seconds.

Mon Sep 5 22:21:49 2016 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.

Mon Sep 5 22:21:49 2016 - [info] Starting ping health check on 172.16.1.7(172.16.1.7:3306)..

Mon Sep 5 22:21:49 2016 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn‘t respond..

上面显示为正常没有问题

注：如果这个时候再去操作，就可能会报错，主要是操作切换挺频繁，按提示走就行了，这样就没有问题了

同时为了manager能够在迁移完主节点能够自动启动

方法一：我们可以设置脚本结合crond监控，来完成自动启动

方法二：可以使用zabbix监控，完成manager自动启动

五、zabbix监控mha服务器，完成manager自动启动

这里就不演示zabbix server 和客户端的安装了，我在mha主机上同时安装了zabbix server，同时安装客户端端进行监控，监控我们刚才设置的nohup启动的manager监控管理进程，一旦发现这个后台命令执行结束了，立即通过zabbix里面设置的条件和触发器，来调用脚本，使得manager进程始终运行在mha上。

在agent需要完成的配置：

(1) zabbix用户拥有所需要的管理权限；

编辑/etc/sudoers文件，注释如下行；

#Defaults requiretty （加上#号，就停止了只有可登陆用户才能执行命令；因为系统默认是要能够通过tty登陆的用户，执行命令的，zabbix没有可以登录系统的权限，所以要把这个注释，或者只允许zabbix一个非登录系统用户可以执行命令，也就是下面一行了：

更加安全的写法为 Defaults zabbix！requiretty

添加如下行：

zabbix ALL=(ALL) NOPASSWD: ALL（这样较为不安全，最好写下面的，用到这么命令就将其写到什么命令）

zabbix ALL=(ALL) NOPASSWD:/usr/bin/systemctl start httpd.service

(2) agent进程要允许执行远程命令；

编辑/etc/zabbix/zabbix_agentd.conf，设置如下配置：

EnableRemoteCommands=1

UserParameter=masterha.manager,[ `/usr/bin/ps aux | /usr/bin/grep -v grep | /usr/bin/grep -o masterha_manager` == masterha_manager ] &> /dev/null ;echo $?

注：这里这这一行是监测后端程序，如果存在就是0，如果不存在就会显示大于0的数，这里为2

[[email protected] ~]# systemctl restart zabbix-agent.service

设置host