MySQL 到底能不能放到 Docker 里跑

　　Close亲爱的读者：我们最近添加了一些个人消息定制功能，您只需选择感兴趣的技术主题，即可获取重要资讯的邮件和网页通知。

　　Talk is cheap，show me the demo。MySQL 到底能不能放到 Docker 里跑？同程旅游目前已经有超过一千个 MySQL 实例安全稳定地跑在 Docker 平台上。

　　前言

　　前几月经常看到有 MySQL 到底能不能放到 Docker 里跑的各种讨论。这样做是错的！这样做是对的！说错的理由也说了一大堆MySQL文章入库助手，说对的思想也很明确。大家都有道理。但是我本人觉得这样的讨论落地意义不大。因为对与错还是要实践来得出的。

　　所以同程旅游也很早开始了 MySQL 的 Docker 化实践，到目前已经有超一千多个 MySQL 实例在 Docker 平台安全稳定地跑着，DB 运维能力发生了质的提高（DBA 再也不用担心删库跑路了）。

　　相关厂商内容

　　一堂课教你看懂技术创新与商业模式

　　面向未来的原生化Web开发 Airbnb的闪订功能和增长策略 Dubbo开源现状与未来规划 Apache Kafka的过去mysql文件入库工具 ，现在，和未来

　　相关赞助商

　　当然这样是不是可以证明之前的讨论结论——是对的mysql文章入库软件 。我想也不一定，因为我们还只是一只在学飞行的小鸟，还要更多的学习，所以我们特将我们在 MySQL 的 Docker 化上的实践分享给大家。

　　背景介绍

　　同程旅游早期的数据库都以 MSSQL 为主，这个产品有个特点就是 UI 操作很棒。但是批量和自动化管理很难做，人力的工作很多。后来逐渐替换为 MySQL 后也是按照传统的运维方式管理。导致大部分的工作需要人肉运维。

　　当然像我们早期使用过的 MSSQL 也是有优点的：就是单机性能比较好，在当年那个资源不够的年代里我们常可以在高可用的实例上运行多个库。这种情况下物理机数量与实例数量还是比较可控的，相对数量比较少，人肉运维完全可以应对。

　　但是 MSSQL 的缺陷也很多，比如做水平拆分比较困难，导致数据库成为系统中最大的一个瓶颈。但在我们使用 MySQL+ 中间件（我们做这个中间件也是下了不少心思的，以后可以分享一下）做水平拆分后就开始解决了这个瓶颈mysql文章入库软件。

　　水平拆分的引入也带来了一个小缺点，就是会造成数据库实例数量大幅上升。举个例子我们做 1024 分片的话一般是做 32 个 node，一主一从是必须的（大部分情况是一主两从），那么至少 64 个实例，再加上应急扩展和备份用的节点那就更多了（中间件的开发者更希望是 1024 片就是 1024 个实例）。

　　一次上线做一个 32node 分片扩展从库，两个 DBA 足足花了 4 个小时。另外，如果做单机单实例那肯定更不行了，别的不说，成本也会是个大问题，且物理机的资源也未能最大化利用。况且因为 MySQL 单体的性能没优势所以分片居多所以大部分情况下并不是每个库都能跑满整个物理机的。即使有部分能跑满整机资源的库，它的多节点备份，环境一至性和运维动作统一等问题也会让 DBA 一头糟，忙碌又容易出错的工作其实是无意义的。

　　有了单机多实例运行 MySQL 实例的需求。单机多实例要思考的主要问题就是如果进行资源隔离和限制，实现方案有很多，怎么选mysql文章入库软件？KVM，Docker，Cgroups 是目前的可以实现隔离主流方案。

　　KVM 对一个 DB 的隔离来说太重了，性能影响太大，在生产环境用不合适。这是因为 MySQL 运行的就是个进程而且对 IO 要求比较高，所以 KVM 不满足要求 (虽然优化以后 IO 能有点提升)。

　　cgroups 比较轻，虽然隔离性不是很高，但对于我们的 MySQL 多实例隔离来说是完全够用了（Docker 的资源限制用的就是 cgroups）。但是我们还想针对每个 MySQL 实例运行额外的管理进程 (比如监控等等)。用 cgroups 实现起来会比较复杂，并且我们还想让实例管理和物理机区分开，那 cgroups 也放弃。

　　至于 Docker，那就很不错了，那些裸用 cgroups 的麻烦它都给搞定了。并且有 API 可以提供支持，开发成本低。而且我们可以基于 Docker 镜像来做部署自动化，那么环境的一至性也可轻松解决。所以最终我们选择了 Docker 作为云平台的资源隔离方案 (当然过程中也做了很多性能、稳定性等的适配工作，这里就不赘述了)。