加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

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

发布时间:2018-08-27 16:19:59 所属栏目:编程 来源:京东商城技术架构
导读:运维自动化来源于工作中的痛点,京东数据库团队面对的是商城成千上万的研发工程师,这种压力推动我们不断变革,然而变革不是一蹴而就,也经历过从手工到脚本化、自动化、平台化、智能化的艰难转变,所以说是需求在驱动运维体系的建设,而运维自动化的真谛

备份在每一步都要严格地验证,但是也无法绝对保证备份文件可用,因此引入了自动恢复检测机制,来帮助DBA对备份文件进行检测,及时发现因为各种未考虑到的情况导致备份文件不可用的情况,并且恢复检测也是审计的一个硬性要求,自动恢复检测也将DBA从繁重的恢复检测工作中彻底解脱了出来。

(2)调度设计

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

整个自动化备份恢复系统主要由调度系统、备份系统、恢复系统、恢复检测系统、自动修复系统组成。其中调度系统是整个系统核心,通过调度系统来协调其他系统运行。调度系统可以部署Standby来实现高可用,执行器以集群部署来实现高可用和横向扩容。

备份系统每次备份时都会进行实例健康状态检查、备份运行状态检查等,防止对无效的数据库实例进行备份;恢复系统主要是在需要进行数据恢复、弹性扩容等等需要从备份文件恢复成运行的数据库实例时使用,能够让DBA通过简单地操作即可完成数据的恢复;恢复检测在调度系统的指挥下自动对备份文件可用性进行检测,来帮助DBA及时发现不可用的备份文件;备份失败有些是能够通过失败自动重试来解决,但有一部分是重试所不能解决的,需要进行相应修复,因此开发了自动修复系统来自动修复因为环境等问题引起的备份失败。

调度系统是最核心的一个系统,是整个备份恢复系统的大脑,当时考察了几种实现方式,例如Linux的crontab、Azkaban和python的开源框架Apscheduler,最终认为Apscheduler更加灵活小巧,调度方式也更加多样化,使用Python开发后期维护成本更低,因此采用Apscheduler开发了调度中心。

(3)系统前端 

主要分为备份策略管理、备份详情、备份黑名单管理、恢复详情四个模块:

备份策略管理:

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

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

备份详情:

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

备份详情里面展示了最近备份总数、成功数、成功率、当天备份任务运行状态、备份任务24小时分布曲线图以及备份详细记录。备份详细的记录可以根据集群名、项目名等信息进行查询,方便DBA更好地掌握备份运行状况。

恢复检测详情:

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

恢复检测页面包含最近每天恢复检测数、恢复检测成功数、成功率柱状图、当天恢复检测任务运行状态饼图和近期恢复检测完成率,有助于DBA对恢复概况有更清晰的了解。

二、数据库变革 

1、过去

在ContainerDB之前,京东的数据库服务实现了容器化,虽然数据库服务已经完全通过Docker容器实现了数据库服务的快速交付和自动故障切换等基本功能,在一定程度上提高了数据库服务的稳定性和效率,但是数据库服务的运维和使用方式与传统方式基本无异,比较典型的问题如下:

(1)资源分配粒度过大

数据库服务器资源标准固定,粒度过大,为数据库服务可提供的资源标准过少。

(2)资源浪费严重

资源分配的标准有DBA根据经验决定,存在很大的主观性,不能根据业务的实际情况进行准确评估,而DBA在分配资源的时候一般都会考虑在3年以内不需要对服务进行迁移或者扩容,而一次分配比较多的资源,存在严重资源浪费。而且由于数据库资源标准固定,标准过大,导致宿主机中的碎片过大,经常出现一台宿主机只能创建一个容器,而剩下的资源满足不了任何资源标准,导致宿主机上资源使用率过低。

(3)资源静态无调度 

数据库服务一旦提供,所占据的资源就会固定,不能根据数据库的负载进行在线动态的调度,而一旦数据库的硬盘使用率过高,需要DBA人工介入进行扩容处理,效率低下。

2、现在

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读