MySQL高可用方案之MHA技术解读

MySQL高可用方案之MHA技术解读,第1张

  MySQL高可用方案中MHA绝地是一个相当成熟的实现。对于数据的切换,其实MGR也能很好的完成,也就是说,数据层面的角色切换已经刻意很平滑的做好了,但是对于访问IP的处理,还是有很大的空间,MHA提供了很多可选的空间来支持。

  常见的组合方式有:

  MHA+VIP

  MHA+keepalive

  MHA+Zookeeper

  当然MHA+VIP是一种很成熟和经典的方案了。

  一般来说都有以下类似的架构方式,假设架构模式为一主两从。对于应用访问来说,提供的IP信息就依据绑定的VIP地址为准。VIP可以根据节点的数据状态在不同节点间漂移,达到无缝切换的高可用。

  MHA Manager是一个核心的调度器,有了它可以调度多套环境,当然MHA Manager自身也有单点,所以会考虑两套MHA Manager节点来做冗余,实际上是做交叉互备,比如有100套环境,两个MHA Manager节点,那就每个分50个节点,如果Manager节点出现故障,可以很顺利的交接给Manager2来接管。

  对于应用来说,就是统一通过VIP的方式来访问。如果是在这个基础上考虑中间件的方案,则数据访问的策略会更加复杂一些。

  MySQL高可用方案之MHA技术解读,MySQL高可用方案之MHA技术解读,第2张

  对于这样的一个基本方案,如果从多个维度来下钻会发现有很多需要注意的地方,所以问题无处不在,可喜的是在MHA中几乎都考虑到了。如果说得简单点,主要有下面的几个场景需要考虑:

  数据库主库宕机

  数据库从库宕机

  重启数据库主库

  重启数据库从库

  从库应用延迟

  主从网络延迟

  主库服务器宕机

  从库服务器宕机

  一主多从切换优先级

  网络抖动的切换

  手工主从切换

  主节点IP调整

  从节点IP调整

  添加从节点

  剔除从节点

  网络抖动的预防

  半同步插件对于MHA的影响

  自定义MHA脚本

  所以上面的方案多多少少都需要考虑,如果用下面的图来表示,就会大体有如下的一些红色警告。所以各个层面都会有可能存在问题和异常,如何尽可能不影响业务,保持业务科持续访问是重中之重。

  MySQL高可用方案之MHA技术解读,MySQL高可用方案之MHA技术解读,第3张

  举一个比较纠结的问题,如果MHA Manager节点到数据库主库的网络发生抖动,导致短时间不可访问,我们是希望这个过程是不会做灾难切换的,但是如果时间过长了,有2分钟或者3分钟都不可访问,这个时候是切还是不切呢。这个时候信息还是相对较少的,如果我们加入应用服务器这个角色,如果应用服务器是可访问的,那么就不切,如果应用访问受到影响,那还是切吧。而且根据我们的测试,在MHA 0.56和0.57里面还是有一些差别。测试了多套环境,测试了多个特性,结合起来才会发现对于MHA的考虑会更加全面,而换句话说,了解了原委,才能更好的掌握MHA,也才能看到更多的问题,来尝试定制它,使得它更加满足于当前的业务需求。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/dianzi/2717061.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-08-17
下一篇 2022-08-17

发表评论

登录后才能评论

评论列表(0条)

保存