这是一个创建于 312 天前的主题，其中的信息可能已经有所发展或是发生改变。
见题。 比如 docker-compose 重启时。会停掉 mysql ，redis 一会儿，那么此时更新的数据就有问题。
第 1 条附言 · 312 天前
谢谢大家的回复，我大概明白了，测试环境无所谓，可以直接丢 docker 里面，生产环境的 DB 最好是单独部署。
 |
1
mmdsun 312 天前
docker-compose 是不是可以重启指定的服务？重启指定服务数据库\redis 也会暂停？
|
 |
2
seth19960929 312 天前
docker-compose restart 都等于你去重启 redis 的机器了, 你平常会有事没事重启吗
|
 |
3
wxw752 312 天前
谁没事重启 docker 里的这俩服务啊
|
 |
4
ksc010 312 天前
docker-compose 重启的话，一般都是手动需要重启
不可控的情况是更新系统，需要重启 docker 服务，连带着所有 docker 容器都需要重启 |
 |
5
MaxFang 312 天前
不在 docker 里面部署，重启存储服务数据更新也有问题呀。。
|
 |
6
wqhui 312 天前
重启过程中更新数据失败很正常吧
|
 |
7
Braisdom 312 天前
处理好依赖关系，和容错后重试就可以了，
|
 |
8
qq135449773 312 天前
并且默认情况下关闭容器肯定是 graceful 的
|
 |
9
liyunyang 312 天前
说是部署在 docker 中会有 io 消耗，蹲一个大佬求证
|
 |
10
ExplodingFKL 312 天前
docker 的本质是 overlayfs + cgroup , 这两玩意儿算是久经考验了 , 主要看打镜像的人水平咋样,
可以使用 podman 避免因为重启 docker 导致的某些问题 ( 逃 |
 |
11
wheat0r 312 天前
应用不是也应该写进 compose 里吗，docker compose down 的时候应用应该已经关闭了才对
|
 |
12
liuzhedash 312 天前
如果停一会，那这一会里面的数据肯定有问题，但是这和 docker 没关系啊，不在容器内跑 mysql ，把 mysqld 停掉一会一样会有问题
|
 |
13
xshell 312 天前
数据库不建议放 docker ，除非数据和稳定性不重要。
|
 |
14
cheng6563 312 天前
docker-compose 都不会常驻运行的，为什么会重启。。。
|
 |
15
sherlockwhite 312 天前
@xshell 啊？
|
 |
16
fengpan567 312 天前
生产不敢这么玩
|
 |
17
lsk569937453 312 天前
我曹，你自己重启了，然后说 redis/mysql 不稳定。。。。你更新应用的时候可以只更新部分应用阿
|
 |
18
leonhao 312 天前
生产环境存储服务不用 docker 不是共识吗，难道变天了？
|
 |
19
zedpass 312 天前
如果不是高可用架构，就算不是 Docker 部署，重启数据库实例也会不稳定啊；生产环境的数据肯定不推荐 Docker ，就算是用容器，至少也要保证是高可用架构；一般生产环境上云的话用云厂商的 RDS 服务就好了，测试/开发环境可以用 Docker
|
 |
20
junwind OP 谢谢大家的回复，我大概明白了，测试环境无所谓，可以直接丢 docker 里面，生产环境的 DB 最好是单独部署。
|
 |
21
ziwen1943 312 天前
服务是否稳定取决于资源调度和数据落盘。docker 用的资源调度使用的是内核级别的 cgroups ，数据管理用的是 overlayfs 如果不放心，可以直接把服务迁移出来直接用 service 级别的服务。
|
 |
22
nothingistrue 312 天前
docker-compose 只是个命令行集合，压根就不是服务，何来的重启。你要是执行 docker-compose 重启 mysql 容器，那跟你用 mysql 命令重启 mysql 服务是一样的，重启时机不合适谁都出问题，谁也别看不起谁。同样，docker 服务挂了，等同于 linux 主机挂了，谁也别看不起谁。
但是，docker mysql 容器，绝大多数情况下，是真得不如 linux 上直接的 mysql 服务。原因是很简单，docker 容器改配置真麻烦，你很难得到一个适合的 mysql 镜像。除非你有高超的 shell 脚本能力能自制镜像，否则还是老实的直接用 mysql 。 |
 |
23
wusheng0 312 天前 via Android
Redis 不用落盘的话放 docker 也无所谓
|
 |
24
glitterzhong 312 天前  1
一般生产的数据库不建议使用 docker 容器，还是老老实实使用云服务厂商的 RDS 。
|
 |
25
xuanbg 312 天前
一直都放 docker 里面，跑了有 5 年了，没啥不稳定的。
|
 |
26
shijingshijing 312 天前
|
 |
27
dululu 312 天前
可以用 k8s ，有公司直接支持 30 多种数据库跑在 k8s 的 docker 里了： https://apecloud.cn/
|
 |
28
thevita 312 天前
我在内部工具平台小规模场景下用 docker host mysql 很多年了，没什么问题.
至于说 生产环境 DB, 的问题主要还是运维的复杂度，但这个问题不是 docker 带来的，你独立部署也会带来一样的问题啊，只是 仅仅一个 docker 给你运维这种服务没有什么帮助，甚至由于与既有运维工具链的兼容配合问题，会更加复杂和麻烦. 你裸部一个 mysql 用来做生产问题也很大啊，只是出问题有很多资料帮你解决，所以还是 运服务吧，或者 用 vitess 这样的 |
 |
29
coinbase 312 天前
懂 op 的意思，有时候先重启 redis ，有时候先重启 mysql ，这样会出现一些问题
你可以设置 app 的 depends_on services: app: build: . depends_on: - db - redis |
 |
30
xx6412223 312 天前
缓存和数据库跑在 k8s 里没问题。
|
 |
31
ShadowPower 312 天前
单独写一个 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 名字来当作域名互相访问 |
 |
32
sead 312 天前
分开两个 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 容器保持在线，前面两个端口升完，这个最后升级。 这样升级时影响降到最低。 |
 |
33
limaofeng 312 天前
单独部署不是也会有你说的问题。去拔掉电源，这时更新不也是有问题。
1. 应该考虑的是应用服务器与数据服务器是否应该分离 2. 数据库是否应该高可用，集群部署 docker 只是落地手段，k8s 不还是挂 docker 。 难道 k8s 是为了搭建开发环境的。 不用 docker 和 k8s 这些问题你也要面对。 工具直接简化解决问题的方式 |
 |
34
zx900930 312 天前
纯 docker compose 管理其实只要备份做好了问题也不大。主要还是分散的 docker 管理比较麻烦。
最好还是上 k8s 加个 operator 来管理这些东西，这个已经是经过大规模生产考验了的，还在说数据库 redis 不适合进容器的该歇歇了，已经 2024 年了。 k8s 可以在 1 分钟之内拉起一个 mysql/redis 集群并且由对应的 operator 实时监控状态主从切换，备份可以用 Percona XtraBackup 实时热备，并且对应负载均衡和 ingress 乃至监控的接入都可以同时生成。 一切的操作只需要你修改一下 chart ，改一改 crd 或者 configmap 参数，就可以大规模复制。 换成 linux 裸机，用 playbook 自动安装部署花的时间一般会更长，除非专门优化过。 如果你的业务全都容器化了，运维工具全是云原生的，那么没有理由让数据库和缓存单独孤立在 k8s 外面。 反之如果你的运维工具链全是基于裸金属的，那就全都裸金属。 |
|
35
zx900930 312 天前 2
@shijingshijing #26 这篇文章明显是一个 PG dba 的 bias ，而且一看就是没有多少云原生生产经验的
他甚至都没有提及生产中大量使用的 PGO 人家从 监控(pgMonitor) 备份(pgBackRest) 高可用 连接池 集群克隆 PostGIS 升级管理 都提供了完整的解决方案，全都集成在 Operator 里面了。 而文章作者还在用裸金属运维工具在运维云原生的东西，然后吐槽一堆 bug 不好用。 更不用说 op 这里提到的还是相比 pg 云原生更成熟的 mysql/redis 。 一般水平的 dba(指只会备份还原/打打补丁/脚本 boy)都快被 operator 取代了，没理由其它的职业都在 skill up ，就 DBA 不转型吧，一旦他依靠的老东家一垮，出去还能找得到他说的传统 DBA 工作吗？ |
 |
36
IvanLi127 312 天前
如果没用云服务厂商的数据库，也没有自己建集群，我觉得用 docker 跑的风险并不大。大家都是虚拟化，不至于 docker 跑数据库就爱翻车。
|
 |
37
txzh007 312 天前
库文件和服务分离就行,储存文件夹挂载到主机
|
 |
38
ragnaroks 312 天前 1
如果你的 docker 特指 docker 本身，那确实还是裸机好点。如果你是想说容器这套东西，那我只能说你能想出名字的云厂的 RDS 全部都是容器。
|
 |
39
soclearn 312 天前
docker 容器很容易挂掉的
|
 |
40
Eished 312 天前
1G 内存服务器+Docker+postgresql 内存满了机器死机，重启后发现丢了一部分数据，之后就单独部署数据库了。
|
Select Language