前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >阴沟翻船之 MYSQL MHA 故障 SSH timeout 与 Binlog not found

阴沟翻船之 MYSQL MHA 故障 SSH timeout 与 Binlog not found

作者头像
AustinDatabases
发布于 2019-10-24 11:35:38
发布于 2019-10-24 11:35:38
1.2K0
举报
文章被收录于专栏:AustinDatabasesAustinDatabases

MYSQL MHA 的安装估计很多地方都是自动化安装的了,流水线方式。个人安装的MHA 的集群虽然没有几百台,但基本上已经突破了三位数,按理说安装应该是不会出什么奇怪的事情,但实际上每天都有新鲜事。

最近就阴沟里面翻船了,在MHA 的安装过程中遇到了一些错误,废了点劲。

故障1

大家可以从图上看出报错的信息,关键错误我沾到下边

[warning] HealthCheck: Got timeout on checking SSH connection to 10.5.7.76! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 342.

- [warning] Failed to SSH to binlog server 10.5.7.76

- [warning] HealthCheck: Got timeout on checking SSH connection to 10.5.7.77! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 342.

- [warning] Failed to SSH to binlog server 10.5.7.77

- [warning] HealthCheck: Got timeout on checking SSH connection to 10.5.7.78! at /usr/share/perl5/vendor_perl/MHA/HealthCheck.pm line 342.

- [warning] Failed to SSH to binlog server 10.5.7.78

[error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln239] Binlog Server is defined but there is no alive server.

从错误信息看,已经很明确的告知有两个问题 1 SSH timeout 2 由于SSH 连接上有问题,提取binlog 有问题,无法进行获取。

所以问题的关键点就 转移到了SSH 的连接上,经过尝试 SSH 连接的确很慢,初期是怀疑网络问题,但测试 PING Telnet 等方式都很快,并不像是 网络问题。

所以解决问题的关键点,转移到SSH 为什么连接这么慢,经过查询后,

图上的地方的白色就是开始等待时间 较长的地方,大约每次连接SSH就在那个地方需要等待7-10秒左右。

根据相关的文档和类似问题,定位到由于DNS 反向解析的造成的连接较慢的原因。

相关文档也给出可以在 sshd_config 里面 添加 UseDNS = no 以及 将 GSSAPIAAuthentication no 设置上就不会出现非网络原因的SSH 超时了

但实际上及时修改了上面的SSHD的配置并且从启动SSHD 服务 ,MHA还是继续报同样的错误。

实际上解决这个问题很简单,就是在每台机器的/etc/hosts 上注册机器的地址和IP 之间的 关系,将所有MHA 涉及的机器都放到里面,问题就解决了。

其实这不是什么新鲜的东西,只是以前安装的过程中,LINUX 的系统人员要不就是配置 了,要不就是 DNS 的解析速度并没有导致相关的问题发生。

如果仅仅按照上面的错误提示,大部分的页面都是在提出没有开启BINLOG 导致的,实际上并不是。

故障2

看到上面的问题,提示说找不到文件目录,并且提示要在配置文件中设置BINLOG 的位置,这样的报错,一般发生在 设置了BINLOG (使用GTID)Server 的服务器

但如果你再次核对你的配置文件,估计也 不会发现什么失误。主要的问题在于你的MYSQL 服务器的BINLOG 的mysql-bin.index 里面注册的当前MYSQL 有的BINLOG 文件数量不一致。

可以看到其中一台机器的BINOG 直到了mysql-bin.000001 而其他的已经 到了 000003 , 怎么办, 只需要将所有的MYSQL 的 binlog 的编号统一就可以解决问题了

其实MHA 的配置本身并不难,但设计的东西比较多,并且注意的权限,网络方面的注意,MYSQL本身配置等等在一起就显得混乱,如果没有章法的去做很可能会忽略一些东西,结果就是故障频发,然后还的费劲心里的去解决,所以标准化这个东西在某些这样的事情上就显得非常重要了。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-10-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 AustinDatabases 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
故障分析 | 如何提高 MHA 的网络容忍能力?(上)
爱可生交付服务部团队北京 DBA,主要负责处理 MySQL 的 troubleshooting 和我司自研数据库自动化管理平台 DMP 的日常运维问题,对数据库及周边技术有浓厚的学习兴趣,喜欢看书,追求技术。
爱可生开源社区
2021/03/16
8010
故障分析 | 如何提高 MHA 的网络容忍能力?(上)
CentOS 6.5下MySQL MHA 报错解决方法
Sat Mar 23 07:17:50 2019 - [info] Connecting to root@192.168.32.181(server2:22)..  Checking slave recovery environment settings..  Opening /data/mysql/relay-log.info ... ok.  Relay log found at /data/mysql, up to server2-relay-bin.000005  Temporary relay log file is /data/mysql/server2-relay-bin.000005  Testing mysql connection and privileges..sh: mysql: command not found mysql command failed with rc 127:0!
星哥玩云
2022/08/17
5000
实现MySQL高可用之MHA过程错误记录集
MHA 集群是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。目前在 MySQL 高可用方面是一个相对成熟的解决方案 ,在 MySQL 故障切换过程中,MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
肓己
2021/08/12
1.3K0
带你玩转MHA高可用集群
一、简介 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,现在很多大型的电商网站都采用此解决方案例如:某宝、某东、某会,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内手动或自动(如需自动需结合使用脚本实现)完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用性,就因为有此特性,受到很多大型电商网站的宠爱
小小科
2018/05/04
8920
带你玩转MHA高可用集群
mysqlbinlog can not parse row based events
    最近的MHA测试过程中,碰到了mysqlbinlog客户端的版本低于服务端版本的问题。即这个错误提示:mysqlbinlog is 3.2 (included in MySQL Client 5.0 or lower), but MySQL server version is 5.6.22-log. mysqlbinlog can not parse row based events。这个应该是个比较常见的错误。主要是由于在安装Linux期间通常在自带安装mysql相关rpm包,后来又安装了高版本的mysql而引发的一些版本问题。下面是这个问题的主要描述。
Leshami
2018/08/13
9280
遭遇DBD::mysql::dr::imp_data_size unexpectedly
    最近的MHA验证时,遭遇了DBD::mysql::dr::imp_data_size unexpectedly这个错误。而DBD这个包已经是安装过了的。下面是这个问题的描述和解决方案。
Leshami
2018/08/13
7780
搭建MHA时 yum 安装perl模块提示 baseurl 错误
今天在搭建MySQL MHA  安装MHA node所需的perl模块(DBD:mysql)时遇到了一个小的错误,如果思路不对的话,还是产生不少麻烦。
星哥玩云
2022/08/17
1.8K0
搭建MHA时 yum 安装perl模块提示 baseurl 错误
MySQL高可用架构-MHA环境部署记录
一、MHA介绍 MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是日本的一位 MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性。是一套优秀的作为MySQL高可用性 环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成
洗尽了浮华
2018/01/22
3.6K1
MySQL高可用架构-MHA环境部署记录
MySQL高可用之MHA
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司 youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升 的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且 在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。 MHA里有 两个角色一个是MHA Node(数据节点)另一个是MHA Manager(管理节点)。 MHA Manager可以单独部署 在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台 MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新 数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完 全透明。
小手冰凉
2020/07/03
1.6K0
MySQL MHA部署与测试-下篇
此命令一般不会在生产环境使用,只用于测试 1、需要关闭mha-manager,不然切换无法执行成功。报错如下:
仙人技术
2021/08/31
6510
故障分析 | MHA 切换的一个“坑”
遇到这个报错内心是懵的,明明切换前检查集群状态、masterha_check_repl都是正常的。嗯……还是对 MHA 的原理了解不够深入。
爱可生开源社区
2021/09/08
9180
MySQL高可用方案MHA的部署和原理
MHA(Master High Availability)是一套相对成熟的MySQL高可用方案,能做到在0~30s内自动完成数据库的故障切换操作,在master服务器不宕机的情况下,基本能保证数据的一致性。
用户2038009
2021/03/08
6K1
听说Mysql你很豪横?-------------搭建MySQL MHA实现数据库高可用( MySQL MHA概述、 搭建 MySQL MHA、 MySQL MHA 故障切换)
MHA目前在MySQL高可用方面是一个相对成熟的解决方案 但是在搭建的过程中会经常报错,且MHA的构建综合了主从复制,所以MHA的安装要思路清晰才可
不吃小白菜
2020/09/03
4.4K0
听说Mysql你很豪横?-------------搭建MySQL MHA实现数据库高可用( MySQL MHA概述、 搭建 MySQL MHA、 MySQL MHA 故障切换)
MHA 源码阅读 第01期:MasterMonitor
MySQL 的高可用方案很多,MHA 算是其中最流行的一种方案之一。目前最新的版本是 0.58,它由两部分组成:管理端(manager)和客户端(node)。了解一个开源项目,阅读源码是一个很不错的选择,我们先从 manager 开始。
数据库交流
2022/04/25
7970
MHA 源码阅读 第01期:MasterMonitor
MySQL高可用架构之MHA
简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。 该软件由两部分组成:MHA Manager(管理节点)和MHA
老七Linux
2018/05/31
2.7K0
安装MHA中清理Relay log报错
[root@MHA3 ~]#  /usr/bin/purge_relay_logs --user=root --password=123456 -disable_relay_log_purge --port=3306 --workdir=/opt/mysql/data/ 2014-08-27 09:19:30: purge_relay_logs script started. install_driver(mysql) failed: Can't locate DBD/mysql.pm in @INC (@INC contains: /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .) at (eval 6) line 3. Perhaps the DBD::mysql perl module hasn't been fully installed, or perhaps the capitalisation of 'mysql' isn't right. Available drivers: DBM, ExampleP, File, Gofer, Proxy, Sponge.  at /usr/bin/purge_relay_logs line 162
星哥玩云
2022/07/03
7270
MySQL MHA配置常见问题
    MHA在MySQL数据库中被广泛使用,它小巧易用,功能强大,实现了基于MySQL replication架构的自手动主从故障转移,从库重定向到主库并自动同步。尽管如此,在部署配置的过程中,由于疏忽总难以避免这样或那样的错误。本文是对MHA配置中常见问题的一个汇总,供大家参考。
Leshami
2018/08/13
1K0
MySQL高可用之MHA集群部署
很多小伙伴反映说网上的MHA教程甚至收费的课程里的MHA教程都存在坑,不少教程只是搭建完成了,是否真的能在主库宕机时自动切换不得而知,鉴于此情况,简单写了一个MHA集群的搭建步骤。由于搭建的次数较多,没踩到过多的坑(坏笑),所以没有写太多的排坑方法,如果小伙伴们在部署的过程中遇到问题可以和我沟通,文中如有问题欢迎斧正。
俊才
2020/05/26
1K0
MySQL高可用之MHA集群部署
MHA 切换的2个异常(masterha_master_switch line 53)
        MHA 在测试手动故障转移和在线切换的过程中,碰到了2个比较诡异的问题,在使用IP地址调用的时候均无法测试成功,出现了Detected dead master xxx does not match with specified dead master以及xxx is not alive。下面是这2个错误问题的描述及解决方案。
Leshami
2018/08/13
4720
故障分析 | 数据库故障 MHA 未切换
这里暂且不说 hang 住的原因,仅分析数据库 hang 住,但是 MHA 未触发切换。
爱可生开源社区
2022/04/06
1.2K0
相关推荐
故障分析 | 如何提高 MHA 的网络容忍能力?(上)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档