关于数据库不适合放在docker里面，有两个歪果仁的文章，其一就是楼主所贴，其二是这篇，译文

还是那个观点：

量小的时候随便搞，量大了有些东西就不行了，传统型数据库和docker并不对路，建议不要直接容器化，非要把数据库容器化，那么需要各种系统的支撑，包括中间件系统、容器化系统。

如果你的数据库能够自动伸缩、容灾、切换、自带多节点解决方案等，docker算是一个比较好的方案。

但是如果不能，还是不要用docker。

原文中也说得很清楚：

在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。

流量小的情况下，什么东西容器化都行。数据库，应用，hadoop，各种节点，nginx。

量大的情况下，存储相关的不适合容器化，应用层、业务层等无状态的服务适合容器化，缓存这类内存密集型的服务可以容器化。

简单来说就是三个问题，容灾、性能和数据一致性。

就mysql这种传统数据库而言，仅仅我所能列出来的问题就有如下这么多：

1. mysql怎么容器化？

2. 主库mysqld跪了怎么办？

3. 主库dockerd跪了怎么办？

4. 从库mysqld跪了怎么办？

5. 从库dockerd跪了怎么办？

6. 能否在高峰来临之际通过容器快速扩容mysql？方案？

7. 数据主从切换方案？一致性如何保证？

8. 高峰时期量足够大，有时候一般一台物理机的容量只够一个mysql进程。

9. 那么同样是单台机器，为什么不能直接启动mysql？

10. 为什么还要外面套一层容器？对性能损耗多少？

11. mysql如何升级？

12. 数据卷是否会丢失数据？（损坏容器我遇到过很多次了……）

但是mysql也不是全然不能容器化。
对数据丢失不敏感的业务（例如京东搜索搜到的商品）就可以数据化，利用数据库分片来实现通过增加实例数增加吞吐量。

题主原文中提到的问题，有些东西是有槽点的，但是考虑的很周全。比如如下问题就很有槽点（关于共享数据目录）：

容易水平伸缩？是否要在多个实例之间共享数据目录？你不害怕直接数据并发问题和可能的数据损坏吗？使用专用数据环境部署多个实例不会更安全吗？最后搞一个主从复制？

就我目前接触到的数据库来看，只有cassandra这类（个）（还有tidb和cockroachdb，但是目前还没遇到过大公司的用例）数据库适合容器化。

但是cassandra自身也接近是无状态了：自己提供容灾，扩容，切换方案。

以下提一下京东。

京东是个异类，但是京东也提到过类似的问题和需要注意的地方。

计算类应用、无状态应用优先，例如微服务特别容易迁移到弹性云。
应用迁移到弹性云，最好选择统一的规格，避免各个实例的负载不均衡。
应用从物理机迁移到弹性云后，实例数量会增加，相应对后端服务的连接数会增加，特别是数据库连接，所以需要防止连接过载。
在弹性云上共享磁盘IO，要避免应用刷日志，减少本地读写文件，采用JFS或JIMDB来满足文件存储或共享数据需求。
容器的CPU核数原低于原有物理机的核数，应用需要根据CPU核数来合理地配置线程数和网络参数。
修改底层，让应用在运行时能准确地拿到自身容器的核数。

甚至，对docker做了很多的定制。

可以看京东分享。

不适合, 而不是不能.

如果单机没什么问题, 在某些情况下还是有利的. 比如之前我公司的oracle数据库调参数时导致数据库崩溃彻底起不来了, 还好那时用的是docker, 直接run一个, 把数据目录指向原来的就好了.

集群的话不管怎么样, 用docker手工组, 或swarm这类工具也好, 都不怎么好搞. 还不如直接在物理机上搭建省事.

国外有家公司就是专做docker的数据存储方案的. 比如flocker, 还有rancher的convoy

docker放更适合无状态，不会变更服务。

如大量集群的时候：
编写好docker file。然后当代码上传到代码仓库的后，在然后部署让好docker file以后，再让发布脚本批量构建docker服务并把服务代码放进去。

不仅仅是MySQL，类似于redis，mc都不适合放入docker中，或者说放把数据库放docker中有为了使用docker而这样做，并没有太多的好处。

是的，因为docker的特性决定了它是不适合做数据储存的，不只是数据库，所有储存相关的服务都不适合用docker。

官方mysql镜像是把数据存储在哪个目录的我都看不明白。