容器的界说：容器是为了处理“在切换运转环境时，怎么确保软件能够正常运转”这一问题。
现在，容器和 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 的一个要素吧”。
假如运用Docker 跑 MySQL，数据库程序与数据需求进行别离，将数据存放到同享存储，程序放到容器里。假如容器有反常或 MySQL 服务反常，主动发动一个全新的容器。别的，主张不要把数据存放到宿主机里，宿主机和容器同享卷组，对宿主机损坏的影响比较大。
Docker 里布置轻量级或分布式数据库，Docker 自身就引荐服务挂掉，主动发动新容器，而不是持续重启容器服务。
关于IO要求比较高的运用或许服务，将数据库布置在物理机或许KVM中比较适宜。现在腾讯云的TDSQL和阿里的Oceanbase都是直接布置在物理机器，而非Docker 。
Docker 快速扩展的一个重要特征便是无状况，具有数据状况的都不合适直接放在 Docker 里边，假如 Docker 中装置数据库，存储服务需求独自供给。
现在，腾讯云的TDSQL（金融分布式数据库）和阿里云的Oceanbase（分布式数据库体系）都直接运转中在物理机器上，并非运用便于管理的 Docker 上。
资源阻隔方面，Docker 的确不如虚拟机KVM，Docker是使用Cgroup完成资源约束的，只能约束资源耗费的最大值，而不能阻隔其他程序占用自己的资源。假如其他运用过渡占用物理机资源，将会影响容器里 MySQL 的读写功率。
需求的阻隔等级越多，取得的资源开支就越多。比较专用环境而言，简单水平弹性是Docker的一大优势。然而在 Docker 中水平弹性只能用于无状况核算服务，数据库并不适用。
1）对数据丢掉不灵敏的事务（例如用户查找产品）就能够数据化，使用数据库分片来来添加实例数，然后添加吞吐量。
2）docker合适跑轻量级或分布式数据库，当docker服务挂掉，会主动发动新容器，而不是持续重启容器服务。
3）数据库使用中间件和容器化体系能够主动弹性、容灾、切换、自带多个节点，也是能够进行容器化的。
典型事例：同程旅行、京东、阿里的数据库容器化都是不错的事例，咱们能够自行去检查。