问下各位大佬， mysql， redis 这种数据库放 docker 里面，是否不太稳定

服务是否稳定取决于资源调度和数据落盘。docker 用的资源调度使用的是内核级别的 cgroups ，数据管理用的是 overlayfs 如果不放心，可以直接把服务迁移出来直接用 service 级别的服务。

docker-compose 只是个命令行集合，压根就不是服务，何来的重启。你要是执行 docker-compose 重启 mysql 容器，那跟你用 mysql 命令重启 mysql 服务是一样的，重启时机不合适谁都出问题，谁也别看不起谁。同样，docker 服务挂了，等同于 linux 主机挂了，谁也别看不起谁。

但是，docker mysql 容器，绝大多数情况下，是真得不如 linux 上直接的 mysql 服务。原因是很简单，docker 容器改配置真麻烦，你很难得到一个适合的 mysql 镜像。除非你有高超的 shell 脚本能力能自制镜像，否则还是老实的直接用 mysql 。

Redis 不用落盘的话放 docker 也无所谓

一般生产的数据库不建议使用 docker 容器，还是老老实实使用云服务厂商的 RDS 。

一直都放 docker 里面，跑了有 5 年了，没啥不稳定的。

看看 DBA 怎么说的

https://mp.weixin.qq.com/s?__biz=MzU5ODAyNTM5Ng==&mid=2247486572&idx=1&sn=274a51976bf8ae5974beb1d3173380c1&scene=21#wechat_redirect

可以用 k8s ，有公司直接支持 30 多种数据库跑在 k8s 的 docker 里了： https://apecloud.cn/

我在内部工具平台小规模场景下用 docker host mysql 很多年了，没什么问题.

至于说 生产环境 DB, 的问题主要还是运维的复杂度，但这个问题不是 docker 带来的，你独立部署也会带来一样的问题啊，只是 仅仅一个 docker 给你运维这种服务没有什么帮助，甚至由于与既有运维工具链的兼容配合问题，会更加复杂和麻烦.

你裸部一个 mysql 用来做生产问题也很大啊，只是出问题有很多资料帮你解决，所以还是 运服务吧，或者 用 vitess 这样的

懂 op 的意思，有时候先重启 redis ，有时候先重启 mysql ，这样会出现一些问题

你可以设置 app 的 depends_on

services:
app:
build: .
depends_on:
- db
- redis

缓存和数据库跑在 k8s 里没问题。

单独写一个 compose ，像这样：
services:
mysql:
image: mysql
networks:
- abc

networks:
abc:
driver: bridge
name: abc


另外写一个 compose ，像这样：
services:
webapp:
image: webapp
networks:
- abc

networks:
abc:
driver: bridge
name: abc

你可以独立停止/启动任意一个 compose
其他的 compose 都不会受影响，而且可以用 service 名字来当作域名互相访问

分开两个 compose ， 使用共享网络。
1.依赖服务
2.经常需要维护应用部分


nginx 使用备用服务：

upstream app_sock {
server 127.0.0.1:3300;
server 127.0.0.1:3400;
server 127.0.0.1:3500 backup; #
}


维护时先升级这个两个端口的容器：3300 ，3400 。
3500 容器保持在线，前面两个端口升完，这个最后升级。
这样升级时影响降到最低。

单独部署不是也会有你说的问题。去拔掉电源，这时更新不也是有问题。

1. 应该考虑的是应用服务器与数据服务器是否应该分离
2. 数据库是否应该高可用，集群部署

docker 只是落地手段，k8s 不还是挂 docker 。 难道 k8s 是为了搭建开发环境的。
不用 docker 和 k8s 这些问题你也要面对。 工具直接简化解决问题的方式

纯 docker compose 管理其实只要备份做好了问题也不大。主要还是分散的 docker 管理比较麻烦。
最好还是上 k8s 加个 operator 来管理这些东西，这个已经是经过大规模生产考验了的，还在说数据库 redis 不适合进容器的该歇歇了，已经 2024 年了。

k8s 可以在 1 分钟之内拉起一个 mysql/redis 集群并且由对应的 operator 实时监控状态主从切换，备份可以用 Percona XtraBackup 实时热备，并且对应负载均衡和 ingress 乃至监控的接入都可以同时生成。
一切的操作只需要你修改一下 chart ，改一改 crd 或者 configmap 参数，就可以大规模复制。

换成 linux 裸机，用 playbook 自动安装部署花的时间一般会更长，除非专门优化过。


如果你的业务全都容器化了，运维工具全是云原生的，那么没有理由让数据库和缓存单独孤立在 k8s 外面。

反之如果你的运维工具链全是基于裸金属的，那就全都裸金属。

@shijingshijing #26 这篇文章明显是一个 PG dba 的 bias ，而且一看就是没有多少云原生生产经验的
他甚至都没有提及生产中大量使用的 PGO
人家从
监控(pgMonitor)
备份(pgBackRest)
高可用
连接池
集群克隆
PostGIS
升级管理
都提供了完整的解决方案，全都集成在 Operator 里面了。
而文章作者还在用裸金属运维工具在运维云原生的东西，然后吐槽一堆 bug 不好用。

更不用说 op 这里提到的还是相比 pg 云原生更成熟的 mysql/redis 。

一般水平的 dba(指只会备份还原/打打补丁/脚本 boy)都快被 operator 取代了，没理由其它的职业都在 skill up ，就 DBA 不转型吧，一旦他依靠的老东家一垮，出去还能找得到他说的传统 DBA 工作吗？

如果没用云服务厂商的数据库，也没有自己建集群，我觉得用 docker 跑的风险并不大。大家都是虚拟化，不至于 docker 跑数据库就爱翻车。

库文件和服务分离就行,储存文件夹挂载到主机

如果你的 docker 特指 docker 本身，那确实还是裸机好点。如果你是想说容器这套东西，那我只能说你能想出名字的云厂的 RDS 全部都是容器。

docker 容器很容易挂掉的

1G 内存服务器+Docker+postgresql 内存满了机器死机，重启后发现丢了一部分数据，之后就单独部署数据库了。