目录正文1. 不可以容器化 2. 可以容器化 小结正文 在容器化的时代,当然一切皆可容器化。在Docker官网首页赫然有下面这几个大字。足以知道docker的优势。那么且问,Mysql适合跑在docker中吗? 当然
在容器化的时代,当然一切皆可容器化。在Docker官网首页赫然有下面这几个大字。足以知道docker的优势。那么且问,Mysql适合跑在docker中吗?
当然,这个问题有人说可以,也有人说不可以。下面我们就正反都来看下各自的观点。
大部分人的理由有两个:
其一,数据安全性不能保障
在容器或者docker出现故障时,不易恢复。即使使用数据卷挂载(volume)也会在容器故障时产生数据问题,共享的数据卷且对宿主机也会有损伤。即数据的持久化和完整性不能保证。docker适合无状态的服务,不适合有数据状态的mysql。
其二,影响mysql性能
mysql我们常用来读写,那么io性能就会受docker影响,最终瓶颈出现在写(在做了挂载情况下);且如果物理机其他应用占用过多资源,也会影响到容器。
当然,以上的问题,也都有对应的解决方案,但时也足够复杂;对研发力量不足的企业来说,如果盲目容器化的话,可能会捡了芝麻,丢了西瓜。
有的小伙伴就会说了,同样是服务,业务服务都是跑在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化。作为技术人们要拥抱变化,要去踏浪,否则只会被淹没在历史的浪潮里。
以上就是mysql是否需要容器化深入解析的详细内容,更多关于mysql容器化的资料请关注编程网(www.cppcns.com)其它相关文章!
--结束END--
本文标题: mysql是否需要容器化深入分析
本文链接: https://www.lsjlt.com/news/398235.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
下载Word文档到电脑,方便收藏和打印~
2024-05-13
2024-05-13
2024-05-13
2024-05-13
2024-05-12
2024-05-12
2024-05-12
2024-05-12
2024-05-12
2024-05-12
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0