MHA实践

Myth丶恋晨 2022-06-12 13:48 201阅读 0赞

整个完整的过程为：

一、配置主从

二、配置SSH公钥互信（用ssh-keygen实现三台主机之间相互免密钥登录)

三、下载安装MHA包（MHAmha4mysql-node，mha4mysql-manager）

四、MHA Manager端配置

五、masterha\_check\_ssh工具验证ssh信任登录是否成功

六、masterha\_check\_repl工具验证mysql复制是否成功

七、启动MHA manager,并监控日志文件

八、测试master宕机后，是否会自动切换

九、主从安装keepalived ，实现虚拟ip漂移。

\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#

master 172.31.107.59 \#数据节点

slave    172.31.107.60 \#数据节点

slave    172.31.107.61  \#管理节点和数据节点

1、master 创建生成密钥

\# cd /root/.ssh

\# ssh-keygen -t dsa -P '' -f id\_dsa

\# cat id\_dsa.pub>>authorized\_keys

2、slave 创建生成密钥

\# cd /root/.ssh

\# ssh-keygen -t dsa -P '' -f id\_dsa

\# cat id\_dsa.pub>>authorized\_keys

3、master

拷贝slave上的公钥文件到master

\# scp root@172.31.107.60:/root/.ssh/id\_dsa.pub /root/.ssh/id\_dsa.pub.60

\# scp root@172.31.107.61:/root/.ssh/id\_dsa.pub /root/.ssh/id\_dsa.pub.61

4、master

将 slave 服务器上的公钥追加到master上的 authorized\_keys中

\# cat /root/.ssh/id\_dsa.pub.60>>authorized\_keys

\# cat /root/.ssh/ id\_dsa.pub.61>>authorized\_keys

5、将 master上的authorized\_keys  拷贝到slave上 /root/.ssh 目录下

\# scp /root/.ssh/authorized\_keys 172.31.107.60:/root/.ssh/

\# scp /root/.ssh/authorized\_keys 172.31.107.61:/root/.ssh/

6、

安装MHA所有依赖

yum install perl-DBD-MySQL

yum install perl-Config-Tiny

yum install perl-Log-Dispatch

yum install perl-Parallel-ForkManager

yum install perl-Time-HiRes

yum install perl-CPAN -y

7、

下载安装MHA包并安装 node及master

[https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2][https_code.google.com_p_mysql-master-ha_wiki_Downloads_tm_2]

scp mha4mysql-node-0.56.tar.gz 172.31.107.60:/root

scp mha4mysql-node-0.56.tar.gz 172.31.107.61:/root

scp mha4mysql-manager-0.56.tar.gz 172.31.107.61:/root

\#管理节点上安装

MHA Manager 0.56 tarball源码安装：

tar -zxvf  mha4mysql-manager-0.56.tar.gz

cd mha4mysql-manager-0.56

perl Makefile.PL

make

make install

\#\#mha Manager 安装完成后：在 /usr/local/bin目录下会存在如下文件

masterha\_check\_ssh              检查MHA的SSH配置状况

masterha\_check\_repl             检查MySQL复制状况

masterha\_manger                 启动MHA

masterha\_check\_status           检测当前MHA运行状态

masterha\_master\_monitor         检测master是否宕机

masterha\_master\_switch          控制故障转移（自动或者手动）

masterha\_conf\_host              添加或删除配置的server信息

masterha\_secondary\_check    \#\#也是监测master是否宕机的脚本

masterha\_stop               \#\#关闭MHA

\#所有数据节点上安装

MHA Node 0.56 tarball 源码安装：

tar -zxvf mha4mysql-node-0.56.tar.gz

cd mha4mysql-node-0.56

perl Makefile.PL

make

make install

\#\#mha node 安装完成后会在/usr/local/bin 下面生成以下四个脚本：（这些工具通常由mha manger的脚本触发，无需人工操作）

/usr/local/bin/save\_binary\_logs       \#\#保存和复制master的二进制日志

/usr/local/bin/apply\_diff\_relay\_logs  \#\#识别差异的中继日志事件并将其差异的事件应用于其他slave

/usr/local/bin/filter\_mysqlbinlog     \#\#去除不必要的ROLLBACK事件（MHA已经不再使用这个工具）

/usr/local/bin/purge\_relay\_logs       \#\#清除中继日志（不会阻塞SQL线程

8、

分别登陆master和slave mysql

执行

grant all privileges on \*.\* to root@172.31.107.59 identified by 'fxiaokemysql';

grant all privileges on \*.\* to root@172.31.107.60 identified by 'fxiaokemysql';

grant all privileges on \*.\* to root@172.31.107.61 identified by 'fxiaokemysql';

flush privileges；

\#以上操作是为了避免masterha\_check\_repl 测试不通过（如果是在slave上安装manager）

\# 这里mha的管理账号用的是 root账号，当然也可以自定义一个账号（比如 mha\_repl),这里的账号要和 下列（app1.cnf）配置文件中指定的账  号和密码要一致，否则会报错。

\#比如在 master和slave上分别执行

GRANT SUPER,RELOAD,REPLICATIONCLIENT,CREATE,INSERT,UPDATE,DELETE,DROP ON\*.\* TO mha\_manager@'172.31.107.%' identified by 'fxiaokemysql'

9、172.31.107.61(mha-manager节点）

在MHA manager服务器 添加配置文件 /etc/masterha/app1.cnf。并创建相关目录和修改权限

ln -s /root/mha4mysql-manager-0.56/bin/\* /usr/local/bin/\*

mkdir -p /etc/masterha/app1

touch /etc/masterha/app1/app1.cnf

**vim  /etc/masterha/app1/app1.cnf**

\[server default\]

manager\_workdir=/etc/masterha/app1   \#\#设置manager的工作日志

manager\_log=/etc/masterha/app1/manager.log  \#\#设置manager的日志

user=root \#mha管理账号

password=fxiaokemysql \# mha管理账号 密码

ssh\_user=root \#免密登陆账号

repl\_user=replUser \#复制账号

repl\_password=slave2016 \#复制账号对应的密码

ping\_interval=1 \#\#设置监控主库，发送ping包的时间间隔，默认的是每隔3秒，尝试三次没有回应的时候自动failover

\#remote\_workdir=/masterha/app1   \#\#设置远端mysql在发生切换时保存binlog的具体位置

\#master\_ip\_failover\_script=/etc/masterha/app1/script/master\_ip\_failover

\#master failover时执行,不配置vip时不用配。自动failover时候切换脚本

\#master\_ip\_online\_change\_script=/etc/masterha/app1/master\_ip\_online\_change

\#masterswitchover时执行,不配置vip时不用配。手动failover时候切换脚本

\#shutdown\_script=/etc/masterha/script/power\_manager

\#\#设置故障发生后关闭故障主机脚本（防止发生脑裂）

\#\#一旦MHA 到master 的监控之间网络出现问题，则将尝试从slave1 登陆到master

\#report\_script=/etc/masterha/script/send\_report

\#master failover时执行,可选。设置发生切换后发送的报警的脚本

\#secondary\_check\_script= /root/mha4mysql-manager-0.56/bin/masterha\_secondary\_check -s vlnx107060 -s vlnx107061 \-s  vlnx107059 \--user=root --master\_host= vlnx107059 \--master\_ip=172.31.107.59 --master\_port=3306

\#实现多路由监测Master的可用性

\[server1\]

hostname=172.31.107.59

port=3306

master\_binlog\_dir=/opt/mysql/data/

candidate\_master=1 \#master宕机后，优先启用这台作为新的master

check\_repl\_delay=0

\[server2\]

hostname=172.31.107.60

port=3306

master\_binlog\_dir=/opt/mysql/data/

candidate\_master=1  \#\#设置为候选master，如果设置该参数后，发生主从切换后会将此从库提升为主，即使这个库不是集群中最新的slave

check\_repl\_delay=0 \#\#在默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，此参数会忽略这个限制。

\[server3\]

hostname=172.31.107.61

port=3306

master\_binlog\_dir=/opt/mysql/data/

ignore\_fail=1 \#\#//即便该slave fails，MHA仍旧继续failover。默认情况下,MHA Manager不启动故障转移如果任何从属服务器失败(不能通过MySQL / SSH连接,SQL线程停止与错误等)。但在某些情况下,您可能希望继续故障转移如果只有特定从属服务器失败。通过设置 ignore\_fail=1 在特定的服务器下，MHA继续故障转移虽然这些服务器失败。默认情况下,它是0。

no\_master=1   \#\#设置no\_master=1使主机不能成为新master

![Center][]

检查SSH配置

masterha\_check\_ssh --conf=/etc/masterha/app1/app1.cnf

检查MHA配置

masterha\_check\_repl --conf=/etc/masterha/app1/app1.cnf

如果遇到如下错误提示

运行masterha\_check\_repl --conf=/etc/masterha/app1/app1.cnf

Can't exec "mysqlbinlog": No such file or directory at /usr/local/perl5/MHA/BinlogManager.pm line 99.

解决方法：

需要做一个软连接

ln -s /usr/local/mysql/bin/mysqlbinlog  /usr/bin/mysqlbinlog

注意：

在MHA Manager端配置中，如果实现MHA的vip故障切换需要在配置文件/etc/masterha/app1/app1.cnf 中启用下面三个参数：

master\_ip\_failover\_script= /etc/masterha/app1/scripts/master\_ip\_failover   \#master failover时执行

\#shutdown\_script= /etc/masterha/power\_manager

report\_script= /etc/masterha/app1/scripts/send\_report    \#master failover时执行

master\_ip\_online\_change\_script=/etc/masterha/app1/scripts/master\_ip\_online\_change   \#master switchover时执行

10、

启动MH Manager

nohup masterha\_manager --conf=/etc/masterha/app1/app1.cnf > /etc/masterha/app1/manager.log 2>&1 &

缺省情况下，如果MHA检测到连续发生宕机，且两次宕机时间间隔不足八小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。不过为了自动化，我们往往希望能取消这种限制，此时可以用如下方式启动Manager：

\# nohup masterha\_manager --conf=/etc/masterha/app1/app1.cnf --ignore\_last\_failover --remove\_dead\_master\_conf  >/etc/masterha/app1/mha\_manager.log 2>&1 &

当有slave 节点宕掉时，默认是启动不了的，加上 --ignore\_fail\_on\_start 即使有节点宕掉也能启动MHA，如下：

\# nohup masterha\_manager --conf=/etc/masterha/app1/app1.cnf --ignore\_fail\_on\_start >/etc/masterha/app1/mha\_manager.log 2>&1 &

启动参数介绍：

\--remove\_dead\_master\_conf      该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。

\--manger\_log                            日志存放位置

\--ignore\_last\_failover                 在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore\_last\_failover。

检查MH状态

masterha\_check\_status --conf=/etc/masterha/app1/app1.cnf

可以看见已经在监控了，而且master的主机为172.31.107.59

11、

关闭MH Manager

（masterha\_stop --conf=/etc/masterha/app1/app1.cnf \#关闭时使用的命令）

//**切换**//

**模拟自动切换**

\#\#\#\#启用keepalived+vip的情况下\#\#\#\#修改编辑  /etc/masterha/app1/scripts/master\_ip\_failover

keepalived配置见 <keepalived安装配置>

![Center 1][]

![Center 2][]

登录到 59 服务器

service mysqld stop

这时登录slave执行

show slave status\\G; \#显示 master为 172.31.107.60

或 查看 61 管理节点的log

cat /etc/masterha/app1/manager.log

最后 将 59 上的mysqld重启并将其设置为slave

**注意：**

自动切换完毕后 MHA Manager服务会停止，故需重启启动。

**手动切换MHA （MHA Manager必须没有运行）**

**手动切换MySQL主服务器，可以使用masterha\_master\_switch命令，不过它调用的不是master\_ip\_failover\_script脚本，而是master\_ip\_online\_change\_script脚本，但调用参数类似，脚本可以互用。**

masterha\_master\_switch --conf=/etc/masterha/app1/app1.cnf  --master\_state=dead --dead\_master\_host=172.31.107.59

masterha\_master\_switch --conf=/etc/masterha/app1/app1.cnf --master\_state=alive --new\_master\_host=172.31.107.60;

或者

masterha\_master\_switch  \--conf=/etc/masterha/app1/app1.cnf  --master\_state=dead --dead\_master\_host=172.31.107.59 --dead\_master\_port=3306 --new\_master\_host= 172.31.107.60 --new\_master\_port=3306 --ignore\_last\_failover

![Center 3][]

新的app2.cnf来做check，因为app1.cnf里面的master是原来旧的cnf，check会报错主从复制失败。如何生成新的app2.cnf，很简单，如下所示：

（1）复制原理的app1.cnf为新的app2.cnf

cp /etc/masterha/app1/app1.cnf/etc/masterha/ app1/ app2.cnf

（2）编辑app2.cnf，将里面的server1和server2的ip互换，也就是switch的两个主从的ip换掉

（3）然后在使用  进行check，masterha\_check\_repl --conf=/etc/masterha/app1/app2.cnf 就可以看到switch后的mha的主从是ok的了。

**在线切换**

MHA在线切换的大概过程：

1.检测复制设置和确定当前主服务器

2.确定新的主服务器

3.阻塞写入到当前主服务器

4.等待所有从服务器赶上复制

5.授予写入到新的主服务器

6.重新设置从服务器

注意，在线切换的时候应用架构需要考虑以下两个问题：

1.自动识别master和slave的问题（master的机器可能会切换），如果采用了vip的方式，基本可以解决这个问题。

2.负载均衡的问题（可以定义大概的读写比例，每台机器可承担的负载比例，当有机器离开集群时，需要考虑这个问题）

为了保证数据完全一致性，在最快的时间内完成切换，MHA的在线切换必须满足以下条件才会切换成功，否则会切换失败。

1.所有slave的IO线程都在运行

2.所有slave的SQL线程都在运行

3.所有的show slave status的输出中Seconds\_Behind\_Master参数小于或者等于running\_updates\_limit秒，如果在切换过程中不指定running\_updates\_limit,那么默认情况下running\_updates\_limit为1秒。

4.在master端，通过show processlist输出，没有一个更新花费的时间大于running\_updates\_limit秒。

**在线切换步骤如下：**

首先，停掉MHA监控：

masterha\_stop --conf=/etc/masterha/app1/app1.cnf

其次，进行在线切换操作

masterha\_master\_switch --conf=/etc/masterha/app1/app1.cnf --master\_state=alive --new\_master\_host=172.31.107.60 --new\_master\_port=3306 --orig\_master\_is\_new\_slave --running\_updates\_limit=10000

参数的意思：

\--orig\_master\_is\_new\_slave 切换时加上此参数是将原 master 变为 slave 节点，如果不加此参数，原来的 master 将不启动

\--running\_updates\_limit=10000,故障切换时,候选master 如果有延迟的话， mha 切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover 时relay 日志的大小决定

**注意：**

slave配置参数重要 添加

relay\_log\_purge=0 \# 一主一丛不需要此项，两从及以上建议开次参数，防止切换为成主库的从库自动删除中继日志后，无法给其他从库应用这部分日志。

MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能。定期清除中继日志需要考虑到复制延时的问题。在ext3的文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，需要暂时为中继日志创建硬链接，因为在linux系统中通过硬链接删除大文件速度会很快。（在mysql数据库中，删除大表时，通常也采用建立硬链接的方式）

read\_only=1

log-bin=mysql-bin

log-bin-index=mysql-bin.index

MHA节点中包含了pure\_relay\_logs命令工具，它可以为中继日志创建硬链接，执行SET GLOBAL relay\_log\_purge=1,等待几秒钟以便SQL线程切换到新的中继日志，再执行SET GLOBAL relay\_log\_purge=0。

pure\_relay\_logs脚本参数如下所示：

\--user mysql                      用户名

\--password mysql                  密码

\--port                            端口号

\--workdir                         指定创建relay log的硬链接的位置，默认是/var/tmp，由于系统不同分区创建硬链接文件会失败，故需要执行硬链接具体位置，成功执行脚本后，硬链接的中继日志文件被删除

\--disable\_relay\_log\_purge         默认情况下，如果relay\_log\_purge=1，脚本会什么都不清理，自动退出，通过设定这个参数，当relay\_log\_purge=1的情况下会将relay\_log\_purge设置为0。清理relay log之后，最后将参数设置为OFF。

**设置定期清理relay脚本（两台slave服务器）**

vim /opt/mysql/purge\_relay\_log.sh

\#!/bin/bash

user=root

passwd=fxiaokemysql

port=3306

log\_dir='/opt/mysql/data/masterha/log'

work\_dir='/opt/mysql/data'

purge='/usr/local/bin/purge\_relay\_logs'

if \[ ! -d $log\_dir \]

then

mkdir $log\_dir -p

$purge --user=$user --password=$passwd --disable\_relay\_log\_purge --port=$port --workdir=$work\_dir >> $log\_dir/purge\_relay\_logs.log 2>&1

添加到crontab定期执行

crontab -e

0 4 \* \* \* /bin/bash /opt/mysql/purge\_relay\_log.sh

整个MHA的切换过程，共包括以下的步骤：

1.配置文件检查阶段，这个阶段会检查整个集群配置文件配置

2.宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作（这个我这里还没有实现，需要研究）

3.复制dead maste和最新slave相差的relay log，并保存到MHA Manger具体的目录下

4.识别含有最新更新的slave

5.应用从master保存的二进制日志事件（binlog events）

6.提升一个slave为新的master进行复制

7.使其他的slave连接新的master进行复制

[https_code.google.com_p_mysql-master-ha_wiki_Downloads_tm_2]: https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2
[Center]: /images/20220612/cf881e83e7e44aadb6151a4ea0eeb8a2.png
[Center 1]: /images/20220612/5085ef9df6e74456b19c2d426243dc3c.png
[Center 2]: /images/20220612/d27b9a1760804cdb80a8fce968e92818.png
[Center 3]: /images/20220612/0227883125cc432eae7de2dc4b11e9c7.png