运维自动化源于工作中的痛点。京东数据库团队在商城里面对的是上千名研发工程师。它是一夜之间完成的，也经历了从手动到脚本、自动化、平台化和智能化的艰难转变。所以说是需求在驱动运维体系的建设，而运维自动化的本质是解放运维人员，促进人力率的提高。要减少人为的失败，要学会养成“偷懒”的好习惯。京东自动化运维体系建设始于2012年，以下从两个方面进行介绍：1、京东数据库智能运维平台。京东的业务每年都在爆发式增长。数据库服务器数量众多，产品线数以千计。支撑如此庞大的业务系统，需要一个完整的自动化运维管理平台。目前，京东MySQL数据库管理平台简称DBS，主要涵盖以下内容：完善的资产管理系统、数据库进程管理系统、数据库监控系统、数据库故障管理系统、数据库报表系统、弹性数据库系统和数据库辅助运维工具，涉及到DBA运维的各个环节，DBA实现了MySQL的自动化、自助化、可视化、智能化和服务化管理，避免了DBA人工操作失误导致的生产事故，保障了MySQL的安全、稳定京东数据库的高效运行。这里重点介绍以下几个核心功能组件：1.元数据管理是自动化运维的基石，其准确性直接关系到整个数据库管理平台的可靠性。京东数据库管理平台从数据库业务端和DBA的运维习惯出发，涵盖机房、主机、业务、集群、实例、库、表等多个维度：机房和主机维度：主要记录硬件信息。业务维度：主要记录业务的名称、等级、业务部门相关信息。集群维度：主要记录MySQL集群架构信息。实例维度：主要记录MySQL的相关参数，为后续的自动化运维提供保障。数据库维度：主要记录数据库名称和业务人员的联系方式。2、自动化部署面对新增数据库、扩容等复杂的运维任务，使用自动化安装部署平台可以彻底解放DBA。目前，京东自动化部署系统包括申请服务器、部署数据库实例、同步数据、一致性校验、拆分切换等操作。整个流程流水线化，包括各个层级的业务和DBA操作审批，最终实现全面的MySQL服务。自动化流程化部署，如下图所示：主要功能包括：MySQL实例安装部署、架构搭建、域名申请。分配规则要求同一集群的主从实例不能在同一个机柜中，硬件性能较好的主机优先作为主库。监控部署、备份部署、资产登记。MySQL服务以镜像的形式创建，镜像依赖于K8S镜像仓库。申请账户由申请方通过自动在线系统申请创建。主从数据一致性检查通常在夜间业务低峰时段定期进行。3、智能分析诊断京东的智能分析诊断涵盖4个重要部分，数据库监控指标采集、诊断分析、故障自愈、趋势分析：（1）监控系统监控系统为数据库管理提供准确的数据基础，从而使运维人员对生产服务系统的运行状态一目了然。核心监控指标包括：OS负载、MySQL核心指标、数据库日志等。通过分析获取到的监控信息，判断被监控数据库的运行状态，预测可能出现的问题，并提供优化方案，保证数据库的稳定性和效率。整个系统。京东的分布式监控系统采用被动模式，server和proxy都具备高可用，杜绝单点故障。总体结构和流程图如下：(2)监控性能分析数据库性能智能分析主要是对数据库监控数据进行二次分析，消除安全隐患。在实际生产中，一些隐患还没有达到设定的报警阈值，处于报警的临界点。其实这种情况是最危险的，随时都有可能爆发。为了解决这些隐患，我们通过环比、同比、TOP指标等多方面进行分组汇总，提前发现隐患。慢SQL分析：索引分析：空间分析与预测：锁分析：(3)故障自愈故障以多种形式出现，核心内容依赖于监控的辅助分析。如何提供最准确的信息，内容如下：告警过滤：过滤掉告警中不重要的告警和重复告警生成派生告警：根据关联关系生成各种派生告警告警告警关联：不同告警之间是否存在关联同一时间窗口内的派生告警类型权重计算：根据预设的各种告警的权重，计算成为根告警的可能性生成根告警：将权重最大的派生告警标记为根告警根的合并alarms：如果多种告警计算出的根告警相同，则合并4.智能切换系统中京东数据库服务器的量级比较大，导致故障的概率比较大，在同时，对系统稳定性的要求也比较严格。因此，为保证数据库的高可用性和7*24小时不间断服务，我们团队自主研发了数据库自动切换平台，实现了自动和半自动切换方式，实现了单集群级、多集群级、和机房关卡等多维场景切换。切换过程包括修改监控、修改资产信息、修改备份策略、修改主从角色等，一键完成，避免人为因素造成的二次故障。(1)分布式检测是交换系统的核心组成部分，分布式检测功能主要解决系统容灾问题。根据京东数据库服务器多数据中心部署的特点，每个独立的数据中心部署一个检测节点，通过专门标识的接口域名来区分。当发生倒换操作时，倒换系统会根据传入的故障主机IP等信息，随机选择两个机房接口执行调用。如果检测到宕机，则认为主机宕机。(2)Master故障转移如果Master数据库实例发生故障，切换系统会首先通过分布式检测系统检查实例的存活状态。确认宕机后，会根据基础信息中的实例切换标识，选择使用自动切换还是手动切换。方法原理是一样的：先在交换系统上创建一个交换任务。手动切换需要DBA执行切换按钮。切换操作会通过insert方法插入数据来验证实例的运行状态，避免实例被阻塞和硬盘只读的情况。如果没有存活的从库，则放弃操作，并通过邮件或短信通知DBA。新主库的选择按照本地优先（先连接数少，QPS负载低），再远程的原则??。切换执行成功后，对应的元数据信息会发生变化。示例如下：一个四主四从的集群，主库10.66.66.66:3366故障，需要切换，如下：监控系统检测到主库宕机，会自动创建切换task，进行自动切换或手动切换，以手动切换为例：选择目标实例，如果例子中有4个slave都存活，则根据先本地再远程，然后查看连接数。如果连接数相同，比较QPS，选择QPS负载低的10.66.66.69:3366作为目标实例：切换完成结果：(3)从数据库实例切换Slave失败，更改下域名故障实例到集群下的非故障实例，选择目标实例方式和主库实例选择规则一致。切换成功或失败都会发送邮件和短信通知相应的DBA。故障实例恢复后，DBA判断是否切回。示例如下：一主四从的集群，从库10.88.88.89:3366发生故障，需要切换，如下：监控系统会自动创建任务，然后查看连接数和QPS按照先本地后远程10.88.88.88:3366的原则确定目标实例，进行自动切换，DBA可以在切换任务列表中查看详情。任务切换成功会显示回切按钮，DBA可以执行回切并查看回切的具体信息。(4)主从计划切换主从计划切换实现了单集群和多集群的批量切换。在进行批量切换时，可以查看子任务切换的具体步骤。切换后会有前后架构对比。具体示例如下：Cluster1批量创建任务。选择原则是先本地后远程，先连接数再QPS，10.66.66.66:3366选择目标主库为：10.88.88.89:3366。批量执行切换：切换子任务详情，可以查看每个子任务的切换结果、执行步骤和前后结构：京东MySQL数据库切换系统将所有功能模块组件化，服务简化了DBA的操作流程和缩短数据库切换时间。五、数据库自动备份与恢复（一）架构设计京东数据库备份系统最初的设计初衷是将DBA从繁杂的备份管理工作中解放出来，实现自动化处理，减少人为干预，提高备份文件的可用性。关于备份文件的可用性，轮询恢复策略确保每个集群在一个周期内恢复。系统架构设计如下图所示：该架构具有以下特点：调度触发器多样调度中心支持interval、crontab、date三种触发方式：interval是周期性调度，可以指定任务按固定的时间间隔调度，并支持时间单位包括周、日、时、分、秒，支持设置调度开始时间、结束时间、时区设置。crontab是一个定时计划，与Linuxcrontab基本相同。支持年、月、日、周、day_of_week、时、分、秒，支持设置日程的开始时间、结束时间和时区设置。date是一个支持时区设置的一次性计划时间表。并发控制由于调度任务的设置不均衡，可能某个时间需要调度的任务很多，很可能导致调度系统出现问题。因此，任务的执行可以通过控制并发数，让任务的调度和执行运行的更加顺畅。触发和执行层次化任务触发本身是一个轻量级的集合，而任务执行一般都是重度的，所以将触发和执行层次化设计，防止执行时间过长导致后续触发问题。任务不会在维护期间丢失。Linuxcrontab在开机后不会执行停机维护期间要运行的任务，而基于APScheduler的调度中心会在开机后运行指定时间间隔内未执行的任务，减少因维护而错过的任务。执行。在对备份策略进行增删改查之前，公司的备份系统需要指定一个特定的IP。由于服务器维护，备份经常失败。所以备份策略在设计之初就结合了高可用，备份策略指定的是域名而不是IP。当从库发生故障转移时，DBS会将这个从库上的域名切换到集群中的其他从库上，相应的备份也会跟随这个从库，保证备份服务器可用。失败自动重试备份可能因意外因素失败，故增加备份重试功能，6小时内对备份失败的任务进行备份重试，最多重试3次以获得更高的备份成功率速度。自动恢复检测备份每一步都要严格校验，但并不能绝对保证备份文件可用，所以引入自动恢复检测机制，帮助DBA检测备份文件，及时发现由各种未考虑的情况引起的。备份文件不可用，恢复检测也是审计的硬性要求。自动恢复检测还将DBA从繁重的恢复检测工作中解放出来。(2)调度设计整个自动化备份与恢复系统主要由调度系统、备份系统、恢复系统、恢复检测系统、自动修复系统组成。调度系统是整个系统的核心，调度系统用于协调其他系统的运行。调度系统可以部署Standby实现高可用，executor可以集群部署实现高可用和水平扩展。备份系统每次备份时都会检查实例的健康状态和备份操作状态，防止备份无效的数据库实例。在数据库实例中使用时，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、基于以上问题，简单的数据库服务容器化已经无法解决。我们需要让数据库服务更智能，让数据库资源能够被激活，提供资源分阶段交付的功能，于是ContainerDB应运而生。ContainerDB基于负载的弹性调度，为京东的数据库资源赋予了智慧，使其资源真正流动起来，成功服务了618、11.11等多个大促。ContainerDB每个业务应用都有一个逻辑库。逻辑库定义了整个业务中所有表的分片键（ShardingKey）哈希取模操作的范围（KeySpace）。在每个逻辑库中，可以创建多个表，但是每个表中都必须定义ShardingKey。通过ShardingKey将表中的数据拆分成多个分片（Shard），每个分片对应一个KeyRange，KeyRange表示对ShardingKey进行哈希处理后得到的一个值（ShardingIndex）。每个分片由一套MySQL主从架构支持，提供数据库服务。应用程序只与Gate集群交互，Gate根据元数据信息和SQL语句完成数据写入和查询的自动路由。ContainerDB中的监控中心会实时监控所有基础服务和资源使用情况，并通过注册在监控中心的Hook程序自动进行动态扩容、故障自愈、分片管理等，这一系列的操作会影响应用程序。它是完全无意识的。(1)以往数据库服务的流式资源持续交付造成资源浪费的主要原因之一是资源的初始分配过于细化，资源从业务端提前3年甚至5年预付费用开始。但是，资源池中的资源是有限的，不可能所有的业务都提前预付资源，导致部分业务没有资源。ContainerDB使用流的方式来持续交付资源。每个业务接入一开始只会分配一个标准的64G硬盘。随着业务的发展和数据量的不断增加，硬盘容量会不断增加，直到达到256G的上限。这样，我们就大大拉长了数据库资源的交付周期，然后我们可以在三五年的所有资源预算到位之前，为所有业务提供数据库服务，提高数据库的业务支撑能力。(2)基于负载的弹性调度数据库服务使用的资源分为瞬时资源和增量资源两类。瞬态资源是指在短时间内剧烈波动的资源使用情况。这些资源主要包括CPU和内存。增量资源是指资源的利用率不会在短时间内剧烈波动，而是缓慢增加，支持增量不减。这些资源主要包括硬盘。ContainerDB针对不同的资源采用不同的调度策略。对于瞬态资源，ContainerDB为每个数据库分配三个标准：下限：2C/4G，上限：4C/8G下限：4C/8G，上限：8C/16G下限：8C/16G，上限：16C/32G每个容器分配的初始资源是标准的下限。当数据库服务的CPU负载过高或内存不足时，会尝试申请超过下限的CPU或内存，但绝不会超过上限。负载恢复后，多应用将释放资源，直到恢复CPU和内存的下限。对于增量资源：磁盘，业务访问开始时，统一分配64G硬盘。每当当前磁盘使用率达到80%且未达到上限256G时，进行垂直升级；如果容器当前磁盘达到上限256G，则进行onlineResharding。垂直升级：首先会进行资源检查，看主机是否有足够的剩余硬盘资源进行垂直升级。如果检查通过，会对宿主机进行全局资源锁定，硬盘垂直扩容增加64G。如果检查失败，则会在宿主机上提供一个与当前容器相同的硬盘大小+64G，与当前容器相同的CPU和内存的新容器，并将数据库服务迁移到新的容器中。垂直升级瞬间完成，不会影响数据库服务。在线分片：申请两个新的分片。新分片中数据库Container的硬盘、CPU、内存标准与当前分片完全一致。根据当前分片中数据库的主从关系，为新分片主从关系中的所有数据库重建MySQL，然后启动Schema信息复制和过滤复制，最后更新路由规则并切换读写流量到新分片，并使旧分片资源下线。无论是垂直升级还是在线Resharding，都需要注意一个问题：在保证每个分片的Master都在主机房的前提下，尽量不要将所有资源都分配在一个主机/机架/机房。ContainerDB提供强大的亲和/反亲和资源分配能力。目前ContainerDB的亲和/反亲和策略是这样的：每个KeySpace有一个hostroom，属于同一个shard中的数据库实例（目前一个shard包含1master和2slave）。属于主机房。同一个机架不能有任意两个实例，同一个机房??不能有任意三个实例。该策略可以防止一个机柜断电导致master和slave同时失效，也可以避免IDC故障导致所有数据库实例不可用。因为是尽可能满足，当资源池中的资源分布不均时，有可能在资源分配时无法满足上述反亲和策略。因此，ContainerDB有一个常驻的后台进程，不断轮询集群中的所有分片，判断分片中的实例分布是否满足反亲和规则。如果没有，它将尝试重新分配实例。为了不影响再配发时的在线业务，将优先从库配发。基于弹性调度能力，ContainerDB实现了以下三个功能：在线扩容：当某个分片的数据库负载达到阈值时，自动触发该分片的在线垂直升级、迁移或重分片。在线自愈：当分片中的一个MySQL实例发生故障时，ContainerDB首先判断故障实例是否是master，如果是master则选择GTID最大的slave作为新的master，重建复制关系和完成奴隶；如果不是master，则直接由slave完成。在线访问：ContainerDB允许用户以完全自助的方式启动数据在线迁移和访问任务。该任务会将传统MySQL数据库中的数据在线迁移到ContainerDB中。数据迁移完成后，域名会自动切换完成。业务系统数据源在线无感知迁移。ContainerDB通过在线服务扩容、在线自愈、在线访问三大功能，实现了京东数据库服务的AlwaysOnline保障。（3）不局限于调度弹性和流式资源的传递和调度是ContainerDB的基石，但除了这两个核心功能，ContainerDB在用户易用性、兼容性、数据安全等方面也做了很多工作，包括：数据保护在传统的直连数据库方案下，当Master在网络中变得不可达时，一般会选择一个新的Slave成为Master，然后将原Master上的域名漂移到新的Master上。但是在网络抖动的情况下，由于AppServer上的DNS缓存，这种方案容易出现双主和脏写。从整体架构图可以看出，ContainerDB通过Gate连接到用户。Gate是一个集群服务。多个Gate服务映射到一个域名。Gate通过IP地址直接访问每一个MySQL服务，Gate对每一个MySQL角色的识别完全依赖于元数据服务：Topology。当ContainerDB中的一个MySQLmaster在网络上不可达时，会选择一个新的master，并在master切换前更新路由元数据信息。数据是脏写的，所以数据被严格保护。流式查询处理ContainerDB通过在门层实现基于优先级的归并排序，提供快速的流式查询功能。在进行大规模数据查询时，可以即时返回部分查询结果数据，大大提升客户体验。无感知数据迁移ContainerDB通过在Window函数中分别进行部分存量数据复制和增量数据追加算法，开发了在线数据迁移和访问工具JTransfer。通过JTransfer，可以将传统MySQL数据库中的动态数据迁移到ContainerDB中，当ContainerDB中的数据与源MySQL中的数据滞后小于5秒时，源MySQL会先停止写入，当滞后变为0，源MySQL的域名会漂移到Gate集群。在整个迁移过程中，用户对AppServer没有任何感知。兼容MySQL协议ContainerDB完全兼容MySQL协议，支持标准MySQL客户端和官方驱动接入，支持大部分ANSISQL语法。路由规则是透明的。ContainerDB通过一个Gate集群连接到用户。Gate根据用户发送的查询语句形成的语法树和查询执行计划，获取查询涉及的所有表，并根据拓扑中的元数据信息获取每个表的信息。分片信息，最后结合Join中语句中的关联条件和Where子句中的谓词信息来路由查询或写入正确的分片。整个过程由Gate自动完成，对用户完全透明。自助式服务ContainerDB将数据库服务实例化、DDL/DML执行、分片升级、扩容等功能抽象为独立的接口，借助流程引擎提供流程化、完全自助式的用户接入服务。数据库服务成功后，ContainerDB会自动推送数据库访问密码到用户邮箱。3、展望未来，过去已去，未来已来。未来，我们会更多地站在用户的角度去思考数据库能够产生的价值。我们相信京东未来的数据库服务会：更智能：我们会根据每个数据库实例中CPU/内存/硬盘等各种资源的监控数据，进行深度学习和聚类分析，分析趋势资源对每个不同的数据库实例，智能调整每个数据库实例的偏好资源限制和减少非偏好资源限制。更快捷：我们会实时分析宿主机和容器的对应关系，每个容器的限制参数，每个容器的历史资源增长率，预先整理容器所在的宿主机，从而确保每个容器都可以垂直升级。扩容，从而大大加快了扩容速度。更便宜：我们将提供完全自研的存储引擎，计划实现查询引擎和存储引擎的融合，提供多模型的数据库引擎，实现多种数据模型的统一，大大节省数据库服务所需的资源和研发成本。更友好：无论是ContainerDB，还是我们自研的多模数据库，我们都将全面兼容MySQL协议和语法，让现有应用的迁移成本接近于零。更开放：ContainerDB在京东内部各种场景的磨练后将拥抱开源，希望与业界同仁一起不断完善ContainerDB。同时，我们后续的多模型数据库最终会贡献给开源社区，我们期待它服务于行业。
