容器的定义：容器是为了处置“在切换运转环境时，如何保证软件可以正常运转”这一成绩。
目前，容器和 Docker 照旧是技术范围最抢手的词语，有形状的效劳容器化曾经是大势所趋，同时也带来了一个热点成绩被大家所争论不已： 数据库 MySQL 能否需求容器化 ？
仔细剖析大家的各种观念，发现赞同者仅仅是沉着器优势的角度来阐述 MySQL 需求容器化，简直没有什么业务场景停止验证本人的观念；反过去再看支持者，他们从功用、数据安全等多个要素停止阐述 MySQL不需求容器化，也举证了一些不适宜的业务场景。
下面，我们就聊一下 Docker 不适宜跑 MySQL 的 N 个缘由！
数据安全成绩不要将数据贮存在容器中，这也是 Docker 官方容器运用技巧中的一条。容器随时可以中止、或许删除。当容器被rm掉，容器里的数据将会丧失。为了避免数据丧失，用户可以运用数据卷挂载来存储数据。但是容器的 Volumes 设计是围绕 Union FS 镜像层提供耐久存储，数据安全缺乏保证。假设容器突然崩溃，数据库未正常封锁，能够会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。
大家都知道，MySQL 属于关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，招致IO瓶颈，大大降低 MySQL 的读写功用。
在一次Docker运用的十大难点专场上，某国有银行的一位架构师也曾提出过：“数据库的功用瓶颈普通出如今IO下面，假设按 Docker 的思绪，那么多个Docker最终IO央求又会出如今存储下面。如今互联网的数据库多是share nothing的架构，能够这也是不思索迁移到 Docker 的一个要素吧”。
其实也有相对应的一些策略来处置这个成绩，比如：
1）数据库顺序与数据别离假设运用Docker 跑 MySQL，数据库顺序与数据需求停止别离，将数据寄存到共享存储，顺序放到容器里。假设容器有异常或 MySQL 效劳异常，自动启动一个全新的容器。另外，建议不要把数据寄存到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比较大。
2）跑轻量级或散布式数据库Docker 里部署轻量级或散布式数据库，Docker 本身就引荐效劳挂掉，自动启动新容器，而不是继续重启容器效劳。
3）合理规划运用关于IO要求比较高的运用或许效劳，将数据库部署在物理机或许KVM中比较适宜。目前腾讯云的TDSQL和阿里的Oceanbase都是直接部署在物理机器，而非Docker 。
形状成绩在 Docker 中水平伸缩只能用于有形状计算效劳，而不是数据库。
Docker 快速扩展的一个重要特征就是有形状，具有数据形状的都不适宜直接放在 Docker 外面，假设 Docker 中安装数据库，存储效劳需求独自提供。
目前，腾讯云的TDSQL（金融散布式数据库）和阿里云的Oceanbase（散布式数据库系统）都直接运转中在物理机器上，并非运用便于管理的 Docker 上。
资源隔离方面，Docker 确实不如虚拟机KVM，Docker是应用Cgroup完成资源限制的，只能限制资源消耗的最大值，而不能隔绝其他顺序占用本人的资源。假设其他运用过渡占用物理机资源，将会影响容器里 MySQL 的读写效率。
需求的隔离级别越多，取得的资源开支就越多。相比公用环境而言，容易水平伸缩是Docker的一大优势。但是在 Docker 中水平伸缩只能用于有形状计算效劳，数据库并不适用。
MySQL 也不是全然不能容器化。以下几种场景还是适宜的。
1） 对数据丧失不敏感的业务 （例如用户搜索商品）就可以数据化，应用数据库分片来来添加实例数，从而添加吞吐量。
2） docker适宜跑轻量级或散布式数据库 ，当docker效劳挂掉，会自动启动新容器，而不是继续重启容器效劳。
3） 数据库应用中间件和容器化系统可以自动伸缩、容灾、切换、自带多个节点 ，也是可以停止容器化的。
典型案例：同程旅游、京东、阿里的数据库容器化都是不错的案例，大家可以自行去查看。
【编辑引荐】
运用 VS Code 在容器中开发
运用 Docker Buildx 构建多种系统架构镜像
为什么我不允许开发人员修正测试环境的MySQL Schema
为什么MySQL不引荐运用子查询和JOIN？
Longhorn，企业级云原生容器散布式存储之监控
(责任编辑：admin)