docker 使用 mysql 时选择新建 mysql 容器还是单一容器内新开 mysql 进程？

[tafee]

看了网络上的两种在 docker 中使用 mysql 的方法： 1 、新建 mysql 容器，利用 docker-compose 或者其他编排工具与运行程序的容器 link ； 2 、在单一 docker 容器中，利用 supervisord 创建 mysql 进程和程序进程；

V 友们如何选择的？这两种方案的优缺点在哪儿？ 个人感觉第二种方案已经失去了 docker 容器化的意义。。。

[jarlyyn]

@windfarer

一楼发的链接到底说了什么数据库不能放在 Docker 的理由？

突然挂掉后丢数据？

[xyjtou]

@jarlyyn 数据库要什么环境一致？生产机的数据库优化方案在开发机上根本没必要搞，搞了没哪个数据量级也没用。

[jarlyyn]

@windfarer

顺便， 1 楼的链接，假设他是最原始的链接，上一片文章是

https://myopsblog.wordpress.com/2017/01/02/20-things-ive-done-in-2016/#more-1987

2016 年完成的 20 件事，嗯嗯，

[jarlyyn]

@xyjtou

是哦，测试环境和开发环境也不需要一样的版本。

开发环境的数据版本比正式环境高一点也没关系，可以把正式环境升级一下么， so easy.

[junnplus]

@windfarer 请看文章下面的评论

[junnplus]

@ohhe 有没有必要放在 docke 里面和方不方便管理数据库没有关系吧

[jarlyyn]

@junnplus

大概是他不习惯 Docker -exec -ti bash

又遇到宿主机客户端和容器服务器不兼容？

[cxbig]

Docker 的理念就是一个服务独占一个容器。所以 MySQL 要独立开一个。

目前的测试感受，用 Docker 跑 MySQL ，无论是内置 volume 还是 mount 到 host 文件夹，性能都远不如直接装 MySQL 来得快。

我司一个 dump ， gzip -9 压缩大概 1G 上下，导入速度参考：
AWS RDS m4.large 25mins
AWS EC2 m4.large Ubuntu 16.04 Apt 安装 30mins
MBP 13 寸 13 年款 Brew 安装 40~50mins
MBP 13 寸 13 年款 Docker App 4core 8g 内置 volume 3hrs 20mins
MBP 13 寸 13 年款 Docker App 4core 8g host 挂载 volume 4~5hrs

[jarlyyn]

@cxbig

性能肯定是有损失的，特别是文件读写。

[cxbig]

@jarlyyn
默认配置做的测试，性能相差太远。所以暂时没有明确的解决途径，就没多折腾。
公司也不想我折腾，宁愿在 AWS 上砸钱求稳定。

[tafee]

@cxbig 从性能上看，“别在 docker 上跑数据库，会被坑死的” 也是没错了

[jarlyyn]

@cxbig

不过看了下你的数据。

你 docker 在 mac 下跑得？那还要转一层虚拟机啊。

应该是在同一环境的原生 linux/docker 对比才行吧？

[cxbig]

@jarlyyn
Docker for Mac 在运算性能上不差，唯独差在 I/O 。 Linux 下我也试过，没有明显改善。

[jarlyyn]

@cxbig

http://www.dockerinfo.net/729.html

看到的资料没看到 docker 的性能有很大的差距。

不行晚上回家在我自己的电脑上跑下对比测试看看。

[lightening]

只好会配置，数据库跑在 Docker 里也是没什么问题。但是配置比较麻烦。
如果用 swarm ，怎么配置多个 replica ？怎么配 cross-machine volume ？
如果 docker 占了全部硬盘空间，要清理，不小心一条命令删了 volume 也是很有可能的事情。

这些问题只要会配都没问题，但是就怕不熟练不小心搞错不是么。




@cxbig Mac 上的 Docker 是运行在虚拟机里的啊，你这么看到的是虚拟机的性能开销。找个 Linux 机器试试。

[cxbig]

@lightening 在 EC2 上试过， I/O 性能上不如 RDS 。

[cxbig]

另外 Docker Image 有 Layer 的因素，碎片文件特别多，对 inode 敏感的机器也是不小的压力。
AWS EC2 开过 32G 的 General Purpose SSD (GP2)，只分配了 2M 的 inode ，仅仅只是 pull 了几个常用的 image 就吃掉了 80%的 inode 。用了 5G 空间就报 No space left on device 。

[HypoChen]

其实并没有什么争论的，至于是不是坑，我只能说，任何软件，工具，轮子都可能被用成坑

首先容器会降低性能，毋庸置疑，无论 网络 还是 磁盘 io ， docker 慢众所周知，但是他部署扩容快啊，看你取舍喽。当然包括上面说 Image 对磁盘的压力，是另一方面，毕竟数据库镜像不经常更新 Layer 。

然后就是把数据库放容器里，因为数据库的特殊性（存储数据以及版本不经常变动），我一般是不建议把这东西放容器里的。
首先是数据问题， docker 并不建议把数据放在容器里，并有了 volume ，数据库这种数据优先的程序更是，无论是把数据放在 volume 还是其他 driver ，都徒增对这些数据的管理（以及风险），而这些管理却一定程度上依赖了 docker 。
然后就是 docker 引入的问题，无论什么数据库，现在的解决方案是非常完善的，但是引入 docker 之后，在一定程度会受到 docker 的影响，比如 daemon 挂了而你恰好要要对数据库这个容器操作，你是打算先修 docker 呢 还是先修 docker 呢。

总之呢， mysql 放在容器里说白了也不过就是一个文件夹的数据和一个进程而已，如果处理的好（对 docker 很熟，没有人为失误）而且运气足够好（遇不到 docker 的 bug ），而且对性能要求不大，那么放哪都一样，怎么喜欢怎么来。

啥？你只是把容器里的 data 目录映射到了宿主机提供数据库服务？我认为你用的是假 Docker 。

[HypoChen]

不过扯回楼主的主题， docker 建议是单一进程的，也就是这一个容器里只跑一个进程。也就是第一个选择更好一些。
原因很简单，比如这个唯一进程挂掉了，容器也就挂掉了， docker 可以很方便的发现这点并进行后续操作，比如 restart 。

[jarlyyn]

@HypoChen

“然后就是 docker 引入的问题，无论什么数据库，现在的解决方案是非常完善的，但是引入 docker 之后，在一定程度会受到 docker 的影响，比如 daemon 挂了而你恰好要要对数据库这个容器操作，你是打算先修 docker 呢 还是先修 docker 呢。 ”

不是应该把 data 文件夹 cp 出来 /通过别的方式挂载使用么……

“然后就是 docker 引入的问题，无论什么数据库，现在的解决方案是非常完善的，但是引入 docker 之后，在一定程度会受到 docker 的影响，比如 daemon 挂了而你恰好要要对数据库这个容器操作，你是打算先修 docker 呢 还是先修 docker 呢。 ”

这句话没看懂。

数据库进 docker 不是应该 -v 配置文件夹和数据文件夹的吗？