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

别在 docker 上跑数据库，会被坑死的

~~ 感觉 数据库跑在 container 里各种不顺利
还是搁在外面好

别在 docker 里跑数据库，会被坑死的

@windfarer 坑在哪？内存还是什么？我自己的博客就是 docker-compose 一套，跑的满正常的啊

别在 docker 里跑数据库，会被坑死的

docker 跑数据库有什么问题。

博客不论，我公司的 gitlab owncloud 数据库都在 Docker 里啊

大家都说会被坑死，具体是有哪些坑呢

我目前在 docker 中跑过的数据库包括

mysql (for blog/owncloud)
postgresql(for gitlab)
redis

可能运气好，暂时还没被坑到

data 不会放容器里，放在其他专有目录
容器里运行数据库程序进程，通过 -v 去读写 data 目录

想问哪些坑，我的网站、论坛都跑在 docker 里，几个月了都没问题，有什么隐患？

完全不懂说被坑的是怎么回事，莫非没用官方镜像自己 build 出了问题？

想起了昨天有个人说，重启容器数据没了，于是说 docker 的不好的梗 ^_^

@xyjtou

数据库表示一脸蒙蔽，放在 docker 里有单独服务器与否有关系和冲突么？

人家不过是为了保证 正式 /开发 /测试 的环境一致以及迁移方便用 dcoker 了，怎么就成舍得不舍得了？

@xyjtou

随便搜了下，看来京东也是个很抠门的公司

http://dbaplus.cn/news-11-1118-1.html

搞不懂楼上在喊“别在 docker 里跑数据库，会被坑死的”的原因在哪，现在有些云厂商提供的 rds 都是跑在 docker 上的，压根没啥坑，当然你把数据放在容器里面能怪 docker 。。。

@brucedone 自己博客的数据库用 docker 跑还行，但生产环境中就要慎重使用。具体为什么，请看一楼发的链接

当然第一种方案了。
程序和数据库分开比较好。因为数据库一般单独运行。程序可能需要负载均衡之类。

不过不是对外提供数据库服务的话。确实数据库没必要放 docker 里面。不方便管理数据库啊。

@windfarer

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

突然挂掉后丢数据？

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

@windfarer

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

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

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

@xyjtou

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

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

@windfarer 请看文章下面的评论

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

@junnplus

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

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

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 年款 DockerApp 4core 8g host 挂载 volume 4~5hrs

@cxbig

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

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

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

@cxbig

不过看了下你的数据。

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

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

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

@cxbig

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

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

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

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

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




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

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

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

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

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

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

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

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

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

@HypoChen

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

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

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

这句话没看懂。

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

1, 但生产环境不建议用 docker-compose

@cxbig EBS 的 IO 本来就很烂, 这锅 docker 不背

docker 跑数据库， data 映射到宿主机没问题。但是多个容器读写竞争怎么处理？

对了，回到楼主的问题。

我跑 Docker 一般是建一个 subnet

每个服务分配一个内网 ip

直接用内网 Ip+端口访问

以 mysql 为例，大概是这样

docker run --network=vps --ip=10.1.1.2 --name mysql -v /dockers/mysql/data:/var/lib/mysql -v /dockers/mysql/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=123456 -d --restart always mysql

@jarlyyn

你说的没错，但是这些是建立在单机应用上的，可以简单的把里面的数据文件夹随便映射到宿主机上一个地方，然后保管好宿主机上这个文件夹就可以了

但是，如果只是这样使用的话是不是和不用 docker 一样，和直接在宿主机上装一个 sql 并保护好本地的文件夹没什么区别。

如果要把文件挂主机上，那么有几个问题怎么做，如果这个机器挂了，我的容器需要快速迁移到别的机器上，如果文件在这个机器上，当机器挂了之后数据是不是就不能用了，当然，你可以提前备份，但是这样是不是和不用 docker 的姿势是一样的。或者说我需要扩容，而且是扩容到多台机器上做高可用，是不是这样并不能算方便快捷。

docker 本来就是是的复杂场景变得方便而有了价值，在面对复杂场景的时候，并不是一个简答的 -v 加一个宿主机文件夹就能解决的。但是换句话说，如果需求很简单，怎么方便怎么了喽

@HypoChen

docker 最开始不就是提供了一个 namespace 和一个网络配置么……

我也一直把 docker 当成一个单进程的运行环境来用的……

主要看中 docker 的迁移 /独立的版本控制 /相对独立的环境。

看来是我用的太浅了……

机器挂了的问题不是该由数据库的主从同步来处理么。

这里对比的是 使用 docker 和使用原声环境安装进程吧？

你提的问题原生环境直接安装也没办法解决啊。

只能说看需求，追求性能肯定不放 docker ，追求部署简便放 docker （单独放一个）

@HypoChen

再比如机器挂了的问题。

如果是真机挂了，不是应该直接拆硬盘挂到别的跑了同样 Docker 的机器上处理。

而如果是各种云服务，就是开新的计算单元，装好 docker 把云磁盘架过去……

我对 docker 的理解只有这么浅。

@cxbig 也试一下 EC2 上 apt-get 裸装吧。感觉不一定是 Docker 的问题。

你们讨论那么多，我算是明白了

数据究竟该不该存镜像内？假 docker ？

总有种为了 docker 而 docker 的即视感。

@cxbig
@jarlyyn
@tafee
我一直想在生产环境用 docker ，但怕性能问题，搜索过很多相关观点，本帖子之前所有观点都说“ docker 造成的性能损失小到可以忽略不计”，但现在你们的说 docker 会给 mysql 造成性能这么大的损失，以网上其他观点完全不同啊。

@Bardon 数据从来就不应该在镜像或容器内

@gdtv 取决于你在什么环境部署你的项目，如果你有自己的物理服务器，性能不算差。
就目前我用过的 AWS EC2 、 Linode 、 DigitalOcean 这几家的都不理想。
当然测试仅限于小型 VPS ， 4 核 16G Ram 左右。大型独占的没有试过。

@cxbig 只是看到上面某层楼说假 docker 而有感而发...

另外，没有什么“本来不应该...”，如果性能允许，放镜像内，保留各种 commit 历史，回退是非常方便的，

@gdtv 考虑是 io 还是 cpu 密集

linux 下本来就是基于进程级的，负载差别基本就看 IO 以及内存差别了
当然，容器与宿主机文件系统不同， Volume 挂载后磁盘 IO 会造成很大的差别...

说错了， docker 利用的一种类似图层形式的文件系统，使得读写在不同的层次上

所以上面说错了，不存在 docker 与宿主机的文件系统不同。 IO 差别，反而在 aufs,overlay,btrfs 与 devicemapper 之间，以及不同层上读写的差距了。

目前， overlay 人气较高， gentoo 下可以直接选择 overlay 这个 use flag 来使得 docker 采用 overlayfs

centos 下还是 devicemapper ，需要一些技巧才能采用 overlayfs

deb 系的没用过，不知道

具体 docker info | grep Driver 查看。

@Bardon

Storage Driver: devicemapper
Logging Driver: json-file
Cgroup Driver: cgroupfs

debian testing

单一容器只运行单一的服务, 减小耦合度
自己 MySQL docker 没遇到过问题

docker 初衷是隔离应用程序的不同版本及灵活编排程序运行环境，避免互相干扰，同时让操作系统版本依赖更少、更稳定；至于数据目录放哪里及性能损耗，可以按 2/8 原则来分析，并不是每个项目都需要全负荷的运作，满足 80%以上场景即可。

如果非要钻牛角尖，你何止不需要用 docker ，完全可以不用数据库啊，直接 io 写数据到硬盘即可，这样性能肯定比经过数据库运算解析后再存储要高很多。