数据库适合docker及容器化吗？-灵析社区
万码D0YNGCCN看到网上有言论说数据库不适合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做了很多的定制。
可以看京东分享。