京东数据库智能运维平台建设之路

副标题#e#

运维自动化来源于工作中的痛点，京东数据库团队面对的是商城成千上万的研发工程师，这种压力推动我们不断变革，然而变革不是一蹴而就，也经历过从手工到脚本化、自动化、平台化、智能化的艰难转变，所以说是需求在驱动运维体系的建设，而运维自动化的真谛在于解放运维人员，促进人率提升，减少人为故障，要学会培养自己“懒”这个好习惯。

京东的自动化运维体系建设始于2012年，下面从两个方面进行介绍：

一、京东数据库智能运维平台

京东业务每年都在以爆发的形式在增长，数据库服务器的数量众多，产品线也多达上千条，要支持如此庞大的业务体系，需要一套完善的运维自动化管理平台。目前京东MySQL数据库管理平台简称DBS，主要涵盖以下内容：完善的资产管理系统、数据库流程管理系统、数据库监控系统、数据库故障管理系统、数据库报表系统、弹性数据库系统以及数据库辅助运维工具，涉及DBA运维的方方面面，实现了DBA对MySQL的自动化、自助化、可视化、智能化、服务化管理，避免DBA因手工操作失误带来的生产事故，保障京东数据库的安全、稳定、高效运行。

这里着重介绍以下部分核心功能组件：

1、元数据管理

作为自动化运维的基石，它的准确性直接关系到整个数据库管理平台的可靠性。京东数据库管理平台从数据库业务方、DBA的运维习惯等方面出发，涵盖机房、主机、业务、集群、实例、库、表等多个维度：

• 机房和主机维度：主要记录硬件方面的信息。
• 业务维度：主要记录业务的名称、等级及业务部门相关信息。
• 集群维度：主要记录MySQL集群架构信息。
• 实例维度：主要记录MySQL的相关参数，为后续自动化运维提供保障。
• 库维度：主要记录数据库名称及业务人员联系信息。

2、自动化部署

面对繁杂的数据库新增，扩容等运维工作，利用自动安装部署平台可以彻底解放DBA。目前京东的自动化部署系统包含申请服务器、部署数据库实例、同步数据、一致性校验、拆分及切换等操作，整个过程流程化，包含各级业务及DBA的操作审批，最终达到全面的MySQL服务的自动化和流程化部署，如下图：

主要功能点包含以下内容：

• 安装部署MySQL实例，架构搭建，域名申请。分配规则要求同一集群主从实例不能在同一机柜，硬件性能好的主机优先为主库。
• 监控部署，备份部署，资产注册。
• MySQL服务采用镜像的形式创建，镜像依赖于K8S的镜像仓库。
• 应用账号是应用方通过自动化上线系统申请创建的。
• 主从数据一致性校验，通常会选择夜间业务低峰期定时执行。

3、智能分析与诊断

京东的智能分析与诊断涵盖4部分重要的内容，数据库监控指标采集、诊断分析、故障自愈、趋势分析：

（1）监控系统

监控系统为数据库管理提供了精准的数据依据，能够让运维人员对生产服务系统运行情况了如指掌，核心的监控指标包含：OS负载、MySQL核心指标、数据库日志等。通过分析获得的监控信息，判断被监控数据库的运行状态，对可能出现的问题进行预测，并给出优化方案，保证整个系统稳定、高效。

京东的分布式监控系统采用被动模式，server端和proxy端均做高可用，防止单点故障。以下是整体架构和流程图：

（2）监控性能分析

数据库性能智能分析，主要是对数据库监控数据的二次分析，排除安全隐患。在实际的生产中，有些隐患没有达到设置的报警阈值，处于一个报警的临界点，其实这种情况是最危险的，随时可能爆发，为解决这些隐患，我们通过对监控数据的环比、同比、TOP指标等方面进行分组汇总分析，提前发现隐患。

慢SQL分析：

索引分析：

空间分析及预测：

锁分析：

（3）故障自愈

故障出现的形态千奇百怪，而最核心的内容依赖于监控的辅助分析，如何提供最为精准的信息，所做内容如下：

• 告警过滤：将告警中不重要的告警以及重复告警过滤掉 
• 生成派生告警：根据关联关系生成各类派生告警 
• 告警关联：同一个时间窗内不同类型派生告警是否存在关联 
• 权重计算：根据预先设置的各类告警的权重，计算成为根源告警的可能性 
• 生成根源告警：将权重最大的派生告警标记为根源告警 
• 根源告警合并：若多类告警计算出的根源告警相同，则将其合并 

4、智能切换系统 

京东数据库服务器的量级较大，会导致出故障的概率相对提高，同时对系统稳定性的要求也较为苛刻。因此为确保实现数据库高可用，保证7*24小时的持续服务，我们团队自主研发了数据库自动切换平台，实现了自动和半自动两种切换方式，实现了按单集群级别、多集群级别、机房级别等多维度的场景切换。切换过程包含监控的修改、资产信息的修改、备份策略的修改、主从角色的修改等，一键化完成，避免人为因素带来的二次故障。

（1）分布式检测

#p#副标题#e#

递增资源是指资源的使用率不会再短时间之内出现严重的波动，而是会缓慢增加，并且支持递增，不会出现减少的情况，这种资源主要包括硬盘。ContainerDB对于不同的资源采取了不同的调度策略。针对于瞬时资源，ContainerDB为每个数据库分配三种标准：

• 下限：2C/4G，上限：4C/8G  
• 下限：4C/8G，上限：8C/16G 
• 下限：8C/16G，上限：16C/32G 

每个容器分配的初始资源为标准的下限值，当数据库服务出现CPU负载过高或者内存不足时，会尝试申请多于下限的CPU或者内存，但绝对不会超过上限，待负载恢复后释放多申请的资源，直至恢复至CPU和内存的下限为止。

针对递增资源：磁盘，在业务接入之初，统一分配64G的硬盘，每当当前磁盘使用率达到80%，且没有达到256G上限的时候，则进行垂直升级；若容器当前磁盘达到了256G上限则进行在线Resharding。

垂直升级：首先会进行资源check，看宿主机是否有足够的剩余硬盘资源进行垂直升级，若check通过，则会在宿主机施加全局资源锁，并对硬盘进行垂直扩容再增加64G。若check不通过，则在宿主机上提供一个硬盘大小为：磁盘容量+64G大小，CPU和内存与当前容器相同的新容器，并将数据库服务迁移到新的容器上。垂直升级是瞬间完成的不会影响数据库服务。

在线Resharding：申请两个新的Shard，新Shard中的数据库Container的硬盘、CPU和内存标准与当前Shard中的完全一致，根据当前Shard中的数据库主从关系，对新Shard中的所有数据库重建MySQL主从关系，然后启动Schema信息拷贝和过滤复制，最后更新路由规则并将读写流量切换到新的Shard上，将旧的Shard资源下线。

无论是垂直升级还是在线Resharding，都需要注意一个问题：在保证每个分片的Master在主机房的前提下，尽量不要将所有的资源都分配在一个宿主机/机架/机房，ContainerDB提供了强大的亲和/反亲和性资源分配能力。目前ContainerDB的亲和/反亲和性策略如下：

每个KeySpace都有一个主机房，属于同一个Shard中的数据库实例（目前一个shard中包含1主2从）的资源分配尽量应该满足：Master必须属于主机房，不能有任意两个实例属于同一机架，不能有任意三个实例在同一IDC，这种策略可以避免某一机柜掉电而导致主从同时出现故障，也可以避免IDC故障从而导致所有数据库实例均不可用。

#p#分页标题#e#

由于是尽量满足，所以当资源池中的资源分布不均时，就有可能在资源分配的时候满足不了上述的反亲和性策略。因此ContainerDB有一个常驻后台进程，不停的轮询集群中的所有Shard，判断Shard中的实例分布是否满足反亲和性规则，若不满足，就会尝试进行实例重新分布。重新分布时为了不影响线上业务，会优先进行从库重分布。

基于弹性调度的能力ContainerDB实现了如下三个功能：

• 在线扩容：当某个Shard的数据库负载达到阈值后，会自动触发Shard的在线垂直升级、迁移或者Resharding。 
• 在线自愈：当Shard中的某个MySQL实例出现故障，ContainerDB首先判断出现故障的实例是否为master，若是master，则选择GTID最大的slave作为新的主，并进行复制关系重建和Slave补齐；若不是master，则直接进行slave补齐。 
• 在线接入：ContainerDB允许用户以完全自助化的方式启动数据在线迁移与接入任务，该任务会将传统MySQL数据库中的数据在线迁移到ContainerDB中，待数据迁移完毕后，自动进行域名切换，完成业务系统数据源的在线无感知迁移。 

ContainerDB通过在线服务能力扩容、在线自愈和在线接入三大功能，实现了京东数据库服务的Always Online保证。

（3）不止于调度

弹性和流式的资源交付与调度是ContainerDB的基石，但是除了这两个核心功能之外，ContainerDB还在用户易用性、兼容性和数据安全性等方面做了很多工作，包括：

数据保护

在传统的直连数据库的方案下，当Master出现网络不可达时，一般都会选择新的Slave变为Master，然后将原来Master上的域名漂移到新的Master上。但是这种方案在网络抖动的情况下很容易由于AppServer上的DNS缓存，而导致双Master，并且出现脏写的情况。从整体架构图可以看出，ContainerDB与用户之间通过Gate连接。Gate是一个集群化服务，多个Gate服务都映射到一个域名下，Gate通过IP地址直接访问各个MySQL服务，而且Gate对各个MySQL角色的识别完全依赖于元数据服务：Topology。当ContainerDB中某个MySQL的Master产生网络不可达时，会选出新的Master，并更新路由元数据信息，最后才做Master切换，这样就避免了由于网络抖动和DNS缓存而在成双主和数据脏写，从而对数据进行了严格的保护。

流式查询处理

ContainerDB通过在Gate层实现基于优先级的归并排序提供了快速流式查询的功能，在进行大批量数据查询时，能瞬时返回部分查询结果数据，极大提高客户体验。

无感知数据迁移

ContainerDB通过在交叉在Window函数中分别执行部分存量数据拷贝和增量数据追加的算法，开发了在线数据迁移和接入工具JTransfer，通过JTransfer可以将传统MySQL数据库中的动态数据迁移到ContainerDB中，当ContainerDB中的数据与源MySQL中的数据的lag小于5秒时，首先会将源MySQL停写，待lag变为0时将源MySQL的域名漂移到Gate集群，整个迁移过程用户AppServer无感知。

兼容MySQL协议

ContainerDB完全兼容MySQL协议，支持标准MySQL客户端和官方驱动程序接入，并且支持大部分ANSI SQL语法。

路由规则透明

#p#副标题#e#

ContainerDB与用户之间通过Gate集群进行连接，Gate根据用户发送的查询语句形成的语法树和查询执行计划得到查询中涉及到的所有表，并根据Topology中的元数据信息获得各个表的分片信息，最后结合语句中的Join中的关联条件和Where字句中的谓词信息，将查询或者写入路由到正确的分片。整个过程都是Gate自动完成的，对用户完全透明。

自助化服务

ContainerDB将对数据库服务的实例化、DDL/DML执行、分片升级和扩容等功能抽象成为独立的接口，并借助于流程引擎提供了流程化的完全自助的用户接入服务，用户申请数据库服务成功后，ContainerDB会将数据库访问口令自动推送到用户邮箱。

3、展望

过去已去，未来已来。

我们后续会更多的从用户的角度去思考数据库能够产生的价值。我们相信京东以后的数据库服务会：

• More Smart：我们会基于各个数据库实例中CPU/内存/硬盘等各种不同资源的监控数据进行深度学习和聚类分析，分析出各个不同数据库实例的倾向资源，并智能化调高每个数据库实例倾向资源的限制并调低非倾向资源的限制。 
• More Quick：我们会实时分析宿主机和容器的对应关系、各个容器的限制参数以及各个容器的历史资源增长速率，预先对容器所在宿主机碎片进行整理，从而尽量保证各个容器以垂直升级的方式实现扩容，从而极大地加快扩容速度。 
• More Cheap：我们会提供完全自主研发的存储引擎，计划实现查询引擎与存储引擎的集成，并提供多模型数据库引擎，从而实现多种数据模型的统一，极大节省数据库服务所需资源以及研发成本。 
• More Friendly：无论是ContainerDB还是我们自主研发的多模型数据库，我们都会完全兼容MySQL协议及语法，从而使得现有应用的迁移成本趋近于0。 
• More Open：ContainerDB会在经过京东内部的各种场景的磨练之后会拥抱开源，并希望与业界各位同仁一起将ContainerDB不断完善。同时我们后续的多模型数据库最终也会贡献给开源社区，并期待其服务于业界。 

【编辑推荐】

1. 从分库分表后遗症，总结数据库表拆分策略
2. 阿里数据库备份专家：教你pick最有效的备份系统
3. 巧妙设计多级缓存，为数据库减负
4. 区块链和数据库，技术到底有何区别？
5. 关于MySQL数据库的备份方案

【责任编辑：庞桂玉 TEL：（010）68476606】
点赞 0