Mysql集群架构MHA应用实战
目录
1、MHA的概念和原理
2、MHA的组成和恢复过程
3、MHA集群架构
5、MHA的安装与配置
1.1. 安装MHA软件
1.2. 配置MHA集群
1.2.1. MHA主配置文件
1.2.2. 配置MHA集群
1.2.3. MHA的master_ip_failover文件
6、测试MHA环境以及常见问题总结
7、启动与管理MHA
1.1. 先在当前的master节点执行如下命令:
1.2. 主节点绑定vip
1.3. 启动管理节点
1.4. 查看管理节点状态
1.5. 验证服务主从复制
1.6. 验证故障转移
1.7. 怎么把原来的故障节点加入集群
8、 MHA集群切换测试
1、自动Failover
2、手动Failover(MHA Manager必须没有运行)
3、MHA master在线切换
4、如何将故障节点重新加入集群
5、使用MHA需要注意的问题
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台sla ve节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度地保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据。使用MyS QL的半同步复制,可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当从库。
1、MHA的概念和原理
2、MHA的组成和恢复过程
Manager工具包主要包括以下几个工具:
● 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信息Node工具包(这些工具通常由MHAManager的脚本触发,无需人为操作)主要包括以下几个工具:
● save_binary_logs 保存和复制master的二进制日志 ● apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave ● purge_relay_logs 清除中继日志(不会阻塞SQL线程)3、MHA集群架构
5、MHA的安装与配置
1.1. 安装MHA软件
MHA提供了源码和rpm包两种安装方式,这里推荐使用rpm包安装方式,安装过程如下:
安装包下载:https://code.google.com/archive/p/mysql-master-ha/downloads
在三个节点依次安装MHA的node
yum install perl-DBD-mysql rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm最后在MHA Manager节点上安装mha4mysql-manage:
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Config-IniFiles perl-Time-HiRes rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm1.2. 配置MHA集群
MHA安装完成后, 可在/etc/mha目录下手动创建一个文件, 用来作为MHA的主配置文件, 文件名称任意即可, 这里创建了一个app1.cnf文件。
1.2.1. MHA主配置文件
MHA主配置文件/etc/mha/app1.cnf常用配置选项内容如下:
[server default] user=root #mysql用户名 password=123456 #mysql密码 ssh_user=root #linux系统的用户 repl_user=repl_user #主从复制的用户 repl_password=repl_passwd #主从复制的mii吗 ping_interval = 1 #状态检查,每隔几秒去检测一次 secondary_check_script = masterha_secondary_check -s 172.16.213.235 #下文解释,一般设置为不是mysql集群的节点 #master_ip_failover_script = /etc/mha/scripts/master_ip.failover #vip的漂移地址,ip跟着切换 #master_ip_online_change_script = /etc/mha/scripts/master_ip.online_change" #在线切换,手动切换 #shutdown_script = /script/masterha/power_manager #master发送故障,直接执行关机防止脑裂 report_script = /etc/mha/scripts/send_report" #切换后发送邮件 manager_log = /var/log/mha/app1/manager.log #日志文件 manager_workdir = /var/log/mha/app1 #指定工作目录secondary_check_script: 默认情况下, MHA通过单个路由(即从Manager到Master)来检查Master的可用性。这种默认的监控机制不够完善,不过MHA还提供了一个监控master的接口,那就是通过调用secondary_check_script参数,通过定义外部本来实现多路由监测;例如:
secondary_check_script = masterha_secondary_check-sremote_host1-sremote_host2
其中,masterha_secondary_check是MHA提供的一个监测脚本,remote_host1、remote_host2是远程的两台主机,建议不要和MHA manager主机在同一个网段中。
masterha_secondary_check脚本的监测机制是:
Manager-[A]->remote_host1-[B]->master_host
Manager-[A]->remote_host2-[B]->master_host
监测脚本会首先通过Manager主机检测到远程主机的网络状态,这个过程是A,接着,再通过远程主机检查到master_host的状态,这个过程为B。
在过程A中,Manager主机需要通过ssh连接到远程的机器上,所以需要manager主机到远程机器上建立publickey信任。在过程B中,masterha_secondary_check是通过远程主机和Master建立TCP连接来测试Master是否存活的。
在所有的路由中,如果A成功,B失败,那么MHA才认为master出现了问题,进而执行failover操作,其它情况一律认为master是正常状态。也就是不会进行failover操作。一般来讲,强烈推荐使用多个网络上的机器,通过不同路由来核实MySQL Master存活状态。
1.2.2. 配置MHA集群
MHA主配置文件/etc/mha/app1.cnf常用配置选项内容如下:
[server1] candidate_master=1 #可被选举为master hostname=172.16.213.232 master_binlog_dir="/db/data" #日志文件位置 [server2] candidate_master=1 hostname=172.16.213.236master_binlog_dir="/db/data" check_repl_delay=0 #进行选举不管落后数据没有 [server3] hostname=172.16.213.237 master_binlog_dir="/db/data" no_master=1 #不能设置为主节点1.2.3. MHA的master_ip_failover文件
MHA没有vip漂移的功能,要实现VIP的自动漂移,需要一个脚本来完成。MHA manager会调用 master_ip_failover_script三次,我们可以在MHA主配置文件通过添加master_ip_failover_script选项指定一个脚本来实现VIP的自动漂移功能。
MHA在源码包中自带了一个实现VIP自动漂移的脚本master_ip_failover,但默认这个脚本无法使用,需要一些修改,修改后的master_ip_failover脚本内容如下:
#!/usr/bin/env perl use strict; use warnings FATAL => 'all'; use Getopt::Long; my ( $command, $ssh_user, $orig_master_host, $orig_master_ip, $orig_master_port, $new_master_host, $new_master_ip, $new_master_port ); my $vip = '172.16.213.239/24'; #vip需要修改自己网段 my $key = '1'; my $ssh_start_vip = "/sbin/ifconfig enp0s8:$key $vip"; #网卡修改为自己的网卡 my $ssh_stop_vip = "/sbin/ifconfig enp0s8:$key down"; #网卡修改为自己的网卡 GetOptions( 'command=s' => \$command, 'ssh_user=s' => \$ssh_user, 'orig_master_host=s' => \$orig_master_host, 'orig_master_ip=s' => \$orig_master_ip, 'orig_master_port=i' => \$orig_master_port, 'new_master_host=s' => \$new_master_host, 'new_master_ip=s' => \$new_master_ip, 'new_master_port=i' => \$new_master_port, ); exit &main(); sub main { print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n"; if ( $command eq "stop" || $command eq "stopssh" ) { my $exit_code = 1; eval { print "Disabling the VIP on old master: $orig_master_host \n"; &stop_vip(); $exit_code = 0; }; if ($@) { warn "Got Error: $@\n"; exit $exit_code; } exit $exit_code; } elsif ( $command eq "start" ) { my $exit_code = 10; eval { print "Enabling the VIP - $vip on the new master - $new_master_host \n"; &start_vip(); $exit_code = 0; }; if ($@) { warn $@; exit $exit_code; } exit $exit_code; } elsif ( $command eq "status" ) { print "Checking the Status of the script.. OK \n"; exit 0; } else { &usage(); exit 1; } } sub start_vip() { `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`; } sub stop_vip() { return 0 unless ($ssh_user); `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`; } sub usage { print "Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n"; }6、测试MHA环境以及常见问题总结
MHA提供了两个工具用来验证MHA环境配置的正确性, 可通过masterha_check_ssh和masterha_check_repl两个命令来验证。
1、通过masterha_check_ssh验证ssh信任登录是否配置成功
masterha_check_ssh --conf=/etc/mha/app1.cnf如下显示则配置成功:
2、masterha_check_repl验证mysql主从复制是否配置成功
masterha_check_repl --conf=/etc/mha/app1.cnf如下显示则配置成功:
7、启动与管理MHA
1.1. 先在当前的master节点执行如下命令:
[root@232server app1]# /sbin/ifconfig eth0:1 172.16.213.239此操作只需第一次执行,用来将vip绑定到目前的master节点上,当MHA接管了mysql主从复制后,就无需执行此操作了。所有VIP的漂移都有MHA来完成。
然后通过masterha_manager启动MHA监控:
[root@238server app1]# nohup masterha_manager --conf=/etc/mha/app1.cnf --ignore_last_failover < /dev/null > /tmp/manager_error.log 2>&1 &启动参数介绍:
- --ignore_last_failover: 在缺省情况下,如果MHA检测到连续发生宕机,且两次宕机间隔不足8小时的话,则不会进行Failover,之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件。
- 默认情况下,MHA发生切换后会在MHA工作目录产生类似app1.failover.complete文件,下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换,除非在第一次切换后删除该文件,为了方便,这里设置" --ignore_last_failover "参数。
- --remove_dead_master_conf: 设置了这个参数后,如果MHA failover结束后,MHA Manager会自动在配置文件中删除dead master的相关项,如果不设置,由于dead master的配置还存在文件中,那么当MHA failover后,当再次restart MHA manager后,会报错 (there is a dead slave previous dead master)
- /tmp/manager_error.logs是存放MHA运行过程中的一些警告或错误信息。
1.2. 主节点绑定vip
1.3. 启动管理节点
查看日志(ssh检查,主从复制检查)
1.4. 查看管理节点状态
停止方式:
1.5. 验证服务主从复制
远程登录
查看当前所在主机master:
插入几条数据,备用节点备份成功
1.6. 验证故障转移
- 在主节点停止mysql服务
- 从节点切换为主节点,管理节点日志显示:
主机不能连接:
- 吧公钥传到135服务器
- 查看日志,不是集群的ssh通了后,立马执行检测到232宕机,执行切换
执行failover
关闭vip
选举成功master
新的主节点的日志报告
1.7. 怎么把原来的故障节点加入集群
- 启动mysql服务
- 今日命令行,从新的主节点 拷贝数据
- 启动从节点
- 查看状态
- 开启监控
如下显示则集群恢复正常
8、 MHA集群切换测试
1、自动Failover
要实现自动Failover, 必须先启动MHA Manager, 否则无法自动切换, 当然手动切换不需要开启MHA Manager监控。
A、杀掉主库mysql进程, 模拟主库发生故障, 进行自动failover操作。
B、看MHA切换日志, 了解整个切换过程。
从Failover的输出可以看出整个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进行复制
切换完成后, 关注如下变化:
- vip自动从原来的master切换到新的master, 同时, manager节点的监控进程自动退出。
- 在日志目录(/var/log/mha/app1)产生一个app1.failover.complete文件
- 如果启动mha manager时, 添加了--remove_dead_master_conf参数, 那么/etc/mha/app1.cnf配置文件中原来老的master配置会被删除。
2、手动Failover(MHA Manager必须没有运行)
手动failover, 这种场景意味着在业务上没有启用MHA自动切换功能, 当主服务器故障时, 人工手动调用MHA来进行故障切换操作, 进行手动切换命令如下:
[root@iivey app1]# masterha_master_switch --master_state=dead --conf=/etc/mha/app1.cnf \ --dead_master_host=172.16.213.232 --dead_master_port=3306 \ --new_master_host=172.16.213.236 --new_master_port=3306 --ignore_last_failover注意: 如果, MHA manager检测到没有dead的server, 将报错, 并结束failover:
Mon Apr 21 21:23:33 2018 - [info] Dead Servers: Mon Apr 21 21:23:33 2018 - [error][/usr/local/share/perl5/MHA/MasterFailover.pm, In181] None of server is dead. Stop failover. Mon Apr 21 21:23:33 2018 - [error][/usr/local/share/perl5/MHA/ManagerUtil.pm, In178] Got ERROR: at /usr/local/bin/masterha_master_switch line 533、MHA master在线切换
MHA在线切换是MHA除了自动监控切换提供的另外一种方式,多用于诸如硬件升级,MySQL数据库迁移等等。该方式提供快速切换和优雅的阻塞写入,无需关闭原有服务器,整个切换过程在0.5-2s的时间左右,大大减少了停机时间。
[root@iivey app1]# masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=172.16.213.232 --orig_master_is_new_slave --running_updates_limit=10000 --interactive=0MHA在线切换基本步骤:
a、检测MHA配置置及确认当前master b、决定新的master c、阻塞写入到当前master d、等待所有从服务器与现有master完成同步 e、在新master授予写权限,以及并行切换从库 f、重置原master为新master的slave4、如何将故障节点重新加入集群
通常情况下自动切换以后,原master可能已经废弃掉。待原master主机修复后, 如果数据完整的情况下, 可能想把原来master重新作为新主库的slave, 这时可以借助当时自动切换时刻的MHA日志来完成对原master的修复。
(1) 修改manager配置文件
将如下内容添加到/etc/mha/app1.conf中:
[server1] candidate_master=1 hostname=172.16.213.232 master_binlog_dir="/ab/data"(2) 修复老的master,然后设置为slave
从自动切换时刻的MHA日志上可以发现类似如下信息:
Sat May 2714:59:17 2018 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTERTO MASTER_HOST='172.16.213.236',MASTER_PORT=3306,MASTER_LOG_FILE='mysql-bin.000009',MASTER_LOG_POS=120,MASTER_USER='repl_user',MASTER_PASSWORD='xxx';意思是说, 如果Master主机修复好了, 可以在修复好后的Master上执行CHANGE MASTER操作, 作为新的slave库。
接着,在老的master执行如下命令:
mysql> CHANGE MASTER TO MASTER_HOST='172.16.213.236', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=120, MASTER_USER='repl_user' MASTER_PASSWORD=repl_passwd; mysql> start slave; mysql> show slave status\G;这样,数据就开始同步到老的master上了。此时老的master已经重新加入集群,变成mha集群中的一个slave角色了。
(3)、在manager节点上重新启动监控进程
nohup masterha_manager --conf=/etc/mha/app1.cnf --ignore_last_failover </dev/null > /etc/mha/app1/logs/manager_error.log 2>&1 &5、使用MHA需要注意的问题
1、Failover切换之后会产生一个app1.failover.complete文件, 如果要进行第二次Failover测试, 需要手工删除 app1.failover.complete。另一种方法是通过--ignore_last_failover参数来忽略, 例如:
masterha_master_switch --master_state=dead --conf=/etc/mha/app1.cnf --dead_master_host=172.16.213.236 --dead_master_port=3306 --new_master_host=172.16.213.232 --new_master_port=3306 --ignore_last_failover2、一旦发生一次切换后, mha manager监控进程将会退出, 无法继续进行监控, 要再次开启监控, 需将原故障数据库重新加入到 MHA环境中来, 然后设置为slave。最后再次在mha manager上开启对master的监控进程。
3、原主节点重新加入到MHA时只能设置为slave, 并且需要执行
change master to MASTER_HOST='172.16.213.236', MASTER_USER='replicationuser',MASTER_PASSWORD='replicationuser', MASTER_LOG_FILE='mysql-bin.000004',MASTER_LOG_POS=106;上面的change信息可从mha切换日志中获取到。
4、关于ip地址的接管有几种方式, 这里采用的是MHA自动调用ip别名的方式,好处在能够保证数据库状态与业务ip 切换的一致性。启动管理节点之后 vip会自动别名到当前主节点上。
