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、启动与管理MHA1.1. 先在当前的master节点执行如下命令1.2. 主节点绑定vip1.3. 启动管理节点1.4. 查看管理节点状态1.5. 验证服务主从复制1.6. 验证故障转移1.7. 怎么把原来的故障节点加入集群8、 MHA集群切换测试1、自动Failover2、手动FailoverMHA Manager必须没有运行3、MHA master在线切换4、如何将故障节点重新加入集群5、使用MHA需要注意的问题MHAMaster 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的nodeyum 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] userroot #mysql用户名 password123456 #mysql密码 ssh_userroot #linux系统的用户 repl_userrepl_user #主从复制的用户 repl_passwordrepl_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_hostManager-[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_master1 #可被选举为master hostname172.16.213.232 master_binlog_dir/db/data #日志文件位置 [server2] candidate_master1 hostname172.16.213.236master_binlog_dir/db/data check_repl_delay0 #进行选举不管落后数据没有 [server3] hostname172.16.213.237 master_binlog_dir/db/data no_master1 #不能设置为主节点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( commands \$command, ssh_users \$ssh_user, orig_master_hosts \$orig_master_host, orig_master_ips \$orig_master_ip, orig_master_porti \$orig_master_port, new_master_hosts \$new_master_host, new_master_ips \$new_master_ip, new_master_porti \$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 --commandstart|stop|stopssh|status --orig_master_hosthost --orig_master_ipip --orig_master_portport --new_master_hosthost --new_master_ipip --new_master_portport\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、启动与管理MHA1.1. 先在当前的master节点执行如下命令[root232server app1]# /sbin/ifconfig eth0:1 172.16.213.239此操作只需第一次执行,用来将vip绑定到目前的master节点上,当MHA接管了mysql主从复制后,就无需执行此操作了。所有VIP的漂移都有MHA来完成。然后通过masterha_manager启动MHA监控:[root238server app1]# nohup masterha_manager --conf/etc/mha/app1.cnf --ignore_last_failover /dev/null /tmp/manager_error.log 21 启动参数介绍:--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. 主节点绑定vip1.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). 识别含有最新更新的slave5). 应用从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、手动FailoverMHA Manager必须没有运行手动failover, 这种场景意味着在业务上没有启用MHA自动切换功能, 当主服务器故障时, 人工手动调用MHA来进行故障切换操作, 进行手动切换命令如下:[rootiivey app1]# masterha_master_switch --master_statedead --conf/etc/mha/app1.cnf \ --dead_master_host172.16.213.232 --dead_master_port3306 \ --new_master_host172.16.213.236 --new_master_port3306 --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的时间左右大大减少了停机时间。[rootiivey app1]# masterha_master_switch --conf/etc/mha/app1.cnf --master_statealive --new_master_host172.16.213.232 --orig_master_is_new_slave --running_updates_limit10000 --interactive0MHA在线切换基本步骤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_master1 hostname172.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_HOST172.16.213.236,MASTER_PORT3306,MASTER_LOG_FILEmysql-bin.000009,MASTER_LOG_POS120,MASTER_USERrepl_user,MASTER_PASSWORDxxx;意思是说, 如果Master主机修复好了, 可以在修复好后的Master上执行CHANGE MASTER操作, 作为新的slave库。接着在老的master执行如下命令mysql CHANGE MASTER TO MASTER_HOST172.16.213.236, MASTER_PORT3306, MASTER_LOG_FILEmysql-bin.000009, MASTER_LOG_POS120, MASTER_USERrepl_user MASTER_PASSWORDrepl_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 21 5、使用MHA需要注意的问题1、Failover切换之后会产生一个app1.failover.complete文件, 如果要进行第二次Failover测试, 需要手工删除 app1.failover.complete。另一种方法是通过--ignore_last_failover参数来忽略, 例如:masterha_master_switch --master_statedead --conf/etc/mha/app1.cnf --dead_master_host172.16.213.236 --dead_master_port3306 --new_master_host172.16.213.232 --new_master_port3306 --ignore_last_failover2、一旦发生一次切换后, mha manager监控进程将会退出, 无法继续进行监控, 要再次开启监控, 需将原故障数据库重新加入到 MHA环境中来, 然后设置为slave。最后再次在mha manager上开启对master的监控进程。3、原主节点重新加入到MHA时只能设置为slave, 并且需要执行change master to MASTER_HOST172.16.213.236, MASTER_USERreplicationuser,MASTER_PASSWORDreplicationuser, MASTER_LOG_FILEmysql-bin.000004,MASTER_LOG_POS106;上面的change信息可从mha切换日志中获取到。4、关于ip地址的接管有几种方式, 这里采用的是MHA自动调用ip别名的方式,好处在能够保证数据库状态与业务ip 切换的一致性。启动管理节点之后 vip会自动别名到当前主节点上。