mha的搭建步骤(一主一从架构)

时间:2022-08-16 06:33:01

所需脚本文件到这里下载:http://note.youdao.com/share/web/file.html?id=ae8b11a61f7a8aa7b52aac3fcf0c4b83&type=note

环境:

centos 6.5 x64

192.168.0.32  # master

192.168.0.33  #管理节点和从节点slave

VIP:192.168.0.62

iptables打开mysql端口

selinx关闭:

shell > vim /etc/selinux/config

SELINUX=disabled

1.安装mysql 5.5.x以上的版本(如果是5.6以上的版本,不建议开启GTID复制),并搭建好双主复制,复制用户:repl,复制用户密码:123456

主从复制搭建好后,从库执行下面两个命令(不要加入到my.cnf中,因为从库随时可能被提升为master)

mysql -e 'set global read_only=1;set global relay_log_purge=0;'

如果是刚刚初始化安装完成的mysql,建议进行安全清理:

mysql > delete from mysql.user where user!='root' or host !='localhost';

mysql > truncate table mysql.db;

mysql > drop database test;

mysql > flush privileges;

2.所有服务器之间建立ssh互信(如果管理节点和数据节点共用,要自己能免密钥登录自己):

在master上:

shell > ssh-keygen -t rsa  #创建密钥

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.33  #发送ssh密钥到其他服务器

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.32  #发送ssh密钥到自己

在slave上:

shell > ssh-keygen -t rsa  #创建密钥

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.32  #发送ssh密钥到其他服务器

shell > ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.33  #发送ssh密钥到自己

3.安装epel源(所有节点):

shell > rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm
shell > rpm -ivh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

4.安装mha(一主一从的架构建议两个节点都安装manager和node包)

MHA的配置,只需要在manager节点上配置即可正常工作,配置文件最少一个,一般可以分成两个部分,这样一个manager管理多个集群时可以少写一点配置(当然,为了方便故障时快速恢复manager,可以在备主上也进行配置一,只是需要把配置里的主动关系做对应修改):

master:

shell > yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y

解压mha_packge.zip:
shell > cd packge

shell > rpm -Uvh mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm

shell > cp -ar masterha /etc/

shell > mkdir /var/log/masterha/app1 -p

slave安装:

shell > yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes -y

解压mha_packge.zip:
shell > cd packge

shell > rpm -Uvh mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm

shell > cp -ar masterha /etc/

shell > mkdir /var/log/masterha/app1 -p

5.配置Mha

master(master中的MHA配置只是用来做备用的,不需要启动管理节点,在主库切换成从库之后,就可以快速切换管理节点,不需要重新配置),全局配置文件内容如下:

shell > cd /etc/masterha

shell > cat masterha_default.conf  #修改全局配置文件

[server default]

#MySQL的用户和密码

user=root

password=4testHIGH

#系统ssh用户

ssh_user=root

#复制用户

repl_user=repl

repl_password= 123456

#监控

ping_interval=1

#shutdown_script=""

#切换调用的脚本

master_ip_failover_script= /etc/masterha/master_ip_failover

master_ip_online_change_script= /etc/masterha/master_ip_online_change

修改集群配置文件:

shell > cat app1.conf

[server default]

user=root

password=4testHIGH

#mha manager工作目录

manager_workdir = /var/log/masterha/app1

manager_log = /var/log/masterha/app1/app1.log

remote_workdir = /var/log/masterha/app1

[server1]

hostname=192.168.0.33  #主库的配置上,把从库写成主节点

master_binlog_dir = /data/mysql/data

port=3306

[server2]

hostname=192.168.0.32 #主库的配置上,把主库写成备节点

master_binlog_dir=/data/mysql/data

port=3306

candidate_master=1

check_repl_delay = 0     #用防止master故障时,切换时slave有延迟,卡在那里切不过来。

注:如果有一主多从架构,那么只需要在app1/conf文件后面再多添加几个配置即可,类似如下:

[server3]

hostname=192.168.0.x

port=3306

master_binlog_dir=/data/mysql/data

 

6.修改master_ip_failover文件中的VIP和绑定网卡

shell > vim /etc/masterha/master_ip_failover

mha的搭建步骤(一主一从架构)

修改master_ip_online_change文件中的VIP和绑定网卡:

shell > vim /etc/masterha/master_ip_online_change

mha的搭建步骤(一主一从架构)

7.把drop_vip.sh和init_vip.sh中的网卡和VIP都改过来

把脚本赋予执行权限:shell > chmod +x drop_vip.sh init_vip.sh master_ip_*

8.这里我为了故障时能快速恢复MHA管理节点,在备主(slave)上也配置了manager,但是不启动:

shell > cd /etc/masterha

shell > cat masterha_default.conf  #修改全局配置文件

[server default]

#MySQL的用户和密码

user=root

password=4testHIGH

#系统ssh用户

ssh_user=root

#复制用户

repl_user=repl

repl_password= 123456

#监控

ping_interval=1

#shutdown_script=""

#切换调用的脚本

master_ip_failover_script= /etc/masterha/master_ip_failover

master_ip_online_change_script= /etc/masterha/master_ip_online_change

修改集群配置文件:

shell > cat app1.conf

[server default]

user=root

password=4testHIGH

#mha manager工作目录

manager_workdir = /var/log/masterha/app1

manager_log = /var/log/masterha/app1/app1.log

remote_workdir = /var/log/masterha/app1

[server1]

hostname=192.168.0.32 #从库上的配置,主库就是主节点

master_binlog_dir = /data/mysql/data

port=3306

[server2]

hostname=192.168.0.33 #从库上的配置,从库就是备节点

master_binlog_dir=/data/mysql/data

port=3306

candidate_master=1

check_repl_delay = 0     #用防止master故障时,切换时slave有延迟,卡在那里切不过来。

修改master_ip_failover文件中的VIP和绑定网卡

shell > vim /etc/masterha/master_ip_failover

mha的搭建步骤(一主一从架构)

修改master_ip_online_change文件中的VIP和绑定网卡:

shell > vim /etc/masterha/master_ip_online_change

mha的搭建步骤(一主一从架构)

把drop_vip.sh和init_vip.sh中的网卡和VIP都改过来

把脚本赋予执行权限:shell > chmod +x drop_vip.sh init_vip.sh master_ip_*

9.配置文件测试(一主一从架构的主库和从库上的管理节点建议都要进行测试,不单单只测试从库上的管理节点):

测试ssh连通性:

shell > masterha_check_ssh --conf=/etc/masterha/app1.conf

注意:如果你是用虚拟机做实验,很可能碰到这步骤报错,碰到两边都无法ssh或者一边可以,一边不可以,此时,可以重新创建密钥试试,如果多次尝试仍然不行,那么就把发起ssh连接而失败的虚拟机换一台再试。或者,看看你的架构是不是把管理节点和数据节点放一起,而管理节点上又没有配置自己到自己免密钥登录。

看到最后提示:[info] All SSH connection tests passed successfully.表示测试通过

测试集群中的主从复制:

shell > masterha_check_repl --conf=/etc/masterha/app1.conf  --global_conf=/etc/masterha/masterha_default.conf

注意:执行这个检测命令的时候使用的是user=root帐号去检测,注意user=root帐号也要有远程权限,另外,把mysql目录下的命令做个链接:ln -s /usr/local/mysql/bin/* /usr/bin/

看到最后提示:MySQL Replication Health is OK.表示测试通过

10.启动管理节点(只在从库上启动管理节点):

启动管理节点最好使用screen启动:

shell > nohup masterha_manager --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf  --remove_dead_master_conf --ignore_last_failover> /tmp/mha_manager.log 2>&1 &

sh /etc/masterha/init_vip.sh
确认VIP 绑定成功,如果业务按VIP 配置的访问DB,应该已经可以正常访问

注意:
第一次起动,主库上的VIP 不会自动绑定,需要手功调用init_vip.sh 去绑定,主库发生故障切换会进行vip 的漂移

11.启动之后查看控制台输出日志:

/tmp/mha_manager.log

查看app1日志输出:

/var/log/masterha/app1/app1.log

查看master的健康状况日志:

/var/log/masterha/app1/app1.master_status.health

检查是否启动成功:

shell > masterha_check_status --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

12.切换测试:

1).在线手工切换(维护切换,需要把MHA监控进程关掉):

shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.0.33 --orig_master_is_new_slave --running_updates_limit=10000

--orig_master_is_new_slave:把旧的master配置为从库

--running_updates_limit=10000:如果主从库同步延迟在10000s内都允许切换,但是但是切换的时间长短是由recover时relay 日志的大小决定

切换成功需要看到类似下面的提示:

info] Switching master to 192.168.0.33(192.168.0.33:3306) completed successfully

同时要查看VIP是否已经漂移到了新的主库上面

2).故障手工切换(MHA进程没启动或者挂了的同时主库也挂了):

shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --dead_master_host=old_ip --master_state=dead --new_master_host=new_ip --ignore_last_failover

切换成功需要看到类似如下提示:

Started manual(interactive) failover.

Invalidated master IP address on 192.168.0.32(192.168.0.32:3306)

The latest slave 192.168.0.33(192.168.0.33:3306) has all relay logs for recovery.

Selected 192.168.0.33(192.168.0.33:3306) as a new master.

192.168.0.33(192.168.0.33:3306): OK: Applying all logs succeeded.

192.168.0.33(192.168.0.33:3306): OK: Activated master IP address.

Generating relay diff files from the latest slave succeeded.

192.168.0.33(192.168.0.33:3306): Resetting slave info succeeded.

Master failover to 192.168.0.33(192.168.0.33:3306) completed successfully.

注意:如果是主库服务器还活着,只是mysqld挂了的时候,VIP在切换的时候也会自动漂移,如果是服务器挂了,那么在挂掉的主库重启后,注意不要让VIP随开机启动,因为此时VIP已经漂移到了从库上,从库上可能正在接管业务,故障主库起来后,需要确认数据是否跟新的主库一样,如果一样,那么就把故障主库作为新的从库加入新主库下

3).故障自动切换(启动MHA监控进程)手动把主库mysqld停掉,观察/var/log/masterha/app1.log日志输出,看到如下信息:

Started automated(non-interactive) failover.

Invalidated master IP address on 192.168.0.32(192.168.0.32:3306)

The latest slave 192.168.0.33(192.168.0.33:3306) has all relay logs for recovery.

Selected 192.168.0.33(192.168.0.33:3306) as a new master.

192.168.0.33(192.168.0.33:3306): OK: Applying all logs succeeded.

192.168.0.33(192.168.0.33:3306): OK: Activated master IP address.

Generating relay diff files from the latest slave succeeded.

192.168.0.33(192.168.0.33:3306): Resetting slave info succeeded.

Master failover to 192.168.0.33(192.168.0.33:3306) completed successfully.

表示成功切换,切换成功后,查看VIP是否漂移到了从库上(切换成功后,MHA进程会自动停止),同时查看/etc/masterha/app1.conf文件中的[server1]的配置是否都被删除掉了

故障主库起来后,需要确认数据是否跟新的主库一样,如果一样,那么就把故障主库作为新的从库加入新主库下。然后在故障主库上启动MHA进程。

附:

MHA 日常维护命令集:

1).查看ssh 登陆是否成功
shell > masterha_check_ssh --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf
2).查看复制是否建立好
shell > masterha_check_repl --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

3).检查启动的状态
shell > masterha_check_status--global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

4).停止mha
shell > #masterha_stop --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf

5).启动mha
shell > nohup masterha_manager --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf > /tmp/mha_manager.log < /dev/null 2>&1 &

注意:当有slave 节点宕掉的情况是启动不了的,加上--ignore_fail_on_start 即使有节点宕掉也能启动mha,需要在配置文件中设置ignore_fail=1

6).failover 后下次重启
每次failover 切换后会在管理目录生成文件app1.failover.complete ,下次在切换的时候会发现有这个文件导致切换不成功,需要手动清理掉。
shell > rm -rf /masterha/app1/app1.failover.complete
也可以加上参数--ignore_last_failover

7).手工failover
手工failover 场景,master 死掉,但是masterha_manager 没有开启,可以通过手工failover:
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --dead_master_host=old_ip --master_state=dead --new_master_host=new_ip --ignore_last_failover

8).masterha_manager 是一种监视和故障转移的程序。另一方面,masterha_master_switch 程序不监控主库。masterha_master_switch 可以用于主库故障转移,也可用于在线总开关。

9).手动在线切换(master还或者,比如做维护切换时)
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.199.78 --orig_master_is_new_slave
或者
shell > masterha_master_switch --global_conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf --master_state=alive --new_master_host=192.168.199.78 -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 日志的大小决定

手动在线切换mha,切换时需要将在运行的mha 停掉后才能切换。
在备库先执行DDL,一般先stop slave,一般不记录mysql 日志,可以通过set SQL_LOG_BIN =0 实现。然后进行一次主备切换操作,再在原来的主库上执行DDL。这种方法适用于增减索引,如果是增加字段就需要额外注意。

注意:Online master switch 开始只有当所有下列条件得到满足。
1). IO threads on all slaves are running // 在所有slave 上IO 线程运行。
2). SQL threads on all slaves are running //SQL 线程在所有的slave 上正常运行。
3). Seconds_Behind_Master on all slaves are less or equal than --running_updates_limit
seconds // 在所有的slaves 上Seconds_Behind_Master 要小于等于running_updates_limit
seconds
4). On master, none of update queries take more than --running_updates_limit seconds in the
show processlist output // 在主上,没有更新查询操作多于running_updates_limit seconds