V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
junwind
V2EX  ›  程序员

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

  •  
  •   junwind · 2024-01-25 13:05:55 +08:00 · 5963 次点击
    这是一个创建于 368 天前的主题,其中的信息可能已经有所发展或是发生改变。

    见题。 比如 docker-compose 重启时。会停掉 mysql ,redis 一会儿,那么此时更新的数据就有问题。

    第 1 条附言  ·  2024-01-25 14:38:16 +08:00
    谢谢大家的回复,我大概明白了,测试环境无所谓,可以直接丢 docker 里面,生产环境的 DB 最好是单独部署。
    40 条回复    2024-01-25 22:08:53 +08:00
    mmdsun
        1
    mmdsun  
       2024-01-25 13:10:00 +08:00
    docker-compose 是不是可以重启指定的服务?重启指定服务数据库\redis 也会暂停?
    seth19960929
        2
    seth19960929  
       2024-01-25 13:16:02 +08:00
    docker-compose restart 都等于你去重启 redis 的机器了, 你平常会有事没事重启吗
    wxw752
        3
    wxw752  
       2024-01-25 13:18:16 +08:00
    谁没事重启 docker 里的这俩服务啊
    ksc010
        4
    ksc010  
       2024-01-25 13:23:57 +08:00
    docker-compose 重启的话,一般都是手动需要重启
    不可控的情况是更新系统,需要重启 docker 服务,连带着所有 docker 容器都需要重启
    MaxFang
        5
    MaxFang  
       2024-01-25 13:25:41 +08:00
    不在 docker 里面部署,重启存储服务数据更新也有问题呀。。
    wqhui
        6
    wqhui  
       2024-01-25 13:28:21 +08:00
    重启过程中更新数据失败很正常吧
    Braisdom
        7
    Braisdom  
       2024-01-25 13:37:09 +08:00
    处理好依赖关系,和容错后重试就可以了,
    qq135449773
        8
    qq135449773  
       2024-01-25 13:43:49 +08:00
    并且默认情况下关闭容器肯定是 graceful 的
    liyunyang
        9
    liyunyang  
       2024-01-25 13:45:36 +08:00
    说是部署在 docker 中会有 io 消耗,蹲一个大佬求证
    ExplodingFKL
        10
    ExplodingFKL  
       2024-01-25 13:49:58 +08:00
    docker 的本质是 overlayfs + cgroup , 这两玩意儿算是久经考验了 , 主要看打镜像的人水平咋样,

    可以使用 podman 避免因为重启 docker 导致的某些问题 ( 逃
    wheat0r
        11
    wheat0r  
       2024-01-25 13:49:59 +08:00
    应用不是也应该写进 compose 里吗,docker compose down 的时候应用应该已经关闭了才对
    liuzhedash
        12
    liuzhedash  
       2024-01-25 13:55:51 +08:00
    如果停一会,那这一会里面的数据肯定有问题,但是这和 docker 没关系啊,不在容器内跑 mysql ,把 mysqld 停掉一会一样会有问题
    xshell
        13
    xshell  
       2024-01-25 13:56:50 +08:00
    数据库不建议放 docker ,除非数据和稳定性不重要。
    cheng6563
        14
    cheng6563  
       2024-01-25 13:57:00 +08:00
    docker-compose 都不会常驻运行的,为什么会重启。。。
    sherlockwhite
        15
    sherlockwhite  
       2024-01-25 14:04:15 +08:00
    @xshell 啊?
    fengpan567
        16
    fengpan567  
       2024-01-25 14:16:11 +08:00
    生产不敢这么玩
    lsk569937453
        17
    lsk569937453  
       2024-01-25 14:24:39 +08:00
    我曹,你自己重启了,然后说 redis/mysql 不稳定。。。。你更新应用的时候可以只更新部分应用阿
    leonhao
        18
    leonhao  
       2024-01-25 14:28:11 +08:00
    生产环境存储服务不用 docker 不是共识吗,难道变天了?
    zedpass
        19
    zedpass  
       2024-01-25 14:28:43 +08:00
    如果不是高可用架构,就算不是 Docker 部署,重启数据库实例也会不稳定啊;生产环境的数据肯定不推荐 Docker ,就算是用容器,至少也要保证是高可用架构;一般生产环境上云的话用云厂商的 RDS 服务就好了,测试/开发环境可以用 Docker
    junwind
        20
    junwind  
    OP
       2024-01-25 14:37:57 +08:00
    谢谢大家的回复,我大概明白了,测试环境无所谓,可以直接丢 docker 里面,生产环境的 DB 最好是单独部署。
    ziwen1943
        21
    ziwen1943  
       2024-01-25 14:40:18 +08:00
    服务是否稳定取决于资源调度和数据落盘。docker 用的资源调度使用的是内核级别的 cgroups ,数据管理用的是 overlayfs 如果不放心,可以直接把服务迁移出来直接用 service 级别的服务。
    nothingistrue
        22
    nothingistrue  
       2024-01-25 14:49:12 +08:00
    docker-compose 只是个命令行集合,压根就不是服务,何来的重启。你要是执行 docker-compose 重启 mysql 容器,那跟你用 mysql 命令重启 mysql 服务是一样的,重启时机不合适谁都出问题,谁也别看不起谁。同样,docker 服务挂了,等同于 linux 主机挂了,谁也别看不起谁。

    但是,docker mysql 容器,绝大多数情况下,是真得不如 linux 上直接的 mysql 服务。原因是很简单,docker 容器改配置真麻烦,你很难得到一个适合的 mysql 镜像。除非你有高超的 shell 脚本能力能自制镜像,否则还是老实的直接用 mysql 。
    wusheng0
        23
    wusheng0  
       2024-01-25 15:11:50 +08:00 via Android
    Redis 不用落盘的话放 docker 也无所谓
    glitter1105
        24
    glitter1105  
       2024-01-25 15:16:33 +08:00   ❤️ 1
    一般生产的数据库不建议使用 docker 容器,还是老老实实使用云服务厂商的 RDS 。
    xuanbg
        25
    xuanbg  
       2024-01-25 15:34:44 +08:00
    一直都放 docker 里面,跑了有 5 年了,没啥不稳定的。
    dululu
        27
    dululu  
       2024-01-25 15:54:48 +08:00
    可以用 k8s ,有公司直接支持 30 多种数据库跑在 k8s 的 docker 里了: https://apecloud.cn/
    thevita
        28
    thevita  
       2024-01-25 16:34:35 +08:00
    我在内部工具平台小规模场景下用 docker host mysql 很多年了,没什么问题.

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

    你裸部一个 mysql 用来做生产问题也很大啊,只是出问题有很多资料帮你解决,所以还是 运服务吧,或者 用 vitess 这样的
    coinbase
        29
    coinbase  
       2024-01-25 16:36:43 +08:00
    懂 op 的意思,有时候先重启 redis ,有时候先重启 mysql ,这样会出现一些问题

    你可以设置 app 的 depends_on

    services:
    app:
    build: .
    depends_on:
    - db
    - redis
    xx6412223
        30
    xx6412223  
       2024-01-25 16:54:29 +08:00
    缓存和数据库跑在 k8s 里没问题。
    ShadowPower
        31
    ShadowPower  
       2024-01-25 17:18:59 +08:00
    单独写一个 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 名字来当作域名互相访问
    sead
        32
    sead  
       2024-01-25 17:33:06 +08:00
    分开两个 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 容器保持在线,前面两个端口升完,这个最后升级。
    这样升级时影响降到最低。
    limaofeng
        33
    limaofeng  
       2024-01-25 17:41:38 +08:00
    单独部署不是也会有你说的问题。去拔掉电源,这时更新不也是有问题。

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

    docker 只是落地手段,k8s 不还是挂 docker 。 难道 k8s 是为了搭建开发环境的。
    不用 docker 和 k8s 这些问题你也要面对。 工具直接简化解决问题的方式
    zx900930
        34
    zx900930  
       2024-01-25 17:55:40 +08:00
    纯 docker compose 管理其实只要备份做好了问题也不大。主要还是分散的 docker 管理比较麻烦。
    最好还是上 k8s 加个 operator 来管理这些东西,这个已经是经过大规模生产考验了的,还在说数据库 redis 不适合进容器的该歇歇了,已经 2024 年了。

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

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


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

    反之如果你的运维工具链全是基于裸金属的,那就全都裸金属。
    zx900930
        35
    zx900930  
       2024-01-25 18:36:09 +08:00   ❤️ 2
    @shijingshijing #26 这篇文章明显是一个 PG dba 的 bias ,而且一看就是没有多少云原生生产经验的
    他甚至都没有提及生产中大量使用的 PGO
    人家从
    监控(pgMonitor)
    备份(pgBackRest)
    高可用
    连接池
    集群克隆
    PostGIS
    升级管理
    都提供了完整的解决方案,全都集成在 Operator 里面了。
    而文章作者还在用裸金属运维工具在运维云原生的东西,然后吐槽一堆 bug 不好用。

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

    一般水平的 dba(指只会备份还原/打打补丁/脚本 boy)都快被 operator 取代了,没理由其它的职业都在 skill up ,就 DBA 不转型吧,一旦他依靠的老东家一垮,出去还能找得到他说的传统 DBA 工作吗?
    IvanLi127
        36
    IvanLi127  
       2024-01-25 19:29:13 +08:00
    如果没用云服务厂商的数据库,也没有自己建集群,我觉得用 docker 跑的风险并不大。大家都是虚拟化,不至于 docker 跑数据库就爱翻车。
    txzh007
        37
    txzh007  
       2024-01-25 19:31:23 +08:00
    库文件和服务分离就行,储存文件夹挂载到主机
    ragnaroks
        38
    ragnaroks  
       2024-01-25 21:50:28 +08:00   ❤️ 1
    如果你的 docker 特指 docker 本身,那确实还是裸机好点。如果你是想说容器这套东西,那我只能说你能想出名字的云厂的 RDS 全部都是容器。
    soclearn
        39
    soclearn  
       2024-01-25 22:05:16 +08:00
    docker 容器很容易挂掉的
    Eished
        40
    Eished  
       2024-01-25 22:08:53 +08:00
    1G 内存服务器+Docker+postgresql 内存满了机器死机,重启后发现丢了一部分数据,之后就单独部署数据库了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1884 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 04:05 · PVG 12:05 · LAX 20:05 · JFK 23:05
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.