关于mysql:mysql到底需不需要容器化

2次阅读

共计 1615 个字符，预计需要花费 5 分钟才能阅读完成。

在容器化的时代，当然所有皆可容器化。在 docker 官网首页赫然有上面这几个大字。足以晓得 docker 的劣势。那么且问，mysql 适宜跑在 docker 中吗?

当然，这个问题有人说能够，也有人说不能够。上面咱们就正反都来看下各自的观点。

1. 不能够容器化

大部分人的理由有两个：

其一，数据安全性不能保障

在容器或者 docker 呈现故障时，不易复原。即便应用数据卷挂载（volume）也会在容器故障时产生数据问题，共享的数据卷且对宿主机也会有伤害。即数据的长久化和完整性不能保障。docker 适宜无状态的服务，不适宜有数据状态的 mysql。

其二，影响 mysql 性能

mysql 咱们罕用来读写，那么 IO 性能就会受 docker 影响，最终瓶颈呈现在写（在做了挂载状况下）；且如果物理机其余利用占用过多资源，也会影响到容器。

当然，以上的问题，也都有对应的解决方案，但时也足够简单；对研发力量有余的企业来说，如果自觉容器化的话，可能会捡了芝麻，丢了西瓜。

2. 能够容器化

有的小伙伴就会说了，同样是服务，业务服务都是跑在 docker 中的，数据库服务有何不可？

我只有配置下数据卷挂载，解决掉数据长久化问题，基本上就问题不大了。

比方：

docker run -p 3306:3306 --name mysql 
-v /mydata/mysql/log:/var/log/mysql 
-v /mydata/mysql/data:/var/lib/mysql 
-v /mydata/mysql/conf:/etc/mysql
-e TZ=Asia/Shanghai -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7

亦或是 docker 官网给的 mysql 容器化的配置 sample

services:
  backend:
    build: backend
    ports:
      - 8080:8080
    secrets:
      - db-password
  db:
    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    restart: always
    secrets:
      - db-password
    volumes:
      - db-data:/var/lib/mysql
    environment:
      - MYSQL_DATABASE=example
      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db-password
    expose:
      - 3306
      - 33060   
volumes:
  db-data:
secrets:
  db-password:
    file: db/password.txt

两个例子都是通过 - v 把 mysql 相干目录数据做好挂载，那么在容器呈现故障或者被删除时，可能保障相干数据在宿主机中存在。让数据恢复成为了可能性。留神！是可能性

当然还有 docker 人造的劣势：

简化部署，可移植性高
保障环境一致性

这两个劣势就足以促使很多人去做容器化部署。（预计大家都被手动部署，迁徙，多环境问题搞得头大过）

小结

在我看来，两种观点或者是叫两种计划没有对错。也不应该有争执。而应该捕风捉影，依据以后的业务倒退，研发力量来决策。如果没有那个技术力量，就老老实实部署在物理机上，老本和危险更小。只是“万事开头难”而已。如果有实力，有技术，那么须要设计出一个好的架构计划；比方须要思考镜像治理，监控，容器灾备，存储扩大，k8s 等。技术的潮流肯定是容器化，serverless 化。作为技术人们要拥抱变动，要去踏浪，否则只会被吞没在历史的浪潮里。

正文完