MySQL高可用架构之MHA的原理分析

这篇文章主要介绍了MySQL高可用架构之MHA的原理分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。MHA 服务有两种角色，MHA Manager（管理节点）和MHA Node（数据节点）：MHA Manager：通常单独部署在一台独立的机器上或者直接部署在其中一台slave上（不建议后者），管理多个master/slave集群，每个master/slave集群称作一个application；其作用有二：（1）master自动切换及故障转移命令运行（2）其他的帮助脚本运行：手动切换master；master/slave状态检测MHA node：运行在每台MySQL服务器上（master/slave/manager），它通过监控具备解析和清理logs功能的脚本来加快故障转移。其作用有：（1）复制主节点的binlog数据（2）对比从节点的中继日志文件（3）无需停止从节点的SQL线程，定时删除中继日志目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。我们自己使用其实也可以使用1主1从，但是master主机宕机后无法切换，以及无法补全binlog。master的mysqld进程crash后，还是可以切换成功，以及补全binlog的。官方介绍：

https://code.google.com/p/mysql-master-ha/下图展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结为如下：（1）从宕机崩溃的master保存二进制日志事件（binlog events）;（2）识别含有最新更新的slave；（3）应用差异的中继日志（relay log）到其他的slave；（4）应用从master保存的二进制日志事件（binlog events）；（5）提升一个slave为新的master；（6）使其他的slave连接新的master进行复制；(1)、 Manager工具:– masterha_check_ssh : 检查MHA的SSH配置。– masterha_check_repl : 检查MySQL复制。– masterha_manager : 启动MHA。– masterha_check_status : 检测当前MHA运行状态。– masterha_master_monitor : 监测master是否宕机。– masterha_master_switch : 控制故障转移(自动或手动)。– masterha_conf_host : 添加或删除配置的server信息。(2)、 Node工具(这些工具通常由MHAManager的脚本触发,无需人手操作)。– save_binary_logs : 保存和复制master的二进制日志。– apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。– filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。– purge_relay_logs : 清除中继日志(不会阻塞SQL线程)。(3)、自定义扩展：-secondary_check_script：通过多条网络路由检测master的可用性；-master_ip_failover_script：更新application使用的masterip；（需要修改）-shutdown_script：强制关闭master节点；-report_script免费主机域名：发送报告；-init_conf_load_script：加载初始配置参数；-master_ip_online_change：更新master节点ip地址；（需要修改）OS：CentOS 6.8MySQL ：5.7.18MHA 软件包： MHA 0.57角色 ip地址 主机名 server_id “类型 “
Master 10.180.2.163 MHA-M1 13306 “写入 “
S1 10.180.2.164 MHA-S1 23306 “读 ” （其实可以一起部署监控，一组MHA 可以多个监控节点）
S2 10.180.2.165 MHA-S2 33306 “读 “，”监控复制组 ” （监控一般不能部署到master 节点，防止Master 宕机不能切换）（1）在所有节点安装MHA node所需的perl模块（DBD:mysql），并下载MHA 软件包?12yum
install
perl-DBD-MySQL -y (可能需要epel源)https://mega.nz/#F!G4oRjARB!SWzFS59bUv9VrKwdAeIGVw （MHA0.57）（2）在所有的节点安装mha node（包括Manager 节点）：安装完成将产生文件如下：
增加系统环境变量：安装完成后会在/usr/local/bin目录下面生成以下脚本文件

复制相关脚本到/usr/local/bin目录(软件包解压缩后就有了，不是必须，因为这些脚本不完整，需要自己修改，这是软件开发着留给我们自己发挥的,如果开启下面的任何一个脚本对应的参数，而对应这里的脚本又没有修改，则会抛错，自己被坑的很惨)
[root@MHA-S2 scripts]# ll
total 32
-rwxr-xr-x 1 root root 3443 Jan 8 2012 master_ip_failover #自动切换时vip管理的脚本，不是必须，如果我们使用keepalived的，我们可以自己编写脚本完成对vip的管理，比如监控mysql，如果mysql异常，我们停止keepalived就行，这样vip就会自动漂移
-rwxr-xr-x 1 root root 9186 Jan 8 2012 master_ip_online_change #在线切换时vip的管理，不是必须，同样可以可以自行编写简单的shell完成
-rwxr-xr-x 1 root root 11867 Jan 8 2012 power_manager #故障发生后关闭主机的脚本，不是必须
-rwxr-xr-x 1 root root 1360 Jan 8 2012 send_report #因故障切换后发送报警的脚本，不是必须，可自行编写简单的shell完成。
[root@MHA-S2 scripts]# cp * /usr/local/bin/
配置SSH登录无密码验证搭建主从复制环境详解之前双主复制环境搭建文档保证两台Slave都搭建成功创建监控用户（在master上执行）至此，复制搭建完毕，后面配置MHAMHA环境配置（1） 创建MHA 工作目录修改app1.cnf配置文件，修改后的文件内容如下：（2）设置relay log的清除方式（在每个slave节点上）：?1’set global relay_log_purge=0′注意：MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能。定期清除中继日志需要考虑到复制延时的问题。在ext3的文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，需要暂时为中继日志创建硬链接，因为在linux系统中通过硬链接删除大文件速度会很快。（在mysql数据库中，删除大表时，通常也采用建立硬链接的方式）MHA节点中包含了pure_relay_logs命令工具，它可以为中继日志创建硬链接，执行SET GLOBAL relay_log_purge=1,等待几秒钟以便SQL线程切换到新的中继日志，再执行SET GLOBAL relay_log_purge=0。pure_relay_logs脚本参数如下所示：（3）设置定期清理relay脚本(例如每天一次，所有服务器）可以手工执行以下是否会报错检查SSH配置检查整个复制环境状况发现有报错，原来Failover两种方式：一种是虚拟IP地址，一种是全局配置文件。MHA并没有限定使用哪一种方式，而是让用户自己选择，虚拟IP地址的方式会牵扯到其它的软件,比如keepalive软件，而且还要修改脚本master_ip_failover。这里先把app1.cnf 里面master_ip_failover_script= /usr/local/bin/master_ip_failover这个选项屏蔽才可以通过。检查MHA Manager的状态手动启动–remove_dead_master_conf 该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。（如果发生异常切换之后修复了旧的master，要加进去新的MHA 的话，必须记得app1.cnf回补server1的信息）–manger_log 日志存放位置–ignore_last_failover在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为–ignore_last_failover。检查启动日志配置VIPvip配置可以采用两种方式，一种通过keepalived的方式管理虚拟ip的浮动；另外一种通过脚本方式启动虚拟ip的方式（即不需要keepalived或者heartbeat类似的软件）。这里仅演示使用脚本管理VIP 的方式，修改master_ip_failover 脚本，使用脚本管理VIP脚本：在app1.cnf 文件中取消刚刚对master_ip_online_failover 的注释并测试：IN SCRIPT TEST====/sbin/ifconfig eth2:1 down==/sbin/ifconfig eth2:1 10.180.2.168/19===Checking the Status of the script.. OK

Wed Aug 9 10:49:43 2017 – [info] OK.
Wed Aug 9 10:49:43 2017 – [warning] shutdown_script is not defined.
Wed Aug 9 10:49:43 2017 – [info] Got exit code 0 (Not master dead).MySQL Replication Health is OK.以上就是MHA 安装配置的全过程，以下进行简单的测试。（1）failover 测试手动kill 了master 上面的mysqld 进程，查看切换状态以上是切换的全日志过程，我们可以看到MHA 切换主要经历以下步骤：1.配置文件检查阶段，这个阶段会检查整个集群配置文件配置2.宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作（这个我这里还没有实现，需要研究）3.复制dead maste和最新slave相差的relay log，并保存到MHA Manger具体的目录下4.识别含有最新更新的slave5.应用从master保存的二进制日志事件（binlog events）6.提升一个slave为新的master进行复制7.使其他的slave连接新的master进行复制注意：1. 切换完之后你会发现MHA Manager 监控程序会自动死掉，官网有如下解释和解决方式：这里我们用shell 脚本的方式去执行就不会发生监控程序死掉的情况2. 当你修复完死掉的master想重新加入先有的两节点MHA 也是可以的旧Master ：现有master：由于有GTID，我们可以直接就change master 切换过去，先对比一下数据：旧master：新master：旧master 直接change master to：start slave 看输出：看是否会补全数据：发现数据补全了，加入复制没问题。最后还得修改app1.cnf 把server1 补上重启监控程序并查看MHA 状态发现权限有问题，赶紧修复一下：MHA-M1：再次执行MHA 状态检查：最后启动监控程序（2)手动在线切换测试在许多情况下， 需要将现有的主服务器迁移到另外一台服务器上。 比如主服务器硬件故障，RAID 控制卡需要重建，将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降， 导致停机时间至少无法写入数据。 另外， 阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。 MHA 提供快速切换和优雅的阻塞写入，这个切换过程只需要 0.5-2s 的时间，这段时间内数据是无法写入的。在很多情况下，0.5-2s 的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口。MHA在线切换的大概过程：
1.检测复制设置和确定当前主服务器
2.确定新的主服务器
3.阻塞写入到当前主服务器
4.等待所有从服务器赶上复制
5.授予写入到新的主服务器
6.重新设置从服务器注意，在线切换的时候应用架构需要考虑以下两个问题：1.自动识别master和slave的问题（master的机器可能会切换），如果采用了vip的方式，基本可以解决这个问题。2.负载均衡的问题（可以定义大概的读写比例，每台机器免费主机域名可承担的负载比例，当有机器离开集群时，需要考虑这个问题）为了保证数据完全一致性，在最快的时间内完成切换，MHA的在线切换必须满足以下条件才会切换成功，否则会切换失败。1.所有slave的IO线程都在运行2.所有slave的SQL线程都在运行3.所有的show slave status的输出中Seconds_Behind_Master参数小于或者等于running_updates_limit秒，如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒。4.在master端，通过show processlist输出，没有一个更新花费的时间大于running_updates_limit秒。在线切换步骤如下：先停止监控程序修改master_ip_online_change脚本如下：执行切换其中参数的意思：–orig_master_is_new_slave 切换时加上此参数是将原 master 变为 slave 节点，如果不加此参数，原来的 master 将不启动–running_updates_limit=10000,故障切换时,候选master 如果有延迟的话， mha 切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由recover 时relay 日志的大小决定查看切换后各机器的状态：S2：S1：M1：在线切换的日志：感谢你能够认真阅读完这篇文章，希望小编分享的“MySQL高可用架构之MHA的原理分析”这篇文章对大家有帮助，同时也希望大家多多支持云技术，关注云技术行业资讯频道，更多相关知识等着你来学习!

相关推荐: 怎么解决RAC数据库环境修改scanip后客户端连接异常

这篇文章主要讲解了“怎么解决RAC数据库环境修改scanip后客户端连接异常”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么解决RAC数据库环境修改scanip后客户端连接异常”吧！摘要：在某个项目上需要将1…