MHA研究与应用实例分析

小编给大家分享一个MHA研究与应用的实例分析。相信大多数人对此还不是很了解，所以分享这篇文章供大家参考。希望您读完这篇文章后能有所收获。让我们一起来了解一下吧！

MHA研究与应用

1.问题和需求

1.1。问题总结

1．目前还没有工具可以快速切换集群的主数据库。如果主库切换，DBA需要手动修改从库指针、修改元信息等。

2．需要能够在不影响当前架构的情况下快速上线

3.所有处理都需要自动化，以方便DBA使用，如检查、操作、显示等。

2． MHA简介

2.1。什么是MHA

MHA（Master High Availability）是目前比较成熟的MySQL高可用解决方案。我t是由日本DeNA公司youshimaton开发的。它是一套优秀的MySQL高可用解决方案。用于环境中故障转移和主从升级的高可用性软件。

在MySQL故障转移过程中，MHA可以在0到30秒内自动完成数据库故障转移操作，并且在故障转移过程中，MHA可以最大程度地保证数据安全。一致性以实现真正的高可用性。

2.2、MHA原理

阶段1：配置检查阶段..

mha将检查mha默认文件，可以得到所有mysql节点的状态以及它们之间的关系，谁是master，谁是slave，谁死了，谁还活着。

阶段2：死主关闭阶段

使用master_ip_failover_scirpt和关闭脚本来关闭或停用失效的master，（例如IP或DNS切换，这是预先在自定义脚本中定义的，以防split-brain），我倾向于使用 python。

（执行master_ip_failover_script --command=stopssh使原主库IP失效；执行SHUTDOWN脚本--command=stopssh关闭原主库）

阶段3：主库恢复阶段

3.1 比较所有从库的bin日志的pos点，找到最新的binlog文件&pos和最旧的文件&pos

3.2 尝试从原来的主库获取binlog< /p>

3.3 根据no_master、candidate_master以及各个从库的延迟情况，选择新的主库；获取新主库缺失的日志信息

3.4 向新选择的主库补充日志，并激活新主库。 （生成change master to语句）

阶段4：从库恢复阶段

4.1向从库补充日志：从主库补充日志，或者从最后一个从库补充日志从数据库到其他补充日志

4.2 在前面步骤生成的所有可用slave中执行“change master to”命令

阶段5：新master清理

清除新主库的slave信息< br/>
[info] * 第 1 阶段：配置检查阶段..
[info] ** 第 1 阶段：配置检查阶段已完成。
[info] * 第 2 阶段：失效主控关闭阶段..< br/>[info] * 第 2 阶段：失效主控关闭阶段已完成。
[info] * 第 3 阶段：主控恢复阶段..
[info] * 阶段 3.1：获取最新的从站阶段..< br/>[info] * 阶段 3.2：保存死亡 Master 的 Binlog 阶段..
[info] * 阶段 3.3：确定新的 Master 阶段..
[info] * 阶段 3.3：新主差异日志生成阶段..
[info] * 阶段 3.4：主日志应用阶段..
[info] * 阶段 3：主恢复阶段已完成。
[info] * 第 4 阶段：从属恢复阶段 ..
[info] * 阶段 4.1：开始并行从属差异日志生成阶段..
[info] * 阶段 4.2 : 开始并行从属日志应用阶段..
[info] *阶段 5：新主清理阶段..
[info] 发送邮件..

2.3，MHA 优势

< p>1。不影响服务器性能，安装方便，不改变现有部署

2.故障转移（实现自动故障检测和故障转移，一般在30秒内；）

3.数据一致性性能保证

2.4、mha模式 < /h3>

按节点划分：manage/node模式，即MHA管理机器和集群node节点

按照切换分为：online/failover模式切换，即在线切换和主库损坏切换

2.5、MHA要求

1.至少一主一从
2. SSH互信

3. MySQL账户

4. Linux系统

5． MySQL 版本 5.0 以及未来

6. mysqlbinlog必须是3.3及以上版本

7.每台可以称为master的mysql服务器上都必须设置log-bin

8、复制过滤器所有mysql服务器的ng规则必须一致

9.复制帐户必须设置在可以成为主服务器的服务器上

10。执行基于语句的复制时，请勿使用 load datainfile 命令

11。关闭relay_log_purge，需要脚本/手动定期清理（清理方法：set global relay_log_purge=1;flush messages;）

2.6、MHA版本选择

从MHA 0.56版本开始，还支持基于GTID的故障转移。 MHA会自动检测mysqld是否在GTID上运行。如果启用GTID，MHA将通过GTID实现故障转移。如果未启用，MHA 将使用基于中继日志的故障转移。

2.7。重要参数

ignore_fail=1 忽略错误

< p>candidate_master=1 1：优先成为master 0：无优先

< p>no_master=1 1: 不能成为master 0: 可以成为master

3. MHA 实现

3.1，Archi结构图

3.2.具体实现及自动化

3.2.1、mha运行、部署、检查等流程--mhacluster

整合mha日常运行，部署、巡检、修复等功能

包含：

<1>添加互信关系

<2>安装MHA软件包等

<3>对相关账号进行授权

<4>检查ssh、repl、conf等是否正确

<5>自动修复问题集群

<6>自动更新各集群的conf文件

<7>自动更新别名，方便使用

<8>自动清理relaylog

函数如下

3.2.2、mhacluster功能-互信

中控/MHA管理机器，直至所有机器之间互信完成

添加集群内互信er并使用make_ssh_authentication.sh脚本自动添加互信

3.2.3、mhacluster功能--授权

需要超级权限的数据库用户并完成源集群所有实例IP

3.2.4、mhacluster功能--relay_log_purge设置

默认设置关闭，使用脚本任务定期清理

使用MHA自带的purge脚本，部署到crontab（已安装的节点会自动出现，此方法不使用暂时模拟这个方法进行清理）                 

3.2.5、mhacluster功能--mysqlbinlog收集更新

因为目前有一个 binlog 目录不固定。暂时用脚本收集仓储元信息

3.3.6、mhacluster功能--安装软件包

为所有实例安装2个软件包

rpm -ivh /data/soft/perl-DBD-MySQL-4.013-3。 el6.x86_64.rpm

rpm -ivh /data/soft/mha4mysql-node-0.56-0.el6.noarch.rpm

3.3.7 、 mhacluster功能-检查ssh/repl/conf

检查mha需要的masterha_check_ssh/repl

检查mha配置文件是否为与元信息一致

3.3.8、mhacluster功能-自动修复问题集群

自动修复ssh/repl/conf检查问题集群

3.3.9、mhacluster功能--更新别名和mha配置文件

更新mha常用别名

< p>alias masterha_check_ssh.1='masterha_check_repl --conf=/data/masterha/conf/1#testdb

alias masterha_check_repl.1='masterha_check_repl -- conf=/data/masterha /conf/1#testdb

注意：1这里是集群编号

更新mha配置文件

根据元信息更新mha的conf文件

3.3.9, < strong>mhacluster功能--授权mha需要的账号

自动授权mha需要的账号

3.4.元信息字段

cluster_id集群编号

cluster_name集群名称

角色：Master、Slave、Backup角色

binlog_dir binlog地址

no_master不能成为master，1不能成为master，0可以

candidate_master是否优先级可以切换为master，1优先， 0不优先',

mha_write_into_conf是否写入配置文件，1写入，0不写入

3.5，MHA配置

3.5。 1、MHA默认配置文件

[root@dbmon conf]# vi /etc/masterha_default.cnf

[服务器默认]

manager_workdir=/data/ masterha/work/

user=dba

password=

ssh_user=root

repl_user=repadm

repl_password=

ping_interval=30

shutdown_script= ""

master_ip_failover_script="/data/mha/master_ip_failover_script.py" 注：故障切换模式切换主脚本

master_ip_online_change_script="/data/mha/master_ip_online_change_script.py" 注：主脚本在线模式切换脚本

report_script="/data/mha/send_report.py" 注：切换后发送邮件的主要脚本

3.5.2、mha集群conf配置文件< /h4>

根据元信息自动生成

[server1]

hostname=10.0.0.1

port=3306

master_binlog_dir=/data/my3306/

ignore_fail=1

no_master=1

candidate_master=0

[server2]

主机名=10.0.0.2

端口=3306

master_binlog_dir=/data/my3306/

ignore_fail=1

no_master=0

candidate_master=0

3.6。切换程序--mhaswitch

切换程序，使用Python封装，方便日常切换ing

支持集群批量切换

切换方式：在线/死机模式切换，即原主库活切换、原主库故障切换

3.6.1、mhaswitch架构

注：其他辅助脚本暂不标注

3.6.2、mhaswitch功能--显示切换信息

可以显示集群实例信息如下

3.6.3、mhaswitch函数-2种切换方式

支持在线模式和failover模式切换（对应程序的活死）

在线模式：可选原主库是否作为新主库的从库库

故障切换模式：关闭原主库进行切换

3.6.4、mhaswitch辅助脚本--master_ip_failover_script.py函数

<1>当传入命令为stopssh或stop时，ori最终主库将关闭

<2>等。 2秒检查原主库是否关闭。如果不关闭，会打印“old master still run，please check”，然后程序退出

<3>当启动传入命令时，开始修改元数据

< p><4>修改域名-IP对应关系

<5>设置新主库read_only=off，同时修改配置文件

<6>修改原来主库read_only =on，同时修改配置文件

3.6.5、mhaswitch辅助脚本--master_ip_online_change_script.py函数

<1>传入时命令为stopssh或stop，原主库设置为read_only

<2>检查原主库是否为read_only。如果没有read_only，则会打印“not read_only，please check”，程序退出

<3>当传入的命令为start时，开始修改元数据

<4>修改域名-IP对应

<5>设置新主库read_only=off，同时修改配置文件

<6>修改原主库read_only=上，同时修改配置文件

3.6.6、mhaswitch辅助脚本--send_report.py函数

<1>发送故障切换模式切换日志、切换结果

<1> p>

<2>发送MHA配置文件地址

<3>旧主库IP、端口

<4>新主库IP、端口

< p><5>库名、服务名

<6>查看切换后的集群状态（表格格式）：

集群号、IP、角色、是否可以连接、slave sql线程、slave io线程、slave指向的主库主机检查、slave指向的主库端口检查、slave延迟、连接数、/数据空间状态、只读状态、时间

< h4>3.6.7、mhaswitch辅助脚本--online_switch_send_report.py函数

<1>发送在线切换日志和切换结果

<2>发送MHA配置文件地址

<1> p>

<3>旧主库IP、端口

<4>新主库IP、端口

<5>库名、服务名

<6>查看切换后的集群状态（表格格式）：

集群号、IP、角色、是否可以连接，slave sql线程，slave io线程，检查slave指向的主库主机，检查slave指向的主库端口，slave延迟，连接数，/数据空间状态，只读状态，时间

3.6.8、mhaswitch辅助脚本--change_domain_ip.sh函数

<1>更改域名-IP对应脚本

3.7、开始切换

3.7.1、mhaswitch使用说明 < /h4>

mhaswitch

请输入要切换的簇号：<强>78 注意：切换簇编号

###请输入集群['78']主库的状态[活/死]： 活动 注意：选择切换方式

-wiz-span">活着，不要关闭原来的主库

strong>死了，关闭原来的主库< /span >

将使用MHA的在线模式切换，主库不会关闭，'旧主库' ' 将被用作'新集群' 那么'从库'呢？ 【是/否]，默认否：是 ###是否切换[是/否]，默认否：是注：确认是否开始切换，确认是开始切换，不退出

3.7.2、切换后检查

<1>查看 mhaswitch 输出
<2>检查邮件
<3>查看实例状态报告

<4>查看新的主数据库访问等

<5>检查数据一致性等

3.8.切换示例

这里只是切换到在线模式的示例，故障转移模式类似 < /p>

3.8.1.切换前的集群拓扑

3.8.2、mhaswitch切换

3.8.3，切换后

拓扑

< p>电子邮件状态

输入时间< /span>： 大约10秒

切换时间 ：大约3-5秒

检查、更新和发送电子邮件时间： 5 秒

总计<跨度达ta-wiz-span="data-wiz-span">：18-20秒向左，向左，对业务写作时间的实际影响为3-5 秒大约

4.监测

4.1、MHA日常生活检查监测

检查ssh、repl、conf的正确性检查程序是mhacluster，结果存储在数据库中并使用django前端显示

命令为：

python mhacluster.py --options=check_all_mha_ssh_repl_conf

< p>前端报告为：

并支持自动修复，即根据错误情况进行修复，命令如下：

python mhacluster.py --options=auto_repair_all_mha_fail

4.2、relaylog_purge 监控

清理过期的relay_log，查看程序运行状态以及清理后的状态，存入数据库并显示在前端，命令为如下

python mhacluster.py --options=purge_relaylog_all

<跨度数据-wiz-span="data-wiz -span">前端：

4.3、状态检查示例

检查实例的运行状态，包括只读、从库IO、SQL线程、从库指向的主库IP、端口是否正确、主从延时、连接数、空间情况等，方便查看集群切换后的状态，快速定位问题

python mysql_check.py --options=check_all

< p>前端报表如下：

< h3>5.常见切换错误及处理

5.1.常见切换情况

<1>不切换，元信息等不改变

< p><2>已切换，部分从实例切换失败

5.2、MHA的masterha_check_ssh/repl检查失败，无法切换

情况：不切换，元信息未修改

原因：

masterha_check_repl 检查失败 原因有很多： < /p>

<1>无信任关系 span>

<2>账户权限问题

<3>主数据库设置没有问题，等

解决方案:

1,2 问题可以通过初始化mha环境解决

python mhacluster.py --options=add_mha_single_cluster --cluster_ids=1,2, 3

3问题：数据库不能切割，优先切割，是否写入配置文件配置错误，改正即可

5.3、MHA切换、部分从库切换失败

情况 ：有已切换，部分从库出现问题

原因：原因比较复杂，比如网络、更改命令本身无法执行（例如5.7的某些配置导致的）等.

处理ng：

<1>检查实例状态以确认哪些实例出现问题

查看报告：可以确认实例状态。例如：

<2>修复切换失败的从库

根据日志等情况修复或重做。

6.在线性能及优势

6.1、在线切换

现已成功上线，已运行4个多月，已切换上线集群6个以上（已切换上线测试环境30+）。目前还没发现问题

实际切换时间在秒左右（大多在3秒之间）-5s)

6.2，使用MHA环境前的情况

1.没有方便的工具可以快速切换集群的主数据库。当主数据库出现故障时：

< p>需要DBA花费5分钟 手动修改来自库的点， 2 -3 分钟检查集群状态，3-5 分钟修改元信息，

实际停机操作时间 3- 5分钟；等待总需求10- 20 分钟

（仅限 DBA 操作）

2.无需工具快速展示某个集群拓扑< span data-wiz-span="data-wiz-span">情况

3. 有没有快速查看实例运行状态的工具

6.3, 使用MHA环境后的情况

1.利用mhaswitch快速切换主库的工具

<1>可以降低数据丢失的风险

<2>影响写入 输入时间短，秒

A切换前后总共需要 5 个5大约几分钟（仅限 DBA 操作）， 实际关闭操作：3-30s左右（如果在线切换大约需要3-5秒，< span data-wiz -span="data-wiz-span">如果原主数据库开关停止，则大于10s< span data-wiz-span=“data-wiz-span”>）

DBA 效率增加50%-75% 向左，向左，< /span>如果速度很快< /span>总时间可以控制在1分钟内

在线实操：输入信息大约10秒、开关影响写入 3 -5s 左右，更新为检查等大约 9 秒，总计< /span>大约22-24秒

<3>mhacluster集成部署，几个小时可以自动部署所有mysql实例（目前近 700实例，近 500机器，实际部署和检查大约需要4-6小时）

<4>无需DBA手动修改主从，节省手动操作时间约10-20分钟

<5>无需DBA手动修改元信息，保存修改元信息时间3-5 分钟左右

无需DBA手动调整域名IP关系，节省调整域名IP时间< strong>1-3 分钟utes左右

<6>封装MHA，方便DBA使用，无需复杂的命令

<7 >邮件程序，发送完整信息，可以快速查看切换结果和日志等。

2.查询集群拓扑工具qmysql, 1秒查看集群拓扑

3.检查集群状态工具mysql_check、查询近700 实例 ，近 500 家台湾机器 仅大约30秒

4.Django前端展示，MHA监控和报告，方便监控MHA状态和排查问题等等

以上就是《MHA研究与应用样本分析》一文的全部内容，感谢您的阅读！相信大家都有了一定的了解..希望分享的内容对大家有帮助大家。如果您想了解更多知识，请关注行业资讯频道！