本文为云原生应用创新实践联盟——容器云自动化运维课题组生产内容，相关专家如下所示，更多内容可 点击此处进入云原生应用创新实践联盟 进行查看。
① 已通过课题组专家审核
② 待课题用户组织评议（欢迎各位在下方评论区提出您的宝贵意见）

执笔专家：
朱琦 课题组特邀外部专家
twt社区云原生应用创新实践联盟——容器云自动化运维方向课题组特邀外部专家。曾在陆金所、诺亚财富、万达金融等知名互联网公司担任运维工作，后又在麦当劳和阿迪达斯担任DevOps和SRE的工作，对数据和数据库，涉猎领域广泛，特别对运维和数据和数据库运维有自己独特的理解和认识。

顾问专家：
彭尚峰 课题组特邀外部专家
twt社区云原生应用创新实践联盟——容器云自动化运维方向课题组特邀外部专家。深耕云计算领域多年，深度参与银行PaaS私有云建设与推广，拥有丰富的容器云平台设计和落地经验。
顾黄亮 容器云自动化运维用户委员会委员
twt社区云原生应用创新实践联盟——容器云自动化运维方向课题组组长。 畅销书《DevOps权威指南》和《技术赋能 数字化转型的基石》作者，中国商联专家智库入库专家、国家互联网数据中心产业技术创新战略联盟(NIISA)智库专家委员会副主任委员、江苏银行业和保险业金融科技专家委员会候选专家、工信部企业数字化转型IOMM委员会特聘专家、财联社鲸平台智库入库专家、中国信通院可信云标准特聘专家、中国信通院低代码/无代码推进中心特聘专家，《研发运营一体化（DEVOPS）能力成熟度模型》和《企业IT运维发展白皮书》核心作者，容器云技能大赛课程出品人，多个技术峰会演讲嘉宾，拥有丰富的企业级DevOps实战经验，专注企业IT数字化的转型和落地，致力于企业智慧运维体系的打造。

前言：

数据库发展大致经历了四个阶段，

第一阶段，大型数据库阶段，“要像了解自己的老婆一样了解自己管理的数据库”，早期的应用迭代较慢，架构集中，尤其是在数据库层面，用比较流行的叫法是巨石型应用，在数据库数量、容量和业务需求都没有爆发的情况下，更需要 DBA 做出极致的优化，更强调对数据库内核的掌握，当时的 DBA 都是以写出极其复杂的 SQL 和掌握 Lock、Pin、Latch 运行机制为荣的；

第二阶段，小而多数据库阶段，分库分表的分布式数据成为互联网公司的主流数据库，如同保姆一般管理数据库已经做不到了，DBA的工作重点是不再是学习数据库内核和SQL Review, 而是转而将大量的日常运维工作脚本化，自动化，性能问题的解决主要将复杂的SQL拆分成多个简单的 SQL, 将复杂性留给应用做好Scale Out的架构；

第三阶段，虚拟数据库阶段，数据库逐步迁移到了虚拟机上，这个阶段可以认为是过渡阶段，因为面临很多问题，计算密度难以提高：虚拟化自身开销较大, 导致计算资源的有效利用率不高，进而导致用户需要更多的硬件存储开销较大：存储在硬件，网络，协议层面的变化巨大，但是虚拟化技术一直支持得不好，开销很大；

第四阶段，容器化数据库阶段，首先出现的是基于容器数据库，使得数据库可以高效的运行在容器内，管理大规模的容器集群，数据库运行在容器内，相比于虚拟机数据库，可以提升一倍的业务服务质量，还能够提高业务吞吐量，优势非常明显。但更细粒度的资源调度是将之运行在基于容器的kubernetes里，由后者提供了Scale Out 的能力, 相比读写分离集群功能更加强大, 同时也带来了运维的复杂性，于是乎DB Operator应运而生。

数据库为什么要容器化？其中有容器化是未来IT发展的方向的原因，更有如下三点原因：

（1）资源消耗
数据库的资源消耗是极不均衡的平时业务量不大时，数据库的资源消耗很低，当业务量正常时资源消耗变成常态，而有突发流量或不良查询时资源消耗又会超乎预估。如何才能兼顾成本消耗和意外突增的需求是一个长期依赖讨论的主题。而容器的引入给这个问题的解决提供了新的思路，我们可以利用容器的水平自动扩展和收缩能力为数据库提供所需要的资源。

（2）资源利用，资源调度
一个数据库实例一个高配服务器，这似乎是企业级的最低标配了。但如果将数据库部署在容器中，我们可以在一个高配服务器中部署多个数据库实例。实现资源利用的最大化。当数据库需要更大资源时，容器集群可以驱逐这个数据库实例，让其部署其他有足够资源的节点上。

（3）便利运维
数据库运维需要DBA，但将来这不是一个必然了，开发人员或厂商，可以把DBA的知识写在容器的operator中，自动“运维”容器数据库，目前数据库的operator不是很成熟，但是一个必然的发展方向。

本文主要是从数据库在容器中部署的特点出发，剖析了数据库在容器中部署会遇到的种种问题，并对主要问题的解决思路进行了阐述，并给出了解决的大致方案和方向。希望对大家在容器中开发容器数据库有所帮助。

一、 数据库容器化的需求

1.1 数据库运维的必然需求

通常DBA运维人员，研发能力比较弱，没有工程化项目经验。当然自动化运维、shell或者python脚本辅助工具等，对于小规模的RDS集群（10～20）的运维管理已经够用。但是随着公司规模的扩大应用场景的丰富，企业通常不会只有一种数据库实例，可能并存着MySQL、Oracle、MySQL、PostgreSQL等. 那么企业用人方要求DBA掌握多种数据库的特性能力，招聘多种数据库的人员，对于企业来说可能是不能承受的。

而且，同时我们注意到，关系型数据库在横向使用场景上存在共性如：高可用、RDS集群规模可扩展、计算/存储可变更、备份恢复、监控告警等等。完全可以统一化，各种不同的数据库之间是有共性的。

1.2 这是数据库服务质量的必然需求

研发和运维之间确实存在壁垒，我们经常看到研发人员发布软件应用上线后，需要由运维人员提供硬件和网络环境进行部署，通常运维人员并不关心你软件运行的“好坏”或者“快慢”，只关心物理服务和网络等监控指标。而DBA运维人员除了需要关心这些指标外，还需要关心数据库软件本身的“好坏”和“快慢”。

当企业开始微服务和DevOps建设后，对服务敏捷和快速交付能力提出了要求。而关系型数据库又是一类比较特别的应用场景，一些大规模的企业更是专门设置了DBA部门来负责数据库实例的运维和开发工作。随着企业业务对产品研发速度和快速适应市场的要求，数据库实例交付速度和能力逐渐成为瓶颈。也就是说研发、运维之外，还多了一个数据库的服务质量的考虑，而这有可能也会成为瓶颈。是否有方法可以规避这个瓶颈呢？

1.3 这是企业降本增效的必然需求

过去数据库都是大一统的模式，比如Oracle数据库是后台主力数据库，所以一套数据库系统占据多台高配服务器无可厚非，但是在某些低负荷的场合我们也发现CPU和内存使用率低下的情况，我们对此无可奈何，为什么呢？因为这是数据库，我