Orchestrator 在好未来数据库高可用系统中的应用

一

前言

MySQL作为目前最流行的关系型数据库，在集团内部被大量应用，有着千级别的实例规模，承载着培优、网校等核心业务系统的数据存储功能。
而原有的高可用方案，随着数据库架构因业务发展不断演变，已无法满足业务对服务可用性及数据可靠性的极致要求：
1、旧高可用方案在网络抖动的场景下，存在不切换与误切换情况，无法满足对可用性99.99%的要求。
2、旧高可用方案因切换过程中未考虑从库同步延迟的情况，存在主从切换后数据丢失的问题，无法满足对数据可靠性的要求。
3、旧高可用方案为闭源产品，不支持定制化开发，可扩展性差，无法与中间件及管控平台形成联动，无法实现故障的自动转移。

二

选型

为了给业务提供一个具备高可用、高安全、高稳定能力的数据库服务，所以我们需要建设一套具备如下特性的数据库高可用系统：
1、具备快速止损能力；
2、切换过程中能够确保切换的准确性与数据完整性；
3、具备跨机房切换能力和可扩展、易迁移特性。
带着以上的目标我们对市面上主流的数据库架构进行了对比分析：

基于以上的调研结果，最终决定基于Orchestrator进行二次开发，Orchestrator是近年出现的基于GO语言编写的MySQL HA开源管理工具，相较与传统的HA（MHA、MMM等）管理工具，Orchestrator提供了展示MySQL复制拓扑关系及状态的Web界面，支持在Web界面管理、变更数据库复制，同时Orchestrator提供了丰富的命令行指令和API接口，并支持多节点集群方式部署。

三

架构

● 3.1 Orchestrator特点

首先我们对Orchestrator进行了深入了解，掌握了它的如下特点：

• 支持通过图形界面操作或调用接口的方式来变更数据库拓扑；

• 提供多个Hooks接口便于定制化开发与运维管理；

• 本身支持多节点，通过raft协议保证集群高可用；

• 支持多种类型恢复：自动恢复、优雅的恢复、手动恢复、手动强制恢复；

• 全面的选主逻辑，确保在切换过程中可以选择出最适合的节点来承担新主的角色；

• 支持自动检测主库异常：主库故障检测，Orchestrator会同时连接主库和从库，当管理节点检测到主库异常时，会通过从库再次确认主库是否异常，这样规避了一些对主库故障错误判断的场景；

● 3.2 Orchestrator故障探测

同时我们对Orchestrator的架构以及故障探测逻辑进行了分析，确定了Orchestrator的故障切换逻辑：
Orchestrator集群每个节点会与MySQL的主库和所有从库各建立三个长连接，每隔InstancePollSeconds秒（默认5秒）进行一次topology discovery，并将读取到的实例信息保存在自有的MySQL中，然后通过读取到的数据为依据来判断主库是否存活；
当检测到主库故障时，同时会检测所有从库的同步状态，如果主库故障且所有从库的复制状态也是异常，才会判定为实例故障（二次确认），当确定主库故障之后，会在所有可连接的从库中根据以下条件选择出一个节点担任主库，并将其他从库Change到新主库下，从而完成整个故障切换。

● 3.3 Orchestrator选主逻辑

四

升级改造

●  4.1 从库故障探测

在对Orchestrator的研究过程中，我们也发现了一个问题，由于其架构中只考虑了主库提供业务的场景，但是在我们的业务场景中从库同样承担了业务查询的流量，因此我们需要对其进行改造升级。
做的第一个改造点，添加从节点故障探测能力，以确保从节点故障的时候，同样会被高可用系统感知到，并且可以发起故障摘除，避免业务长时间受损。

●  4.2 现有组件联动

在公司内部的数据库架构中，业务通过中间件来访问后端的数据库，在加入了高可用组件之后，虽然可以做到实例的故障探测，以及故障切换，但是由于没有和中间价层进行联动，从而导致在发生故障切换的时候业务还是不能够访问到切换之后的数据库，我们根据Orchestrator在完成故障切换之后可以调用钩子函数的特性，添加了高可用联动程序，打通了高可用组件到中间件层的链路，以确保切换之后的拓扑可以第一时间被中间件层感知到，从而使得业务可以通过中间件层正常的访问到切换之后的数据库拓扑。

●  4.3 数据库管控平台与高可用组件的联动

日常工作中，除去实例因为某些不可抗因素触发的主动切换之外，还有一部分情况是，某个集群的压力过大，需要进行从节点扩容，某个服务器硬件异常，需要进行集群拆分迁移、实例下线等日常维护的需求，这类情况高可用系统同样进行了支持。

●  4.4 最终构架

整个数据库架构中由orchestrator负责对数据库集群进行实时监测，确保在实例故障的时候，第一时间发起切换，保证数据库上游的中间件组件可以及时感知，同时负责通知下游的数据库管理系统进行数据修正，以保障其工单、查询、备份等功能的正常运行，最终实现上游的业务系统与下游的研发老师的访问请求可以在最短的时间内访问切换之后正确的数据库拓扑，确保数据库服务的可用性。

五

故障场景测试

至此高可用组建核心功能已经具备，在上线之前我们进行了详细的故障场景测试：

• 上下游联动的稳定性；

• 切换之后的告警情况（是否报警、报警升级）；

• 确保高可用系统上线之后的切换准确性，以及是否覆盖所有故障场景。

六

未来展望

●  6.1 高可用系统在多机房结构中的应用

未来我们将依据Orchestrator自己自身的raft特性，将Orchestrator节点部署于多个机房中，当某个机房故障或者出现网络隔离的时候，依据多数一致的特性，在可用的机房中选出主库，同时发起故障切换，而故障机房中的dbproxy由于连接不上Orchestrator中的leader节点，进行自我下线，最大限度的避免数据双写，从而使得数据库层具备机房级故障切换能力。