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

docker-compose 是不是可以重启指定的服务？重启指定服务数据库\redis 也会暂停？

docker-compose restart 都等于你去重启 redis 的机器了, 你平常会有事没事重启吗

谁没事重启 docker 里的这俩服务啊

docker-compose 重启的话，一般都是手动需要重启
不可控的情况是更新系统，需要重启 docker 服务，连带着所有 docker 容器都需要重启

不在 docker 里面部署，重启存储服务数据更新也有问题呀。。

重启过程中更新数据失败很正常吧

处理好依赖关系，和容错后重试就可以了，

并且默认情况下关闭容器肯定是 graceful 的

说是部署在 docker 中会有 io 消耗，蹲一个大佬求证

docker 的本质是 overlayfs + cgroup , 这两玩意儿算是久经考验了 , 主要看打镜像的人水平咋样,

可以使用 podman 避免因为重启 docker 导致的某些问题 ( 逃

应用不是也应该写进 compose 里吗，docker compose down 的时候应用应该已经关闭了才对

如果停一会，那这一会里面的数据肯定有问题，但是这和 docker 没关系啊，不在容器内跑 mysql ，把 mysqld 停掉一会一样会有问题

数据库不建议放 docker ，除非数据和稳定性不重要。

docker-compose 都不会常驻运行的，为什么会重启。。。

@xshell 啊？

生产不敢这么玩

我曹，你自己重启了，然后说 redis/mysql 不稳定。。。。你更新应用的时候可以只更新部分应用阿

生产环境存储服务不用 docker 不是共识吗，难道变天了？

如果不是高可用架构，就算不是 Docker 部署，重启数据库实例也会不稳定啊；生产环境的数据肯定不推荐 Docker ，就算是用容器，至少也要保证是高可用架构；一般生产环境上云的话用云厂商的 RDS 服务就好了，测试/开发环境可以用 Docker

谢谢大家的回复，我大概明白了，测试环境无所谓，可以直接丢 docker 里面，生产环境的 DB 最好是单独部署。

服务是否稳定取决于资源调度和数据落盘。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 这样的

缓存和数据库跑在 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 外面。

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

@shijingsijing #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 内存满了机器死机，重启后发现丢了一部分数据，之后就单独部署数据库了。