提个疑问，生产环境中的数据库可不可以用 docker 容器化部署？

肯定可以，有不少公司就是，只要能力能 hold 住就行。

不要给自己找麻烦

你是专业运维的话那可以试试,开发就算了

可以，只要把数据库的数据文件挂在到宿主机就可以了

没有什么绝对的合适不合适。

容器化解决的问题是什么，不能解决的问题是什么，带来的新问题是什么。

不用容器时的哪些问题在容器里能解决，用了容器仍然要自己解决的怎么解决，容器带来的新问题怎么解决。

这些问题想清楚了就有数了。

比如 HA 和备份，不管你用不用容器，都要自己做。除非你用的容器镜像是已经考虑了的。

可以，但没必要

可以啊 挂宿主机上就行

跑了三年了 每翻车过呢

肯定是要容器啊，你能保证每一次通过包安装的版本都是一致的么，容器的话是可以快速部署和保证一致性的，还具有复用性，还能自己维护一个自己的版本，小修小改

容器挂服务，数据单独处理

存算分离，大胆上～

可以，我们就是，不过数据是非核心的数据库，核心的数据库都上云了

你以为是个技术问题，有可能是个政治问题

直接用 docker 跑没什么问题，维护也不麻烦，反而比在宿主机上直接跑维护起来更方便
用 k8s 跑的话会比较麻烦一些，但用 statefulset 也能跑。

这个问题说不建议数据库安装到容器中，主要的考量应该还是容器部署性能有下降。性能足够的情况我觉得容器化部署挺方便的

我的遭遇就比较怪, 我当年第一份工作是前端, 第一天进去领导就让我学 Docker, 因为开发某些功能的时候, 我必须要拉一些后端服务到我机器上才能开发. 然后这么多年到现在了, 我只会 Docker, 现在开发自己的网站了, 我单服务器, 所有的服务都用容器化部署, 暂时还没碰见用不了容器化的场景, 也没考虑过为什么不用 Docker.

数据挂载出来就行

不知道你问题是什么, 是不是觉得数据库不能开副本所以才觉得不合适.
Kubernetes 也有数据库场景专用的配置, 不用担心.

可以，而且相对于直接在宿主机安装数据库可以不用考虑发行版版本和依赖的问题。

生产环境都是 docker 部署。放心大胆的用 ，数据挂出来即可

数据库可以容器化部署。如果用 docker 部署，将数据目录映射到 host 即可。如果用 k8s ，需要持久化存储的问题，k8s 有提供专门的持久化存储方案。对于 on-premise ， 使用 k8s 部署中间件是推荐的方案。

当然可以
这个跟能力有关，有能力怎么都行

数据库容器化早就不是问题了

为什么不行呢？ https://dev.mysql.com/blog-archive/mysql-with-docker-performance-characteristics/

现在通用做法就是 docker 跑 mysql ，data 文件夹-v 在宿主机

容器里跑呗，没事儿的。

云厂商的数据库都是容器实例，当然，人家的数据库已经修改的充分云原生化了

我觉得没啥不合适的，做好挂载存储和备份策略

对于 90%被要求使用信创的客户，docker 都不存在性能问题

感谢各位大佬解答，我是觉得没问题，因为本身公司内部的开发环境我也使用容器部署使用了好几年，并且新的服务器资源很足够！但是问了公司里的几个领导，他们都说不建议，所以我这边还是按领导的要求来，不想给自己找事。。。（ ps ，我内心还是站在容器化部署的！！）

@liyunyang 如果做的项目是面向企业的，那我强烈建议你上 docker ，这样交付的时候可以避免点各种各样的坑。

如果服务器多或者客户项目多已经形成部署脚本的话，那肯定是 docker 部署方便便于维护，我们公司的项目数据库就全是基于 docker 部署的，但感觉你这种情况完全没必要，不要给自己找麻烦

容器化部署没啥问题，conf 和 data 都要暴露出来，主从节点要测试网络连通性。但是用 k8s statefulset 部署数据库就比较麻烦了，最好还是独立在 k8s 外，用 service 访问

我也觉得数据库用容器部署没什么问题。
问题在于，如果有多个应用，是连接到同一个数据库容器，还是每个应用都各自开一个数据容器？

有没有专家说一下容器化管理数据库具体操作? 是把数据库的数据也容器化管理吗

小心一件事情，如果限制容器的 cpu 、内存资源，容易不稳定出问题。

因为，容器里获取到的 cpu 数量和内存都是主机值，不是容器限制值。

例如：主机 16 核但是 nginx 容器限制 4 核，nginx 会根据 cpu 数量自动设置 workers 进程数量，也就是按 16 核分配了过多的 workers 导致高负载下性能急剧下降。

例如：主机 64GB 内存但是 mysql 容器限制 8GB 内存，mysql 读到的是主机 64GB 内存，然后不断占用内存超 8GB 后被系统杀死，导致 mysql 异常重启。

推荐，不要在 docker 里限制容器 cpu/内存，改成在软件配置里加限制；如果必须在 docker 里限制容器 cpu/内存，则需要调整软件配置以匹配容器限制。

@COW 哈哈哈，尤其是那些机房涉密，完全隔绝外网的政府，国企，军工。用 docker ，珍爱生命

当然可以

这都 2024 年了还问这个

@arcaitan 肯定不是啊，其实这个问题 docker 官网写的很明确了，可以容器化数据库，但是数据盘不要放在容器里，做好挂载

很多人说这个就直接无脑说不行，那抛开容器，以下哪种最稳妥?
1. 物理机: 包管理安装，本地路径当数据目录
2. 物理机: 计算存储分离，iSCSI 挂载到机器上某个目录，数据目录这个目录
3.机器虚拟化，虚拟机上包管理部署 mysql ，本地路径当数据目录
4.机器虚拟化，虚拟机上包管理部署 mysql ，单独一个数据盘当数据目录
5. 物理机上 mysql 读写本地 ssd 盘当数据目录
6. 物理机上 docker -v 把一个路径当数据目录

请问以上哪个性能最差哪个性能最好。

讨论容器适不适合跑数据库要看场景说话，隔离的好，不调度容器，本地盘稳定 io 也高，为啥不可以。
总有人非要拿不好运维说话，那举例 mysql 数据损坏，常规 mysql 数据损坏下还不是 mysqld 起不来，自己用命令修复啥的，换到容器还不是 docker run -v mysql bash 进去用命令修。

数据还是在宿主机上，解决了什么问题？

既然是信创，那数据库大概也需要国产化，但国产数据库对 docker 的支持并不好，甚至没有稳定的 arm64 版本的镜像。

再者，用国产化的数据库，都需要购买授权。一般是客户自己去采购，这点就不可控，客户一般都不会买 docker 版的。

所以，如果只是用 docker 容器化数据库，可以，只需要将数据挂载到宿主机就行，运维我反而觉得更简单了。

如果是要用国产数据库，那么要慎重考虑是否要 docker 了。

很多说不建议用 docker 的，都是看了几篇带节奏的公众号文章，就和下属布道禁用 docker 部署了。

客观上，docker 的确是会有一定的性能损失，包括 fork 进程的资源消耗，包括容器的网卡 pair 相关，这些都需要资源，正确配置后，例如用 host 网卡，挂载宿主机路径，在高负载的情况下大概也就 7%-10%左右的性能损失，大多数应用都吃不满机器的资源，但带来的运维收益却是巨大的。

特别是交付型的项目，整个项目一个 docker 镜像出去，实施那边只需要解决如何安装 docker 这个问题，运维剩下的工作都基本上不是问题了。

一般来讲可以，没问题；

但是如果你们担心数据量上去了会有问题，业务问题或者性能问题，而且没有能力验证的话，要么不要冒险直接物理机，要么把验证周期拉长，得出结论之后再决定

我就是，单纯的 Docker run pg

@yinmin 有经验的

我觉得没问题，我接私活就是这么干的。公司没这么搞，不过公司生产环境也不是我负责，所以与我无关了。

这件事可以参考 https://i.imgflip.com/4qnhqj.png

最傻的回答是：没问题。因为这群人就是在单机上跑 docker 当虚拟机用

中间的回答是：有问题，因为 docker 集群对应的销毁 - 创建过程会导致高可用问题和数据一致性问题

聪明的回答是：没问题。因为 pod 是可以有状态和强行绑定的

但是要做到聪明回答，即便有一个 DBA+一个 SRE 也很难胜任。得既特定版本的 db+k8s 的懂哥才能搞好。还不如就一个 dba 直接物理机部署。

我最近在学习 docker, 本地一开始没用 docker 的时候, 某个 app 用了 db
然后用 docker-compose build, 里面 app 也会调用一个 db

我的问题是, 我用 docker-compose up 之后的调用的 db, 和本地的 server 拉起的那个 db, 不是同一个(虽然他们 dbname, 结构都相同, 就是数据不同) , 这俩 db 是完全不同的两套安装目录吗?

可以，但必要性不是很大。

太可以了，这都 2024 年了

可以，数据一定要挂到本地，存算分离

k8s 下，有靠谱的 csi 的情况下，数据库容器化没有任何问题。
有 operator 简化一些基础操作，平时遇到的问题和 bare metal 的数据库没有任何区别。

k8s 持久性存储的 io 有瓶颈，绝大多数的 k8s 持久存储都比 sata 还要慢很多，所以数据库不建议部署在 k8s 上。如果是本机 docker 是 OK 的，性能基本接近本机安装，维护也方便。

没有极端的写入场景的话，没问题，和 k8s 的运维协调好资源限制

这个还真行，配置好数据一致以及容灾管理即可

接#57 如果必须在 k8s 上部署数据库，估算一下数据库的大小，然后为容器分配 2 倍以上的内存，例如：估摸着数据库总容量为 6GB ，就为容器分配 12GB 内存。容器刚启动时读盘稍慢些，跑一段时间后数据库都缓存在内存里，就不慢了。

正确使用 docker (container) 是一项很有挑战性的事情，自己用随便用，团队里面有菜逼的话还是按短板来

云原生化的数据库，行业内有生产级别的应用了

@yinmin 这个也能解决，给内核打 patch 就行

当然可以 这和 docker 没什么关系吧 有 docker 反而方便部署。重要的是数据库做好各种备份。

看信创化或者国产基准要求

云厂商都是容器化了吧

当你考虑到架构变化带来的新可能，那些性能损失根本不是问题。微服务就有设计每一个服务一个数据库，自从有了 k8s 和 helm ，部署 HA 的数据库从来没有过的简单，非常有效率。其次容器本身只是计算，储存是没有变化的，依然是磁盘上。我看不到任何理由拒绝容器化。事实上各种算法，包括大模型，CNN ，神经网络等等都是组织架构意义上的进步，是数据结构和数据关系的进化，数据库本身如何运行，在哪里运行，如何协同合作，容器化提供了载体，让这些成为可能。再说，即使不容器化，所谓上云，还不是虚拟化吗？为什么不质疑虚拟化而去质疑容器化呢？

@yinmin k8s 接全闪 ceph 或者其它主流商业分布式存储，fio 跑 4k random rw iops 随便上万（ 2 x 10g trunk ）。不知道怎么会得出不如 sata 的结论。

数据库的核心资源需求就是存储和内存，存储垃圾裸金属也没救。

自己玩随意，生产环境下的“有状态副本集”怎么部署看领导的安排，之前有大佬推荐 KubeBlocks ，可以参考下这个

用 docker 是不是方便启动服务,但是数据是用操作系统直接存文件有风险?

@yinmin 8.0.3x 及之后的版本已经能识别 cgroup 的资源限制了。 建议及时升级。

理论上只要存储挂出来，无论 docker 或者 k8s 应该都是可以。
但你要考虑运维，dba 他们的能力。无论是升级还是数据恢复，dba 是否有解决的能力。

可以，部署有状态应用 k8s

@adoal #5 还是说唱歌手

重要数据基本都备份，多个宿主机容器挂卷打通就行吧

MySQL Docker 情况下，遇到过一个很底层的问题，但是总体上将数据卷挂载到物理磁盘是可用的。

可以，很成熟了。把存储目录挂在出来就行了。

@adoal 上次听人这么说还是上次，给你点赞了

有备份就行。之前生产遇到一次断电，可能数据卷出问题了，docker 里面的 mysql 再也拉不起来了，只能初始化重头导入备份。

肯定可以啊，k8s 不都是挂存储卷的吗

- 一般 PV 和 PVC 用的外部网络存储，延迟会高一些，但用本地硬盘，那必须绑定到某个 node 了，reschedule 换节点的功能就用不上了，感觉怪怪的。还会和其他 pod 竞争资源，追求稳定的话不如专用服务器。
- k8s 版本升级也会有数据库中断问题

如果是简单玩玩，或者不重要的小业务系统，可以用容器跑数据库。把数据盘挂存储卷，做好备份和监控。
如果业务对延迟、并发性能敏感，不建议容器部署数据库。

容器上跑数据库，总的原则大概是：可以，但不建议。

感觉是有难度,要有特定的镜像的才行,不然的话主从的自动切换都是个问题.访问上要读写分离也是要配置.客户端有办法通过 7 层的 ingress 访问数据库吗,不能的话对运维也是很讨厌的事情.

完全可以，但是没必要。本来你是 DBA ，现在你要熟练掌握 K8S ，而且会变的很复杂，还记得滴滴 K8S 事故吧

你老老实实的虚拟机或者物理机上跑数据库，infra 至少可以安心的 5 年不大动。
跑在 k8s 上呢，每年至少来一次 k8s 大升级折腾一回？

可以，但是没意义
还得挂一堆 volume 给它，和本地直接运行没什么本质区别

@abolast 指定包版本号安装肯定是一致的啊
你可别说同一个版本号也可能被篡改过这种话哦，你们容器镜像也可能会出类似问题的

@importmeta 其实最大的问题就是“你只会”、“没考虑过我什么不用”

而，“都能用，暂时没碰见用不了”反而不是主要矛盾

你在问这个问题，我觉得你对 docker 还是不是很熟，而且你公司的 dba 也未必会运维。
所以，我建议你不要把数据库放在 docker 。

可以，但是从描述上来看，应该对 k8s 方面不是特别了解，进 k8s ，要理解存储、有状态工作负载等概念，然后就是基础的数据库运维相关的操作，确保在出现问题后能够及时进行处理，否则的话，以自己和公司运维最熟悉的经验来做是最好的。没出问题的时候，公司不会认为做了多牛逼的事情，但一旦出问题了，谁改的谁就要背锅。

可以试试 KubeBlocks

可以，技术上没有障碍。不过决定容器化后，比如 mysql 的集群模式有几种方案，都要调研选择...

@Suaxi kubeblocks 可以的，数据库容器化还没看到过好点的开源，好像是原来阿里的人搞得，还没看到平替的，打算入坑了