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

递增资源是指资源的使用率不会再短时间之内出现严重的波动，而是会缓慢增加，并且支持递增，不会出现减少的情况，这种资源主要包括硬盘。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故障从而导致所有数据库实例均不可用。

由于是尽量满足，所以当资源池中的资源分布不均时，就有可能在资源分配的时候满足不了上述的反亲和性策略。因此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还在用户易用性、兼容性和数据安全性等方面做了很多工作，包括：

数据保护

（编辑：晋中站长网）

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