为什么不建议将数据库部署于Docker上？

建议将数据库部署于Docker上？"/>

为什么不建议将数据库部署于Docker上？

Docker 不适合部署数据库的七大原因

1.数据安全问题

不要将数据存储在容器中，这是Docker官方容器使用技巧中的一条。容器可以随时关闭、删除或停止，因此当容器被rm掉，里面的数据将会丢失。为了避免数据丢失，用户可使用数据卷挂载来存储数据。但是容器的Volumes设计围绕Union FS镜像层提供持久存储，数据安全缺乏保证。而且容器里共享数据卷组，对物理机硬件损伤较大。总之，如果容器崩溃，数据库未正常关闭，则可能会损伤数据。

2.性能问题

像关系型数据库MySQL，它对于IO要求比较高。当一台物理机跑多个数据库时，IO就会累加，导致IO瓶颈，大大降低MySQL的读写性能。如果部署在Docker上，那么IO请求又会出现在存储层面。

针对以上问题的解决方案：

1）数据库程序与数据分离---将程序放到容器，将数据放到共享存储。另外，建议不要将数据放到宿主机里。

2）Doker里面部署轻量级或者分布式数据库

3）合理布局应用---对IO要求高的应用或服务，将数据库部署在物理机或者KVM中。像腾讯云的TDSQL（金融分布式数据库）和阿里云的Oceanbase（分布式数据库系统）就是直接部署在物理机上的。

3.网络问题

Docker存在网络问题,而数据库需要专用的和持久的吞吐量，以实现更高负载，而解决Doker网路问题需要对网络虚拟化有着深入了解，这些问题放在一起，因此容器化会让数据库容器更加困难，所以建议将数据库放在专用环境中。

4.状态

Docker中，水平伸缩只能是用于无状态计算服务，而数据库是具有数据状态的，因此，具有数据状态的都不适合直接放在Docker里面。

5.资源隔离

在资源隔离层面，Docker不如KVM，它是利用Cgroup实现资源限制，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。如果其他应用过度占用物理机资源部，将会影响MYSOL的读写效率。

6.云平台的不适用性

云简化了虚拟机操作和替换的复杂性，不需要在夜间或者周末这些没有人工作的时间内测试新的硬件环境。而且我们可以迅速启动一个新的实例而不需要考虑这个实例的运行环境。而当我们将实例放置于数据库容器时，因为数据不一致，新的实例将不会和老实例兼容，上面所说的云平台的便利性将不复存在。

7.运行数据库的环境需求

DBMS容器和其他服务对硬件的要求是不同的。特别是数据库中的关系型数据库对IO要求较高。一般数据库引擎为了避免并发资源竞争而使用专用环境，而当你将数据库放入容器中，那么你将浪费你的项目资源。因为你需要为该实例配置大量额外资源。在公有云中，当你需要34G内存时，你启动的实例却必须为64G。在实践中，这些资源并未完全利用。所以你可以分层设计，并使用固定资源启动不同层次的多实例。水平伸缩总是比垂直伸缩更好。

结语：

综上，数据库不适合部署在容器上。但这并不意味这它不能部署于容器。我们可以把数据丢失、不敏感的业务（搜索、埋点）容器化，利用数据库分片来增加实例数，从而增加吞吐量。

docker适合跑轻量级或分布式数据库，当docker服务挂掉，会启动心得容器，而不是继续重启容器服务。数据库利用中间件和容器化系统能够自动伸缩、容灾、切换、自带多个节点，所以说也是能够进行容器化的。