MySQL高可用方式的一些思考

2024-07-24 12:31:54

字体：大中小

来源：转载

供稿：网友

我在去年QCon和Gdevops广州站的时候，讲到MySQL和Oracle的现状和发展时，简单总结了下一个常见的使用误区：把MySQL当Oracle用，或者把Oracle当做MySQL用。

在我们身边这种情况太多，以至于很多重度依赖Oracle的人觉得MySQL太弱，MySQL的人觉得Oracle的方案扩展性不够好。其实可以从几个维度来看，我们今天就着重从MySQL的一些技术点来说起吧。

MySQL的高可用其实如果延展开来，可以从三个维度来考虑，应用层，数据库层，系统层（包含网络层）。假设数据库层面已经能够做到最好了，数据层面可以保持数据业务的访问，从网络层面来说，我们需要DNS的支持能够满足两个层面的高可用，一个是同城机房（或者同机房）的DNS高可用，另外一个是跨机房（跨区域）的DNS高可用，从数据库的业务诉求和网络规划来说，使用的DNS是不对外服务的，所以可以理解是local DNS的角色，这样一来，我们都不需要刻意去维护VIP的切换，网络层或者中间件层足够强大，我们只需要格外关注数据库服务的可用性和数据一致性就可以了。

如果往上层来看，就是应用层面，其实应用访问数据库服务使用域名，他压根不需要知道对应的IP是什么，就跟我们访问谷歌只需要知道是google.com就可以了。如果有了网络层面的高可用，保证一个DNS的生效策略，比如10秒，1分钟等，那么应用层需要的改造就是短连接或者是应用重连机制，因为毫无疑问程序端会有一层缓存，长连接很容易出现“迷失在过去状态”的情况。

所以一个较为完整的方案应该是系统层，网络层，数据库层和应用层来共同配合，才能保证一个基本的高可用方案。

如果要实现更为复杂的高可用，比如已经不局限于容灾，做双活多活等，其实整个架构的复杂度会高很多。

我就抛砖引玉，来说说MySQL高可用方案的一些想法。

大家知道MHA是MySQL DBA非常喜欢用的高可用方案，因为确实非常经典，我看了下代码的实现，逻辑的部分是非常的完善的，很多我们没有考虑到的点在代码层都做了校验。所以说MHA是一个非常成熟的方案，在大家的各种应用场景中发展壮大起来了。如果是早一些的版本使用MHA就是一个标准动作，大家知道MHA后期也有一些变化，一个是自0.56的版本开始引入了binlog server,在这个基础上有了0.57的版本，之后在github上就没有了版本更新。如果大家细细看看0.56和0.57的改进，主要的改动就是在数据完整性上的一个补充，当然这种架构方式对已有的快捷恢复来说会有一定的侵入性。所以我们很多公司用MHA，其实还是没有用binlog server的。MHA还有一个比较特别的地方就是对于网络异常的处理，其实0.56和0.57是有一些差别的，当然在细节测试的时候，其实碰到有些异常情况比较纠结，好像怎么解释都可以，所以以0.56和0.57为分水岭，对于网络的处理的差异来看，我是更倾向于0.56版本的，所以我们迭代测试了0.56,0.57然后又折回来补充了0.56的场景。

当然这个过程的收获是比较大的，也妆模作样的看了下MHA的一些代码，理了一下思路。但是我发现一个问题，相信很多朋友都有类似的感觉，那就是MHA是perl写的，实在是让很多人感到非常的陌生和别扭，因为perl语言本身的群体和易读性上是存在一些落差的，所以我们其实更倾向于用Python来实现这个事情，当然用其他的语言也可以，至少群体要大一些。

其实我在调研MHA的细节时，是打算在年后做MHA的代码python化工作的，但是我理了下自己的思路，发现这个事情其实做起来很有技术价值，但是投入和付出的成本落差是很大的，一来改造的难度很大，我得把Perl搞明白，然后用Python重写一遍或者理解了原来的逻辑，整理出缺点来，重新构建，我想了比较多的细节，对于MHA的缺点等等，这是技术上的投入，很大，而且很有难度，对个人成长是大有帮助的，但是从另外三个角度来说，我觉得可能实践意义不是很大了，第一是目前的技术方案MHA其实已经没有明显的优势了，第二我改造的版本如果足够好，公司内怎么推行，如果跑起来一直不出问题，那么实践意义其实不够大；第三我推广到社区里，大家是否能够接受，因为我面对的不是很多年前的一个状态，如何保证我写的足够好，或者说写正确了，这不是个拍脑袋的问题，一定是大量的细致测试才有说服力。

所以很多大公司其实在很早之前就把这个事情做了，当然可能只是不对外而已。当然对于MySQL的高可用，双活方案其实一直以来大家都有很多的解决方案，或者看起来行得通的经验。

比如双主，漏斗形的架构设计，其实在很多公司早期确实是这么干的，看起来这个方案没有特别的难点，但是处理这些临界点的问题的时候，还是要投入不小的功夫。这个方案我不打算多说，更多是在异常的处理上。

然后来说说MGR，其实完整说来，应该是InnoDB Cluster,我非常看好这个方案，可能很多人对此比较陌生，其实最先大家熟悉的是MGR, 如果把InnoDB Cluster比作三驾马车，那么是由MySQL Shell, MySQL Router,MySQL Group Replication三个组件共同组成，其中的核心组件就是MGR了。他的基因是真正的分布式，基于paxos协议。当然从数据架构的角度来说，基于复制的方案，可用性和完整性是有保证的，但是性能上是要衰减的，所以MGR干脆就限制了节点个数。这个和传统关系型数据库的节点的概念就不同了。

如果你留意下Windows安装版本的话，你会发现InnoDB Cluster已经打包成为了默认的安装服务了，里面提供了全面的安装配置过程，可以参考如下的链接：

一种快速安装InnoDB Cluster的方法

有很多人说InnoDB Cluster的方案要落入生产实践还有待考验，这个绝对没错，但是从方向上来说，他已经对早期的方案是一个很好的补充和改进了。他的三大组件，其实MySQL Router目前是一个短板，但是一旦这个短板不成为瓶颈，有了sharding等功能，那对于MySQL开源社区的影响是深远的。所以方案可以改进，就如同技术发展一样。我赞同那句话，没有最好的方案，只有最合适的方案。

（编辑：武林网）

上一篇：mysql+keepalived 双主热备高能用

下一篇：mysql安置出现 conflicts with mysql 的解决办法