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 mha172.16.1.5
master.zou.com master172.16.1.7
slave1.zou.com slave1172.16.1.9
slave2.zou.com slave2
各方面测试主机名可以互相ping通，如：[root@mha ~]# ping slave2PING 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连接各节点基于秘钥[root@mha ~]# ssh-keygen -t rsa -P ''[root@mha ~]# ssh-copy-id -i .ssh/id_rsa.pub root@master[root@mha ~]# ssh-copy-id -i .ssh/id_rsa.pub root@slave1[root@mha ~]# ssh-copy-id
-i .ssh/id_rsa.pub root@slave2master连接个点基于秘钥[root@master ~]# ssh-keygen -t rsa -P ''[root@master ~]# ssh-copy-id -i .ssh/id_rsa.pub root@mha[root@master ~]# ssh-copy-id -i .ssh/id_rsa.pub root@slave1[root@master ~]#
ssh-copy-id -i .ssh/id_rsa.pub root@slave2slave1连接各个节点基于秘钥[root@slave1 ~]# ssh-keygen -t rsa -P ''[root@slave1 ~]#
ssh-copy-id -i .ssh/id_rsa.pub root@mha[root@slave1 ~]# ssh-copy-id -i .ssh/id_rsa.pub root@master[root@slave1 ~]# ssh-copy-id -i .ssh/id_rsa.pub root@salve2slave2连接各个节点基于秘钥[root@slave2 ~]# ssh-keygen -t rsa -P ''[root@slave2 ~]#
ssh-copy-id -i .ssh/id_rsa.pub root@mha[root@slave2 ~]#
ssh-copy-id -i .ssh/id_rsa.pub root@master[root@slave2 ~]#
ssh-copy-id -i .ssh/id_rsa.pub root@slave1 注：其实这个4个服务器彼此之间使用秘钥认证可以使用同一对私钥要公钥来进行认证，这样方便用ansible来进行推送 二、mysql主从复制配置配置各节点的my.cnf，并成功启动服务[root@master ~]# vim /etc/my.cnfinnodb_file_per_table=ONskip_name_resolve=ONserver_id=1log_bin=bin-logrelay_log=relay-log[root@master ~]# 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;


从节点配置[root@slave1 ~]# vim /etc/my.cnfserver_id=101log_bin=bin-logrelay_log=relay-logskip_name_resolve=ONinnodb_file_per_table=ONread_only=ON[root@slave1 ~]# 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;
另一个从节点配置[root@slave2 ~]# vim /etc/my.cnfserver_id=201log_bin=bin-logrelay_log=relay-logskip_name_resolve=ONinnodb_file_per_table=ONread_only=ON[root@slave2 ~]# 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 slaveMariaDB [(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源 主节点安装：[root@mha ~]# yum install mha4mysql-*.rpm [root@mha ~]# mkdir /etc/masterha[root@mha ~]# vim /etc/masterha/app1.conf每一个独立的应用程序应该使用各自的应用配置[server default]user=mhaadmin 这个和授权mha程序使用的用户和密码有关，要和主节点定义一致password=mhapassmanager_workdir=/data/masterha/app1manager_log=/data/masterha/app1/manager.logremote_workdir=/data/masterha/app1ssh_user=rootrepl_user=repluser 这个是和mysql主从复制时的授权用户和密码有关系repl_password=123.comerping_interval=2 多长时间ping一次主节点，看是否宕机 [server1]hostname=172.16.1.5candidate_master=1 是否可以为主节点，第一个配置即为主节点 [server2]hostname=172.16.1.7candidate_master=1 是否可以成为主节点，主的挂了，它可以补上 [server3]hostname=172.16.1.9candidate_master=1测试配置文件是否有问题（这里主要是测试基于秘钥ssh的认证）[root@mha ~]# 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包[root@master ~]# yum install
mha4mysql-node-0.56-0.el6.noarch.rpm -y[root@slave1 ~]# yum install
mha4mysql-node-0.56-0.el6.noarch.rpm -y[root@slave2 ~]# yum
install mha4mysql-node-0.56-0.el6.noarch.rpm -y 在主节点上检查repl配置是否成功[root@mha ~]# masterha_check_repl
--conf=/etc/masterha/app1.confMySQL 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';
再次检查配置[root@mha ~]# masterha_check_repl
--conf=/etc/masterha/app1.conf.....MySQL Replication Health is OK.好了，没有问题了
启动进程，因为没有程序脚本，只能送往后台，同时剥离终端与进程的关系[root@mha masterha]# nohup master_manager
--conf=/etc/masterha/app1.conf > /data/masterha/app1/manager.log 2>&1
&[1] 16767
查看日志文件是否正常收录日志[root@mha 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服务[root@master ~]# killall -9 mysqld mysqld_safe查看日志：[root@mha 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 之后）上线：[root@master ~]# systemctl start mariadb.service（新）主节点完全备份，恢复数据到（旧主）节点上面，之后在chage master to....[root@master ~]# 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上再次启动健康转移服务：[root@mha masterha]# nohup masterha_manager
--conf=/etc/masterha/app1.conf > /data/masterha/app1/manager.log 2>&1
&[1] 17568
[root@mha masterha]# tail -20 /data/masterha/app1/manager.log Mon Sep 5 22:21:48
2016 - [info] Connecting to
root@172.16.1.9(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
[root@one ~]# systemctl restart zabbix-agent.service设置host

设置items

设置trigger

设置动作





准备上面的脚本：[root@mha ~]# cat manager.shnohup masterha_manager
--conf=/etc/masterha/app1.conf > /data/masterha/app1/manager.log
2>&1 & 测试zabbix是否根据设置的事务动作，完成脚本的调用，完成manager的后台启动关闭nohup执行的进程用kill -9 +id 这个id号需要查询一下先之后手动抓取一次：[root@mha app1]zabbix_get -s 172.16.1.1 -k masterha.manager2

再次手动抓起一次：[root@mha app1]zabbix_get -s 172.16.1.1 -k masterha.manager0这里显示的是0了，同时通过ps命令可以查看这个进程确实已经自动启动了，于是我们zabbix监控manger完成自动启动也就做完了