MHA高可用切换工具(2)

检查mha manage是否配置成功
1）检查SSH登陆

[root@db02 ~]# masterha_check_ssh --conf=/etc/mha/appl.cnf ... Sun Jul 10 23:43:10 2016 - [info] All SSH connection tests passed successfully.

2） 检查mysql replication主从复制是否成功

[root@db02 ~]# ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog #所有节点执行 [root@db02 ~]# ln -s /application/mysql/bin/mysql /usr/bin/mysql #所有节点执行 [root@db02 ~]# masterha_check_repl --conf=/etc/mha/appl.cnf ... Mon Jul 11 00:11:14 2016 - [info] Checking replication health on 172.16.2.10.. Mon Jul 11 00:11:14 2016 - [info] ok. Mon Jul 11 00:11:14 2016 - [info] Checking replication health on 172.16.2.10.. Mon Jul 11 00:11:14 2016 - [info] ok. Mon Jul 11 00:06:56 2016 - [warning] shutdown_script is not defined. Mon Jul 11 00:06:56 2016 - [info] Got exit code 0 (Not master dead). MySQL Replication Health is OK.

3） 管理端启动监控和测试启动监控

[root@db02 ~]# 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 & [1] 100414 #--remove_dead_master_conf 该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除 #--ignore_last_failover 在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failover [root@db02 ~]# masterha_check_status --conf=/etc/mha/app1.cnf #查看主库及节点状态 app1 (pid:100414) is running(0:PING_OK), master:172.16.2.10

这里MHA配置就算结束了，我们来试试停掉主库master，模拟故障
此时3308从库兼管理机器上

mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.16.2.10 Master_User: rep Master_Port: 3306 #显示master是3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000023 Read_Master_Log_Pos: 3887 Relay_Log_File: relay-bin.000031 Relay_Log_Pos: 701 Relay_Master_Log_File: mysql-bin.000023 Slave_IO_Running: Yes

我们停掉3306

[root@db02 ~]# mysqladmin -uroot -pli123456 -S /data/3306/mysql.sock shutdown

再来看各同步信息

mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.16.2.10 Master_User: rep Master_Port: 3307 #显示主库已经切换为3307了，而且速度非常快 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 3529 Relay_Log_File: relay-bin.000002 Relay_Log_Pos: 253 Relay_Master_Log_File: mysql-bin.000002

而3307上面，此时已经看不到从库信息了，说明已经被MHA自动变为主库了~

mysql> show slave status\G; Empty set (0.00 sec)

说明：实际工作中，当真的碰到主库宕机，要秒级切换主库时，这种MHA高可用方案涉及到要变更集群架构中DB的IP操作，会影响很多后端web应用，所有我们最好在连接解析数据库时采用解析主机名的方式，一旦主库宕机，MHA重新选出主库以后，我们可以一键分发hosts解析到所有集群节点，减少更改配置的的麻烦，效率还高！