基于MHA+consul的MySQL高可用设计

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

基于MHA的高可用方案算是一种相对保守的使用，一方面也是为了兼顾低版本的历史问题。而采用MGR的过程，中间还有一些路和坑要走完，所以在快和慢之间，在数据一致性之外的高可用访问也是一个值得关注的地方。

传统的MHA+VIP是一种相对稳定的架构，可以申请一个VIP，然后对于应用来说是透明的访问方式，当然VIP的使用方式也存在一些瓶颈，比如：

1. 对于单机多实例的支持有限,
2. VIP本身没有业务含义
3. 对于跨机房容灾来说，VIP存在切换瓶颈

当然在一些特定的场景下还会触发“双主”的情况，所以对于高可用使用来说，总是有一大堆的改进要做。

基于MHA+consul的方案算是对原来问题的一个补充，也算是MHA 2.0版本的一个基本思想，那就是支持域名的高可用访问，对于业务来说，是更加透明的访问模式。基于consul的支持相对来说更加柔性，可以把consul server当做我们理解中的DNS服务器。我想这也是近些年来consul很火的一个重要原因吧。

我们在落地实践的过程中，也在逐步积累经验，当然总体的思想就是整个方案要比原来的更加稳定，可扩展，而且侵入性要小。我画了一个相对完整的设计图。在整个体系的建设中，有MHA Manager,consul server，当然还有CMDB

有的同学可能会存在疑问，CMDB凑什么热闹？

你的主从复制关系，MHA集群管理信息是在哪里存储，如果要找一个统一的存储入口，那就是CMDB,所以意味着切换的时候，不光MHA Manager要告诉Consul Server，还要告诉CMDB,这样一个流程化的操作，会带来一系列的联动变更，这样一来，整个流程是完整的链条。

在consul APi之外，CMDB除了要维护元数据一致性之外，还可以提供有意义的数据查询服务，比如我们开发了一个APi,可以推送任何维度的一个IP(比如实例IP,VIP,多网卡IP等）来得到真正的Master IP.

当然，MHA+VIP的方式到MHA+consul的方案是一个逐步过渡的过程，对于已有的MHA管理也是很有必要的，比如我们可以完全实现平台化的操作来得到MHA的管理信息。也可以基于任务调度来完成MHA的检查工作。