https://www.cnblogs.com/xiaoboluo768/p/5135584.html
环境:
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
修改master_ip_online_change文件中的VIP和绑定网卡:
shell > vim /etc/masterha/master_ip_online_change
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
修改master_ip_online_change文件中的VIP和绑定网卡:
shell > vim /etc/masterha/master_ip_online_change
把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