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的生产力,投入业务的优化工作中。

你可能感兴趣的:(MySQL实战宝典 高可用篇 19 高可用套件:选择这么多,该如何选?)