第99讲：MHA高可用集群配置实战：邮件告警和Binlog服务器搭建详解

文章目录 一、配置当MHA故障切换时发生邮件告警1.准备发送邮件的脚本2.配置MHA支持邮箱告警3.重启MHA4.模拟主库故障切换观察邮件接收 二、为MHA高可用集群配置Binlog服务器1.为什么要配置Binlog服务器2.搭建Binlog服务器2.1.创建保存主库Binlog的路径2.2.配置MHA增加Binlog服务器2.3.自动使Binlog服务器拉取主库的Binlog日志2.4.重启MHA2.5.验证Binlog复制的实时性

一、配置当MHA故障切换时发生邮件告警

MHA故障切换是透明的，并且切换完MHA就挂掉了，如果我们不知道，那么在下一次故障时，就无法形成高可用环境了。

因此下面我们来配置当MHA故障切换完成后，就发送一个邮件告警，通知我们去维护MHA。

1.准备发送邮件的脚本 [root@mysql-3 ~]# ll /data/mha/scripts/* -rwxr-xr-x 1 root root 36 7月 9 17:38 /data/mha/scripts/send -rwxr-xr-x 1 root root 80213 9月 30 2009 /data/mha/scripts/sendEmail -rwxr-xr-x 1 root root 203 4月 19 2019 /data/mha/scripts/toemail send脚本内容是调用toemail这个脚本 [root@mysql-3 ~]# cat /data/mha/scripts/send #! /usr/bin/perl -w system"/data/mha/scripts/toemail" toemail脚本内容 [root@mysql-3 ~]# cat /data/mha/scripts/toemail #!/bin/bash /data/mha/scripts/sendEmail -o tls=no -f xxx@163.com -t xxx@163.com -s smtp.163.com:25 -xu user -xp password -u "MHA故障告警" -m "The primary and secondary MySQL replication clusters are abnormal. The MHA switchover has been completed. Repair the MHA in time!" &>/tmp/sendmail.log #改成自己的邮箱发送方和接收方 #我的如下 /data/mha/scripts/sendEmail -o tls=no -f 15910468023@163.com -t 15910468023@163.com -s smtp.163.com:25 -xu 15910468023 -xp MYLOITHAOPLEAAUR -u "MHA故障告警" -m "The primary and secondary MySQL replication clusters are abnormal. The MHA switchover has been completed. Repair the MHA in time!" &>/tmp/sendmail.log 2.配置MHA支持邮箱告警 [root@mysql-3 ~]# vim /data/mha/app1.cnf [server default] ······ report_script=/data/mha/scripts/send 3.重启MHA [root@mysql-3 ~]# masterha_stop --conf=/data/mha/app1.cnf [root@mysql-3 ~]# nohup masterha_manager --conf=/data/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /data/mha/logs/manager.log 2>&1 & 4.模拟主库故障切换观察邮件接收

1）模拟主库故障

1.主库是mysql-2 [root@mysql-3 ~]# masterha_check_status --conf=/data/mha/app1.cnf app1 (pid:13746) is running(0:PING_OK), master:192.168.20.12 2.模拟主库故障 [root@mysql-2 ~]# systemctl stop mysqld

2）正常收到邮件

二、为MHA高可用集群配置Binlog服务器 1.为什么要配置Binlog服务器

在高可用环境中，如果主库故障宕机，从库们无法SSH到主库，如果主从延时较大，可能就会导致数据丢失，因为从库被选举为新的主库后，会获取新主库与故障主库差异的Binlog日志，如果SSH无法连接，此时差异的Binlog就无法获取，就会导致数据丢失。

因此我们可以搭建一个Binlog服务器，专门实时同步主库产生的Binlog日志文件，当主库故障宕机后，MHA直接从Binlog服务器中读取主库的Binlog日志。

2.搭建Binlog服务器

由于服务器有限，直接在mysql-3中搭建一个Binlog服务器。

2.1.创建保存主库Binlog的路径

搭建Binlog服务器，需要在此服务器中准备mysqlbinlog命令工具，这台服务器可以是一个很低配的服务器。

[root@mysql-3 ~]# mkdir /data/mysql_master_binlog [root@mysql-3 ~]# chown -R mysql.mysql /data/mysql_master_binlog 2.2.配置MHA增加Binlog服务器 [root@mysql-3 ~]# vim /data/mha/app1.cnf [binlog1] no_master=1 #此服务器不进行选举 hostname=192.168.20.13 #Binlog服务器的地址 master_binlog_dir=/data/mysql_master_binlog #Binlog日志的路径 2.3.自动使Binlog服务器拉取主库的Binlog日志

通过mha账号，指定从哪个Binlog日志文件开始复制，后面产生的新的Binlog日志文件以及指定的Binlog文件都会持续不断的复制过来，实时复制。

#必须进入到自己创建好的目录 [root@mysql-3 ~]# cd /data/mysql_master_binlog #主库地址一定要指对 [root@mysql-3 mysql_master_binlog]# mysqlbinlog -R --host=192.168.20.12 --user=mha --password=123456 --raw --stop-never mysql-bin.000002 & --stop-never mysql-bin.000002：这个参数表示从mysql-bin.000002这个Binlog开始，包含这个Binlog，以及后面产生了新的Binlog日志都复制到当前路径 从哪个Binlog日志开始复制，一般都是查看从库的状态，看看从库当前读取了主库哪个Binlog日志，从这个Binlog文件开始，包含这个Binlog以及后面产生新的Binlog都会复制过来。 2.4.重启MHA [root@mysql-3 ~]# masterha_stop --conf=/data/mha/app1.cnf [root@mysql-3 ~]# nohup masterha_manager --conf=/data/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /data/mha/logs/manager.log 2>&1 & 2.5.验证Binlog复制的实时性

主库多刷新几个Binlog，观察Binlog服务器是否会复制过来。

经过我们一点点的深造，目前MHA的架构为：MHA+VIP漂移地址+Send邮件告警+BinlogServer