MySQL实战宝典 高可用篇 19 高可用套件：选择这么多，该如何选？

前面，我们了解了MySQL数据库的高可用解决方案，并且学习了怎么根据金融业务的需求，通过无损半同步复制的方式进行三园区的同城容灾设计，以及三地五中心的跨城容灾设计。

但是当数据库发生宕机时，MySQL的主从复制并不会自动的切换，这需要高可用套件对数据库主从进行管理。

高可用套件

MySQL的高可用套件用于负责数据库的Failover操作，也就是当数据库发生宕机时，MySQL可以剔除原有主机，选出新的主机，然后对外提供服务，保证业务的连续性。

MySQL复制时高可用的技术基础，用于将数据实时同步到从机。高可用套件是MySQL高可用实现的解决方案，复制切换新主机。

为了不让业务感知到数据库的宕机切换，这里需要用到VIP(Virtual IP)技术。其中， VIP不是真实的物理IP，而是可以随意绑定在任何一台服务器上。

业务访问数据库，不是服务器上与网卡绑定的物理IP，而是这台服务器上的VIP。当数据库服务器发生宕机时，高可用套件会把VIP插拔到新的服务器上。数据库Failover后，业务一九访问的还是VIP，所以所用VIP可以做到对业务透明。

下面这图显示了业务通过VIP进行数据库的访问。

通过VIP进行访问

MySQL的主服务器的IP地址为192.168.1.10，两个从服务器的地址分别为192.168.1.20和192.168.1.30。上层服务访问数据库并没有直接通过物理IP192.168.1.10，而是访问VIP 192.168.1.100，这时，如果MySQL主服务器发生宕机，会进行如下处理：

VIP迁移

发生故障迁移后，由于上层服务器访问的仍然是VIP 192.168.1.100，所以切换对服务来说是透明的，只是在切换工程中，服务会收到连接数据库失败的提示。但是通过重试机制，当下层数据库完成切换后，服务就可以继续使用了。所以，上层服务一定要做好错误重试的逻辑，否则就算启用了VIP，也无法实现透明的切换。

VIP的局限性，仅限于同机房同网段的IP设定。如果是我们之前设计的三园区同城跨机房容灾架构，VIP就不可用了。这时就要用名字服务，常见的名字服务就是DNS（Domain Name Service），如下图所示：

通过DNS解析域名

从上图可以看到，这里将域名m1.xxx.comd对应的IP指向为192.168.1.10，上层业务通过域名进行访问。当发生宕机，进行机房级切换后，结果变为：

DNS迁移

当发生Failover后，高可用套件会把域名指向为新的MySQL主服务器，IP地址为202.177.54.20，这样也实现了对于上层服务的透明性。

虽然使用域名或其他名字服务可以解决跨机房的切换问题，但引入了新的组件。新组件的高可用问题也需要特别注意。在架构设计时，请咨询公司提供名字服务的小组，和他们一起设计高可用的容灾架构。

MySQL常见高可用套件

MHA（Master High Availibility）

MHA是一款开源的MySQL高可用程序，它为MySQL数据库主从复制提供了自动主机故障迁移的功能。MHA由两大组件组成。

• MHA Manager通常部署在一台服务器上，用来判断多个MySQL高可用组是否可用。当发现有主服务器发生宕机，就发起Failover操作。MHA Manager可以看作是Failover的总控服务器。
• MHA Node部署在每台MySQL服务器上，MHA Manager通过执行Node节点的脚本完成failover切换操作。

MHA Manager和MHA Node通过SSH的方式进行通信，也就是需要在生产环境中打通MHA Manager到所有MySQL节点的ssh策略，那么这里就存在潜在的安全风险。

另外，ssh通信，效率并不是很高。所以，MHA比较适合用于规模不是特别大的公司，所有MySQL数据库的服务器数量不操作20台。

MHA.png

Orchestrator

Orchestrator也是一款开源的MySQL高可用套件，处理支持failover，还可以完成MySQL数据库的一些简单的复制管理操作。提供了HTTP接口来进行相关数据库的操作。

Orchestrator.png

其实现原理与MHA是一样的，只是把元数据信息存储到元数据库中，并且提供了HTTP接口和命令的访问方式，使用上更为友好。但是由于管控节点到下面的MySQL数据库的管理依然是ssh的方式，依然存在MHA一样的短板问题，总的来说，关于Orchestrator，依然只建议使用在较小规模的数据库集群。

数据库管理平台

当然了，虽然MHA和Orchestrator都可以完成MySQL高可用的failover操作，但是，在生产环境中如果需要管理成千乃至上万的数据库服务器，由于它们的通信采用ssh的方式，并不能满足生产上的安全性和性能的要求。

所以，几乎每家互联网公司都会自研一个数据库的管理平台，用于管理公司所有的数据库集群，以及数据的容灾切换工作。

接下来，就带你了解数据库管理平台的架构。

dms.png

上图中的数据库管理平台是用户操作数据库的入口。对数据库的大部分操作，比如数据库的初始化、数据查询、数据备份等操作、后续都能在这个平台完成，不用登录数据库服务器，这样的好处是能大大提升数据库操作的效率。

数据库管理平台提供HTTP API的方式，可以前后端分离的方式支持Web、手机等多种访问方式。

元数据库用于存储管理MySQL数据库所有的节点信息，比如IP地址、端口、域名等。

数据库管理平台Manager用来实际控制下面的所有MySQL节点，Manager和后端MySQL的通信通过MySQL服务器上部署的agent方式进行。两者通过BP协议以grpc的方式通信。这样解决了ssh的不安全性和性能问题。

其中，agent用来上报数据库各节点的状态给Manager，管理节点Manager通过上报的信息判断数据库是否宕机，是否需要进行切换，切换到哪个节点。

上图的设计，能完成一个比较基本的数据管理平台。另外，每个公司有自己的一些需求，也可以做到数据库管理平台中，比如安全要求、审计需求、工单系统等。

所以，有了数据库管理平台，数据库的高可用切换、数据库日常管理和访问，都可以由平台自动完成。有了数据库管理平台，才能真实实现数据库管理的无人驾驶。

总结

• MySQL复制技术本身不能实现failover的功能。所以需要借助MySQL的高可用套件。
• 采用VIP和名字服务机制，可以实现下层故障迁移的透明性，VIP仅用于同机房同网段，名字服务可用于跨机房的切换。
• MHA和Orchestrator都是MySQL的高可用套件，可以完成failover的工作。但是由于管理节点与MySQL通信采用ssh协议，所以安全性不高，性能一般。一般建议用在不操作20台数据库节点的环境中。
• 对于要管理MySQL数量比较多的场景，推荐自研数据库平台，这样能结合自家公司的特性，设计出MySQL数据库的自动管理平台，这样才能解放DBA的生产力，投入业务的优化工作中。