公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2018-09-26 23:56:55 · 原文链接

 这是学习笔记的第 1756篇文章

    高可用是整个业务建设中的核心和持续改进的地方，因为没有银弹，也没有终极方案，所以对于高可用建设不能掉以轻心。 高可用收到影响，那么我们常说的运维价值就会黯然失色。

    MySQL方向的高可用有什么迭代的思路呢。 我先说说自己的理解，欢迎补充和建议。 

    最原始的终极方案就是不需要高可用，完全单机，而且无备份裸奔状态，这种状态是万恶的根源，但是这种现象却似乎普遍存在，究其原因就是成本，当然在节省成本的时候我们最好还是得考虑下备份成本，否则恢复成本和这些成本不是一个数量级的。 

    当然好歹得有个一主一从或者根据业务需要有个一主多从，这基本是大多数MySQL数据完整性的一个初步方案吧，在这里还说不上是高可用，因为主库宕机，从库完全没有结果，高可用是业务的延续，而这里还没有正式启用。 

    在早期的版本里面是会大量使用MHA的，MHA有几个版本，在后期的版本中主要是做了binlog server的改进。 早期的版本中是主要使用偏移量的方式来完成数据的补齐和复制关系的重建，而GTID让整个切换过程更加高效，集群状态的检查效率都大大提高了。 MHA尽管早就已经不维护，但是因为经历了广泛的实践考验，尽管是用Perl写的，维护成本高，但是在行业里的认可度还是很高。当然基于这个工具我们是可以改写的，可以用Python或者go,主要的问题来了，就是这个重写的代价相对较高，一提到业务价值就会让这个工作的推动力打折。

    从MHA的实现原理来说，他只能保证数据完整性，对于应用来说，还不能够实现业务的可持续访问，因为主库宕机，从库接管，随之带来的就是IP的改动，在这个层面上，有多种实现方案，一种是使用VIP,相对便捷一些，根据IP漂移来实现业务可持续访问，这个在MHA层面是可以支持这种模式的，当然还有其他的模式，比如使用keepalive等。我们暂且把这个阶段成为第一期吧，这个阶段实现了从无到有的过程。 

    第二阶段就是跨机房的容灾了，我们需要考虑同机房的灾难情况，这种情况下使用DNS就是一种好的方式，这种方式有几个好处，一个是对于应用来说更有意义，因为域名相比IP可读性更强，另外域名的方式在网络服务支持的情况下，DNS就不存在IP跨机房漂移的难题了。 这种情况下使用服务发现的方式就是一种不错的解决方案，比如zookeeper或者是使用consul，都是一种行之有效的解决方法。 此外这种方式还有个优点就是可以解决单机多实例的一个潜在瓶颈。 

    当然在数据库方向是使用MGR或者InnoDB Cluster就是一个趋势了，在MGR方向上还是值得投入一定的时间精力去做好高可用方案的，因为有了MGR,就可以不用MHA了，而且MGR是一种数据一致性的解决方案，相对来说是具有权威性和方向引导力的。 

    在服务发现方面，做好了以后其实很多事情就可以做的更加平滑了，比如我们对外暴露的是DNS,而且可以支持跨机房的切换，那么我们都可以在业务低峰期在线完成跨机房切换或者平滑升级等操作，这样对业务的影响最低，也是几乎无感知的，数据库层面的价值就能够大大发挥出来 。