京东数据库运维自动化体系建设之路

太阳不下山

　　运维自动化来源于工作中的痛点，京东数据库团队面对的是商城成千上万的研发工程师，这种压力推动我们不断变革，然而变革不是一蹴而就，也经历过从手工到脚本化、自动化、平台化、智能化的艰难转变，所以说是需求在驱动运维体系的建设，而运维自动化的真谛在于解放运维人员，促进人率提升，减少人为故障，要学会培养自己“懒”这个好习惯。京东的自动化运维体系建设始于2012年，下面从两个方面进行介绍。
1.    京东数据库智能运维平台　　京东业务每年都在以爆发的形式在增长，数据库服务器的数量众多，产品线也多达上千条，要支持如此庞大的业务体系，需要一套完善的运维自动化管理平台。目前京东MySQL数据库管理平台简称DBS，主要涵盖以下内容：完善的资产管理系统、数据库流程管理系统、数据库监控系统、数据库故障管理系统、数据库报表系统、弹性数据库系统以及数据库辅助运维工具，涉及DBA运维的方方面面，实现了DBA对MySQL的自动化、自助化、可视化、智能化、服务化管理，避免DBA因手工操作失误带来的生产事故，保障京东数据库的安全、稳定、高效运行。这里着重介绍以下部分核心功能组件。


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


1.3.1    监控系统　　监控系统为数据库管理提供了精准的数据依据，能够让运维人员对生产服务系统运行情况了如指掌，核心的监控指标包含：OS负载，MySQL核心指标，数据库日志等。通过分析获得的监控信息，判断被监控数据库的运行状态，对可能出现的问题进行预测，并给出优化方案，保证整个系统稳定、高效。
　　京东的分布式监控系统采用被动模式，server端和proxy端均做高可用，防止单点故障。以下是整体架构和流程图：

　　

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


　　    空间分析及预测


1.3.3    故障自愈

　　1.监控系统检测到主库宕机，则自动创建切换任务，进行自动切换或者手动切换，以手动切换为例：


　　3.切换完成结果


　　监控系统会自动创建任务，并根据先本地后异地原则，然后再查连接数，QPS，确定目标实例为10.88.88.88:3366，进行自动切换，DBA可在切换任务列表查看详情。


1.4.4    主从计划性切换　　主从计划性切换实现了按单集群，多集群的批量切换。执行批量切换时可以查看子任务切换的具体步骤，切换后会有前后架构的对比，具体示例如下：
　　集群1

　　

　　切换子任务详细信息，可查看到每个子任务的切换结果，执行步骤及前后架构。
　　

    调度触发多样化：　　调度中心支持三种类型的触发方式interval、crontab和date。
　　interval是周期调度，可以指定固定间隔时长的任务调度，支持时间单位有weeks、days、hours、minutes、seconds，并支持设定调度开始时间和结束时间以及时区设置。
　　crontab是定时调度，与Linux的crontab基本相同，支持year、month、day、week、day_of_week、hour、minute、second，并且支持设置调度开始时间和结束时间以及时区设置。
　　date是一次性定时调度，支持时区设置。
　　2)    并发控制：
　　由于调度任务设置具有不均衡性，可能某一时刻需要调度的任务较多，容易引起调度系统出现问题，因此执行任务通过控制并发数来使任务调度执行运行更加平稳。
　　3)    触发和执行分层：
　　任务触发本身是轻量级集的，而任务执行一般都比较重，因此对触发和执行进行了分层设计，来防止因为执行时间过长导致后续触发出现问题。
　　4)    维护期间任务不丢失：
　　Linux的crontab在停机维护期间要运行的任务开机后并不会再次执行，而基于APScheduler的调度中心则会在启动后运行指定间隔内尚未执行的任务，减少因维护而错失任务的执行。
　　5)    备份策略增删改查：
　　之前公司的备份系统是需要指定特定的IP，经常因为服务器维护而导致备份失败，故在设计之初就将备份策略与高可用结合在一起，备份策略指定域名而不是IP。从库因为故障切换时DBS会将此从库上的域名切换到集群内的其他从库，相应的备份也跟随到了此从库，保证了备份服务器是可用的。
　　6)    失败自动重试：
　　备份很可能因为偶然因素而失败，因此加入了备份重试的功能，会对6小时以内的备份失败任务进行备份重试，最多重试3次，来获得更高的备份成功率。
　　7)    自动恢复检测：
　　备份在每一步都要严格地验证，但是也无法绝对保证备份文件可用，因此引入了自动恢复检测机制，来帮助DBA对备份文件进行检测，及时发现因为各种未考虑到的情况导致备份文件不可用的情况，并且恢复检测也是审计的一个硬性要求，自动恢复检测也将DBA从繁重的恢复检测工作中彻底解脱了出来。
1.5.2    调度设计

　　备份策略管理的页面包含了备份状态分布情况、存储使用情况以及每个集群的当前备份策略状态，如果已经添加了备份策略则可以在这里进行（时间、服务器、备份方式）修改、暂停（继续）、删除操作，如果没有添加备份策略，则可以进行添加。
　　备份详情：


　　恢复检测页面包含最近每天恢复检测数，恢复检测成功数，成功率柱状图，当天恢复检测任务运行状态饼图和近期恢复检测完成率，有助于DBA对恢复概况有更清晰的了解。
2.    数据库变革2.1.    过去　　在ContainerDB之前，京东的数据库服务实现了容器化，虽然数据库服务已经完全通过Docker容器实现了数据库服务的快速交付和自动故障切换等基本功能，在一定程度上提高了数据库服务的稳定性和效率，但是数据库服务的运维和使用方式与传统方式基本无异，比较典型的问题如下：
2.1.1    资源分配粒度过大　　数据库服务器资源标准固定，粒度过大，为数据库服务可提供的资源标准过少。
2.1.2    资源浪费严重　　资源分配的标准有DBA根据经验决定，存在很大的主观性，不能根据业务的实际情况进行准确评估，而DBA在分配资源的时候一般都会考虑在3年以内不需要对服务进行迁移或者扩容，而一次分配比较多的资源，存在严重资源浪费。而且由于数据库资源标准固定，标准过大，导致宿主机中的碎片过大，经常出现一台宿主机只能创建一个容器，而剩下的资源满足不了任何资源标准，导致宿主机上资源使用率过低。
2.1.3    资源静态、无调度　　数据库服务一旦提供，所占据的资源就会固定，不能根据数据库的负载进行在线动态的调度，而一旦数据库的硬盘使用率过高，需要DBA人工介入进行扩容处理，效率低下。
2.2.    现在　　基于以上的问题，单纯的数据库服务容器化已经无法解决，我们需要让数据库服务更聪明，让数据库的资源能够动起来，提供资源分期交付的功能，于是ContainerDB应运而生。ContainerDB基于负载的弹性调度为京东的数据库资源赋予了智慧，令其资源真正地流动起来，并已成功服务于多次618和11.11大促。


　　数据库以前的服务存在资源浪费的一个主要原因就是资源初始分配粒度太大，一开始就为业务提前预支3年甚至5年的资源。而资源池中的资源是有限的，不可能让所有业务都提前预支资源，从而导致有些业务没有资源。ContainerDB采用流式的方式进行资源的持续交付。每个业务接入初始都只会分配标准的64G硬盘，随着业务的发展和数据量的持续增加，会持续增加硬盘容量直到到达硬盘限制的上限256G。


　　针对递增资源：磁盘，在业务接入之初，统一分配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的亲和/反亲和性策略如下：



　　ContainerDB通过在Gate层实现基于优先级的归并排序提供了快速流式查询的功能，在进行大批量数据查询时，能瞬时返回部分查询结果数据，极大提高客户体验。
无感知数据迁移　　ContainerDB通过在交叉在Window函数中分别执行部分存量数据拷贝和增量数据追加的算法，开发了在线数据迁移和接入工具JTransfer，通过JTransfer可以将传统MySQL数据库中的动态数据迁移到ContainerDB中，当ContainerDB中的数据与源MySQL中的数据的lag小于5秒时，首先会将源MySQL停写，待lag变为0时将源MySQL的域名漂移到Gate集群，整个迁移过程用户AppServer无感知。
兼容MySQL协议　　ContainerDB完全兼容MySQL协议，支持标准MySQL客户端和官方驱动程序接入，并且支持大部分ANSI SQL语法。
路由规则透明　　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不断完善。同时我们后续的多模型数据库最终也会贡献给开源社区，并期待其服务于业界。