作者：陈予诚（京东科技资深 DBA）

背景简介

京东 StarDB 是基于 Share Nothing 架构构建的分布式数据库，核心模块包含计算引擎、存储引擎和管控引擎，提供多节点分布式和单节点集中式两种高可用拓扑解决方案，满足不同数据容量的应用需求。它将数据库核心能力进行技术整合，拥有高性能、高可用、高扩展、高安全、易维护等优异特性，打造了能够提供平稳高效的 DB 服务以及合理运维管控能力一体化的国产分布式数据库生态体系。

StarDB 是一个一体化的数据库，具有一站式的数据库生态管控。不同角色的用户在 StarDB 中也拥有着不同的视角。本文将会着重讲数据库层面上 StarDB 的设计理念与经验。数据库层实际上又分为两个部分，一部分是偏运维管控的，如 DBA 视角进行一些资源管控、资源交付、高可用切换等操作的运管平台；另一部分是偏 SaaS 层的性能分析平台，这部分实际上研发和 DBA 的视角是类似的，都可以通过平台进行性能诊断和性能优化等。

StarDB 智能运维管理平台

整体设计思路

针对运维管理平台来说，标准化和模版化是管理大规模数据库集群的不二法门，可以显著的提高数据库运维的效率与可靠性。一方面将通用的操作流程标准化、自动化；另一方面将个性化的配置与流程做成模版与插件脚本。根据这一基本指导思想，StarDB 逐步在数据库管理上既实现了高效自动化的基础需求，又保障了灵活性个性化，最终达到精细化管理的目标。

数据库交付

数据库交付是数据库精细化管理的重要一环，一方面需要保障交付的数据库符合规范、服务器配置与数据库配置达到上线标准，另一方面又需要根据不同的业务场景与数据库主从拓扑方式定制特化的交付方式。其中数据库规格设定以及 DB 应用部署这两部分是可以做成定制化的。

针对数据库规格设定这部分，以 MySQL 为例，ibp size 大小，innodb_thread_concurrency 大小，连接数的多少以及内存分配器的指定（如使用默认的 ptmalloc 亦或是使用 jemalloc）等都可以进行定制化、个性化配置。同时根据不同的业务类型，不同的资源类型设置不同的定制化模板以适配不同的场景，如高并发秒杀型、rt 敏感型等等。

针对 DB 部署部分，StarDB 将部署代码和平台剥离，当有新类型数据库接入的时候，只需要新增部署脚本类型并适配即可。这样做一是提高了可扩展性，二是上线的时候影响小，只需要变更脚本即可，不需要整体平台打包上线。同时平台约定好部署所需要的输入参数（如端口、路径等），脚本部署完成后会将对应的状态和结果进行返回，平台根据结果进行下一步的流程调度。定制好这些规范后，平台即可快速支持多种类型数据库的交付工作。

数据库备份

备份也是数据库管理必不可少的组成部分，无论何种场景下备份要实现的目标其实很简单，京东对备份有以下三个需求：1.覆盖完整，但不要有冗余；2.备份成功率高；3.备份确保可以被找到。StarDB 的备份目前采取了全备使用 xtrabackup，同时每天去备份增量的 binlog，并没有采取过多的 mysqldump 等备份工具。

从上图可以看出在每个 DB 的节点上都部署了 backup-agent，由平台定时发起备份任务并将备份上传到 Hadoop 存储上。备份管控平台可以设定备份保留策略，将过期备份归档到磁带库集群上，减少集群的存储压力。同时依赖于 cmdb 的元数据的准确采集，系统可以准确找到整个数据库拓扑中的从库节点，并对其配置备份配置。如果进行切换或者替换等元数据变更，系统也会自动去变更适配现有的集群 topo。这样就做到了动态调整，避免了备份的时候对主库产生影响。这样就保证了第一个需求，也就是覆盖面是完整的同时又不会出现冗余的情况。

针对数据库日常的迁移、拆分、替换机器等操作，在追溯历史备份链路的时候，经常会出现无法准确寻找到想要的备份的情况，StarDB 针对这种情况为每一个数据库集群都设定了一个 uuid，在迁移和拆分的时候可以指定和原集群同步，这样就很轻易的能追溯到历史的备份文件。同时 StarDB 对备份文件进行了加密处理，这样就算出现备份文件意外泄露，对方也无法获取数据。同时 StarDB 会对备份进行有效性检测，会有后台进程去对历史备份进行恢复检测，并出示备份有效性的报告，确保备份是真实有效可恢复的。

数据库容灾

整体容灾体系不只要从深度解决数据库问题，还需要多系统之间的协同合作才能解决之前的系统性问题。首先完善的自动化体系是解决企业级大规模运维的需求。StarDB 会根据当前的拓扑结构自动调整高可用的配置，自动适配上下线等配置变更。同时提供对切换过程的进度状态跟踪，历史记录查询等，对切换的结果进行主动推送，DBA 无需登录平台即可了解切换结果。同时 StarDB 的高可用模块提供了良好的兼容性和适配性，无论接入方式是 slb 还是 proxy，亦或是部署方式为跨 IDC 还是跨网段都可以进行容灾管理。深度优化容灾服务能力、提升数据一致性保障能力是说 StarDB 在尽可能的降低切换时间前提下，保障数据的完整性。在原生的 MySQL 下，大多是利用半同步，或者 mgr 的分布式协议功能来保障主从数据一致性，但是数据需要跨机房跨地域的容灾能力，在这种区域划分的场景下，是无法保障数据一致性的能力，也就是说故障情况下，很可能会丢数据，而且对性能的损耗非常大。StarDB 对内核层进行了适配变更，改变了数据提交时的一致性校验逻辑，然后在主从复制的过程中增加了区域与分组标识，在对外部用户无感知的情况下可以实现跨区域一致性的方案。同时 StarDB 完全重构了开源的 MHA 代码，针对一些关键步骤进行了逻辑优化。比如在故障容灾场景下，为了保证数据一致性备库需要完整恢复与主库的差异数据，这个过程根据数据量的大小不同有可能会占用很长的时间，通过分析耗时与权衡，在此步骤中 StarDB 根据当前的资源与数据量，动态调整系统和数据库的 IO 同步策略的调整，以达到最优的切换效率，减少切换所需要的时间。

性能分析平台

性能分析平台的发展背景

针对性能分析平台来说，京东的诉求有两方面。第一从 DBA 侧，业务发展速度远远超过了 DBA 团队发展的速度，单独依靠 DBA 重人工支持模式变得越来越困难，因此 StarDB 在几年前开始尝试通过产品来完成 DBA 人工做的一些工作，来覆盖一些长尾数据库项目。通过产品解决 DBA 人工服务的扩展性问题，是京东最直接的诉求，希望能把 DBA 人工服务产品化；如何可靠地去发现数据库异常，甚至是提前预测到故障的发生并进行及时干预，是有很强的业务需求的。从用户侧，京东期望用户能够自助发现和解决数据库的性能问题，并非发现问题先去找 DBA，这样整个流程会比较长，时间成本也比较高。但做到自助化，首先用户能够全面了解数据库的运行情况。也就是对用户来说，数据库应该是一个白盒而不是黑盒。也就是说要有一个系统使得 DB 信息对用户是透明的。

上面讲述了京东要做性能分析平台的诉求，这个平台不单单是给 DBA 开发的工具，同时也是面对所有使用数据库的开发同学，来提供这种自助化的诊断优化服务。所以 StarDB 对监控数据进行了加工，分析以便使得没有很深数据库背景的同学也可以轻易上手这个平台。该平台整体架构如下，分为 4 个层级：

1.数据采集层：数据来自于数据库进行实时的秒级数据采集，包括性能指标、日志数据、SQL 流水、DB 内部的一些信息等等。

2.计算层：分为实时计算和离线计算，如评分、SQL 指标、监控数据等；另一部分是离线计算，如智能基线计算、统计报表等。

3.诊断服务层：如 SQL 优化、索引建议、会话分析、锁诊断、空间诊断等

4.Web 服务层：将计算结果与优化建议等通过服务展示给研发和 DBA 同学

StarDB 将数据库的核心监控指标（例如活跃连接数、CPU、内存、磁盘等）纳入到评分模型中，同时也将结合数据库的历史异常率，慢日志、死锁、审计日志等深层次分析找出潜在问题，综合给数据库的健康状况进行打分。此外传统的监控很难提供一个关注所有数据库实时状态的全局视野，针对这个痛点，StarDB 为用户提供了“集群监控”、“集群概览”，实现以集群数据库实例维度（用户整体视角）的监控指标展示。便于用户查看和发现数据库异常问题，提高运维效率。

审计系统

StarDB 除了对慢查询有采集分析外，还对全量 SQL 进行了采集分析。因为单纯的慢 SQL 可能无法准确定位数据库性能问题。有些业务对 latency 很敏感，尽管 SQL 没有达到慢 SQL 标准，比如 MySQL 里默认的 1 秒，但业务已经感觉到明显的异常，因此需要对数据库实例上的全部 SQL 进行分析，了解当前实例正在执行哪些 SQL，性能如何。这些信息能够更全面了解业务 SQL 的健康情况，比如对执行耗时占比较高但执行效率较低，执行性能有明显波动以及新增 SQL 等进行了识别。

审计系统也分成了多个模块，首先是采集端，为了不影响数据库服务的运行，使用了旁路监听的形式对网卡数据进行监听、过滤、解析，推入消息队列 Kafka 中。数据处理模块将解析后数据根据 session 信息进行补充、匹配、聚类，数据会入库 ClickHouse，用于前端展示。Webserver 端，用户可以发起配置修改（敏感字段配置或正则规则）请求，Web 服务鉴定用户权限后，将配置修改事件写入消息队列 Kafka，实时计算引擎 Flink 读取事件并广播到所有节点，实现配置的实时修改。数据处理模块实现了 SQL 的风险判定功能，包括语法层面的风险，如无 where 条件的 update 语句，也包括对敏感数据（库表字段）的访问等等，这些规则的启用禁用都可以在前端动态配置。

巡检系统

数据库巡检体系作为数据库运维保障体系最重要的环节之一，目的是能及时发现系统中存在的隐患。为什么除了监控体系之外还需要巡检？是因为要时刻保持数据库在一个健康的状态下运行，监控是执行手段，但是巡检是监控监控的手段，类似于一个监察机关。

系统设计之初就考虑到了巡检分为两大类，一类是针对数据库的可用性巡检，一类是可运维性巡检。同时巡检项不仅仅针对数据库本身，同时涵盖了高可用系统，备份系统、监控系统等数据库生态周边系统，尽可能覆盖所有会引发数据库故障的风险点，这也是运维经验的一个逐步累积的过程。同时系统将隐患级别进行分级，严重级别需要立即处理，警告级别则是未来会出现隐患并以提前告知。针对研发会定期发送巡检报告推动研发去进行相关治理，针对 DBA 也会定期发邮件去提示 DBA 本次巡检出现哪些隐患。目前 StarDB 支持定期巡检，也支持用户自定义配置巡检周期。

总结

StarDB 一体化的智能运维管控平台除了包含上述提到的运维管控、性能管控，还包含资产管理、数据治理、安全管控，同时该平台拥有灵活的生态对接能力，集数据库运维管理经验、AI 智能运维算法和企业级数字化能力于一身，通过服务接入、功能集成、用户赋能和流程管控，实现了多种数据库和中间件全生命周期的运维管理，可提供一站式、自动化、智能化的运维管控服务。