MYSQL MHA 如果网络不太好,怎么降低敏感度 (爱可生方案)

(最近网上热的是赵英俊,不是因为出了什么新歌,而是他离开了人间,.并且隐瞒了多年的病情以及敬业的精神,临死前还要吃镇痛片,录完了那个小红花,仅此纪念一个,有想法和敬业的人)

事情的这样说,不是每个单位的网络都是刚刚的, 有些情况下由于某些原因导致网络在改造前,各种的问题,如网络丢包,网络问题导致的通讯的问题等等, 但数据库中的高可用千不怕万不怕,就怕网络有问题.

网络出现问题,容易导致集群中的主节点被认为"溺水了", 导致最终的主节点被切换,有可能出现双主的尴尬现象. 所以网络的问题,可以导致数据库高可用集群"凋落",一个稳定可靠的网络是一个公司IT 整体正常的基础和保障.

那问题是如果网络不稳定,你怎么办, 听天由命,还是在搏一搏,看看自己有什么可以做的.

1 通过更多的网络节点来判断主库是否"失踪" 了

MHA 有一个参数 secondary_check_script ,实际上这个参数还有一个故事,我们公司因为网络的问题,导致一部分MHA 的主机切换,之前只想到一些后面要说的延迟的方法,但没有想到用 secondary_check_script 的方式来操作.其实还是学艺不深,没有想到这个方案.

后来我们和爱可生公司在MYSQL方面的合作,将这个问题抛出后,对方的技术人员在调查和研究我们的问题后,给出了一套方案. 所以既然人家的知识都送到嘴边了,难道还要人家喂. 自己赶紧好好的看看这个 secondary_check_script的参数.

原理是通过MHA 的manager 通过命令(自己或masterha_secondary_check 的方式),通过两个机器对你的MYSQL 的主机进行判断. 这个方案是不错的,也比较合适我们目前的情况.

那到此为止, 自己的在深入一下,否则囫囵吞枣,自己的脑子就白长了.

问题 1 ,这样的MHA的设置的方式是应该常态化,还是因为你们公司网络有问题而有意为之.

答: 经过查询资料,实际上这样的配置,应该是常态化,而不是光针对我们这样网络有问题的企业

问题 2 , 为什么网上的那些MHA 的文字基本上很少有这样的描述

答: 大部分企业有的还没有使用GTID, 即使使用了MHA 的软件版本还在0.54 转悠, 目前0.56 才支持这个参数,所以老的文字自然是不提这个参数. 所有MHA 的版本 建议0.56 及以上.

问题 3, 设置两个节点,应该选择哪两个节点 ?

这里有两个想法

1 如果是主 从 从 的结构 那么两个节点 可以选择两个从节点

2 在一个网段设置两个机器专门从事这个工作

实际上我个人的看法是 应该选择 2 , 1 到底有什么,试想如果几点切换了,你的配置文件是否需要再改变. 但转过来一项,如果从成本的原因想, 1 到时节省成本的方法.

所以各有利弊,自己知道就好, 能承受相关的缺点,并做出改变就好.

目前我们选择1

问题 4 , 如果在操作的过程中,什么情况不切换, 什么时候切换, ?

我们先看一个图

我们先从情况1 说起

如果管理节点到路由节点都是OK 的,就是两个路由节点到MYSQL的primary节点不OK , 那说的都不用说, 切换, 这是必须的

情况2

如果管理节点到路由节点都不可以,而路由节点到MYSQL的PRIMARY 节点是OK的, 那一定不切换

情况3

一条通道是OK 一条通道不OK ,那么不切换

所以通过上面的方式方法,即使网络出现一些丢包的情况,至少我们提高了对于网络的容忍度, 也就是网络的不稳定性的情况下 ,MHA 我们考虑了这个问题,并且也做出了应该做出的最大的努力.

另外上面提到的方案 2

其实就很简单了,增加判断的次数, 使用ping_interval 这个参数,增加MHA 对于故障的判断时间,来给网络出现故障的时候一个喘息的时间.

当然任何技术方案都没有那么完美的, 转换的时间加大, 架构变得更复杂了一些. 所以方案如人生, 方案没有好坏绝对而言, 适合的成本和付出成性价比的是我们要的, 人生起伏跌宕, 只要能爬起来,就好.