MHA+MySQL实现mysql高可用
发布时间：2023-02-16 13:19:04 所属栏目：MySql 来源：互联网
导读：1. MHA的简单介绍 简介 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MysqL高可用性环境下故障切换和主从提升的高可用软件。在MysqL故障切换
|
Resetting slave 192.168.142.48(192.168.142.48:5700) and starting replication from the new master 192.168.142.49(192.168.142.49:5700).. 6、清理新master的相关信息 192.168.142.49: Resetting slave info succeeded 10. 自动故障切换过程 1、首先需要保证mha manager处于运行状态 nohup masterha_manager --conf=/data/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /data/mha/mha/app1/manager.log 2>&1 & 2、一旦主master出现宕机，会自动检测和选取新的主master 3、切换的过程 当master_manager监控到主库MysqLd服务停止后，首先对主库进行SSH登录检查（save_binary_logs --command=test），然后对MysqLd服务进行健康检查（PING(SELECT)每隔3秒检查一次，持续3次），参数secondary_check_script可用于double check，最后作出Master is down!的判断，master failover开始 1、先根据配置文件检测当前的复制环境中有哪些服务器，MHA也会校验诸如复制异常以及是否存在一些从库有不同的主库，启动failover（排除上次failover失败或者failover时间间隔太短） 2、隔离master server，把故障主库的VIP停掉（前提是你需要指定相关的脚本，比如：如果有master_ip_failover_script则会调用脚本停掉VIP、如果有shutdown_script脚本则调用脚本关闭master避免脑裂，具体在配置文件中app1.cnf） 3、选举新主库并尽量补全新主库的数据 1、获取同步位置最靠前的从库：对比所有从库的master_log_file和read_master_log_pos位置找出执行位置最新和最旧的从库对应的故障主库的binlog位置 2、保存dead master的binlog：在故障主库上执行save_binary_logs命令获得lastest slave同步位置与master间的binlog差异（使用3.1步骤找到的同步最靠前的从库binlog位置，如果故障主库系统没挂的情况下）并scp到mha manager server上 scp from root@192.168.142.48:/data/mha/mha/tmp/saved_master_binlog_from_192.168.142.48_5700_20180525155119.binlog to local:/data/mha/mha/app1/saved_master_binlog_from_192.168.142.48_5700_20180525155119.binlog succeeded. 3、确定和决定新的主库 确定新的主库：先使用命令apply_diff_relay_logs --command=find把前面3.1步骤中找出的同步位置最靠前和最靠后的对应主库的binlog位置作为参数，在同步位置最靠前的从库上执行这个命令在其中继日志中找出两个binlog位置之间的relay log并生成文件用于恢复其他从库（这里就是检查同步最靠前的从库是否有从最老的位置开始的中继日志，这也是为什么MHA环境中执行过的中继日志不能删除的原因，否则这个对比就比较麻烦） 接着寻找及决定新的主库，根据配置选择如何提升新主库(检查是否有设置candidate_master=1和no_master=1，如果有设置候选主库，那么候选主库中标，但候选库不一定就是有最新数据的slave，所以需要跟其他从库进行比较，当然如果候选主库恰好是同步位置最靠前的从库，就不需要跟其他从库进行relay log比较了；如果没有设置候选主库，那么同步位置最靠前的从库中标)。mha manager server也会将之前复制的差异binlog复制到新主库上 4、新的主库应用日志(如果有任何错误从这个阶段会发生，需要手动恢复) 新的主库首先需要对比master_log_file=relay_master_log_file,read_master_log_pos=exec_master_log_pos确认自己已经执行完成复制，如果新的主库不是同步位置最靠前的从库，那么需要使用apply_diff_relay_logs --command=generate_and_send命令比较自己和同步位置最靠前的从库之间的relay log是否存在差异，如果存在则需要生成一个差异relay log（如果新主库就是同步位置最靠前的从库，那么只需要执行mha manager server发过来的差异日志即可），然后使用这两个差异日志进行恢复数据（apply_diff_relay_logs --command=apply命令）。恢复完成后获取binlog位置并生成change master语句准备用于其他从库change master到新的主库上，并设置read_only=0。然后把VIP绑定到新的主库上。到这步骤新的主库切换完成 4、其他从库恢复：将其他从库数据尽量补全（所有从库并行执行） 并行使用apply_diff_relay_logs --command=generate_and_send命令判断各个从库的relay log位置和同步位置最靠前的从库之间的relay log差异，并把差异文件从同步位置最靠前的从库上发送到对应的各个从库上 并行使用两个差异日志进行恢复：mha manager server上的binlog差异拷贝到各个从库上，然后各个从库通过master_log_file=relay_master_log_file,read_master_log_pos=exec_master_log_pos先确认自己已经执行完成复制，再应用两个差异日志恢复数据。最后，执行reset slave，并重新CHANG MASTER到新主库上 5、清理新master的相关信息，到这里故障主库切换到新主库完成 Resetting slave info on the new master.. 11. 故障后的主机新加入资源组 第一种方法 1、vim /data/mha/app1.cnf 添加server1主机信息 [server1] candidate_master=1 client_bindir=/usr/local/MysqL-5.7.18/bin/ client_libdir=/usr/local/MysqL-5.7.18/lib/ hostname=192.168.142.48 port=5700 2、将server1指向当前的master充当从的角色 CHANGE MASTER TO MASTER_HOST='192.168.142.49',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_PORT=5700,MASTER_LOG_FILE='MysqL-bin.000001',MASTER_LOG_POS=2488; 3、启动mha manager nohup masterha_manager --conf=/data/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /data/mha/mha/app1/manager.log 2>&1 & 第二种方法 1、通过masterha_conf_host将server1主机信息添加进资源组 masterha_conf_host --command=add --conf=/data/mha/app1.cnf --block=server1 --hostname=192.168.142.48 --params="candidate_master=1;client_bindir=/usr/local/MysqL-5.7.18/bin/;client_libdir=/usr/local/MysqL-5.7.18/lib/;port=5700" 参数解释： command：添加或者删除一个主机信息到配置文件 conf：配置文件的路径 hostname：主机信息ip block：新添加的块名 params：额外参数列表，(key1=value1;key2=value2;...) 2、将server1指向当前的master充当从的角色 CHANGE MASTER TO MASTER_HOST='192.168.142.49',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_PORT=5700,MASTER_LOG_FILE='MysqL-bin.000001',MASTER_LOG_POS=2488; 3、启动mha manager nohup masterha_manager --conf=/data/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /data/mha/mha/app1/manager.log 2>&1 & 12. MHA 清理relay log（purge_relay_logs） 1、说明： MysqL数据库主从复制在缺省情况下从库的relay logs会在sql线程执行完毕后被自动删除 但是对于MHA场景下，对于某些滞后从库的恢复依赖于其他从库的relay log，因此采取禁用自动删除功能以及定期清理的办法 对于清理过多过大的relay log需要注意引起的复制延迟资源开销等。MHA可通过purge_relay_logs脚本及配合cronjob来完成此项任务 2、purge_relay_logs的功能 a、为relay日志创建硬链接(最小化批量删除大文件导致的性能问题) b、SET GLOBAL relay_log_purge=1; FLUSH LOGS; SET GLOBAL relay_log_purge=0; c、删除relay log（rm –f /path/to/archive_dir/*） 3、purge_relay_logs的用法及相关参数 ###用法 # purge_relay_logs --help Usage: purge_relay_logs --user=root --password=rootpass --host=127.0.0.1 （编辑：甘南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
