为什么不建议把数据库部署在Docker容器内
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
为什么不建议把数据库部署在Docker容器内
21 CTO 1月2日
近2年Docker非常的火热， 各位开发者恨不得把所有的应用、 软件都部署在Docker容器 中， 但是您确定也要把数据库也部署的容器中吗？这个问题不是子虚乌有， 因为在网上能 够找到很多各种操作手册和视频教程， 这里整理了 一 些数据库不适合容器化的原因供大家 参考， 同时也希望大家在使用时能够谨慎 一点。 目前为止将数据库容器化是非常不合理 的， 但是容器化的优点相信各位开发者都尝到了甜头， 希望随着技术的发展能够更加完美 的解决方案出现。 Docker不适合部署数据库的7大原因l、 数据安全问题不要将数据储存在容器中， 这也是 Docker官方容器使用技巧中的一 条。 容器随时可以停止、 或者删除。 当容器被rm掉， 容器 里的数据将会丢失。 为了避免数据丢失， 用户可以使用数据卷挂载来存储数据。 但是容器 的Volumes 设计是围绕Union FS镜像层提供持久存储， 数据安全缺乏保证。 如果容器 突然崩溃， 数据库未正常关闭， 可能会损坏数据。 另外， 容器里共享数据卷组， 对物理机 硬件损伤也比较大。 即使你要把 Docker 数据放在主机来存储 ， 它依然不能保证不丢数 据。 使用当前的存储驱动程序， Docker 仍然存在不可靠的风险。 如果容器崩溃并数据库未 正确关闭， 则可能会损坏数据。 2、 性能问题大家都知道， MySQL属于关系型数据库， 对IO要求较高。 当一 台物理机跑多个 时， IO就会累加， 导致IO瓶颈， 大大降低MySQL的读写性能。 在一 次Docker应用的十大 难点专场上， 某国有银行的一位架构师也曾提出过： “数据库的性能瓶颈一 般出现在IO上
总结针对上面问题是不是说数据库一定不要部署在容器里吗？答案是： 并不是我们可以把 数据丢失不敏感的业务（搜索、 埋点）就可以容器化， 利用数据库分片来来增加实例数， 从而增加吞吐量。 docker适合跑轻量级或分布式数据库， 当docker服务挂掉， 会自动启动 新容器， 而不是继续重启容器服务。 数据库利用中间件和容器化系统能够自动伸缩、 容 灾、 切换、 自带多个节点， 也是可以进行容器化的。
作者： 梅西爱骑车
关千21CTO
心．， ．
足-�-皇-
一－言 ---�-·一Fra bibliotek气息·扈心．，
．
一俨-·--�又-·占玉····�--扈
' •J.. 或于有-··寥
--一了勹－｀＇匕，一
-·一.贰 . 一-···-���--�
6、 云平台的不适用性大部分人通过共有云开始项目。 云简化了虚拟机操作和替换的复杂 性， 因此不需要在夜间或周末没有人工作时间来测试新的硬件环境。 当我们可以迅速启动 一个实例的时候， 为什么我们需要担心这个实例运行的环境？这就是为什么我们向云提供 商支付很多费用的原因。 当我们为实例放置数据库容器时， 上面说的这些便利性就不存在 了。 因为数据不一 致， 新实例不会与老实例兼容， 如果要限制实例使用单机服务， 应该让 DB使用非容器化环境， 我们仅仅需要为计算服务层保留弹性扩展的能力。
7、 运行数据库的环境需求常看到DBMS容器和其他服务运行在同一 主机上。 然而这些服务 对硬件要求是非常不同的。 数据库（特别是关系型数据库）对IO的要求较高。 一 般数据 库引擎为了避免并发资源竞争而使用专用环境。 如果将你的数据库放在容器中， 那么将浪 费你的项目的资源。 因为你需要为该实例配置大量额外的资源。 在公有云， 当你需要34G 内存时， 你启动的实例却必须开64G内存。 在实践中， 这些资源并未完全使用。 怎么解 决？您可以分层设计， 并使用固定资源来启动不同层次的多个实例。 水平伸缩总是比垂直 伸缩更好。
21 CTO 1月2日
近2年Docker非常的火热， 各位开发者恨不得把所有的应用、 软件都部署在Docker容器 中， 但是您确定也要把数据库也部署的容器中吗？这个问题不是子虚乌有， 因为在网上能 够找到很多各种操作手册和视频教程， 这里整理了 一 些数据库不适合容器化的原因供大家 参考， 同时也希望大家在使用时能够谨慎 一点。 目前为止将数据库容器化是非常不合理 的， 但是容器化的优点相信各位开发者都尝到了甜头， 希望随着技术的发展能够更加完美 的解决方案出现。 Docker不适合部署数据库的7大原因l、 数据安全问题不要将数据储存在容器中， 这也是 Docker官方容器使用技巧中的一 条。 容器随时可以停止、 或者删除。 当容器被rm掉， 容器 里的数据将会丢失。 为了避免数据丢失， 用户可以使用数据卷挂载来存储数据。 但是容器 的Volumes 设计是围绕Union FS镜像层提供持久存储， 数据安全缺乏保证。 如果容器 突然崩溃， 数据库未正常关闭， 可能会损坏数据。 另外， 容器里共享数据卷组， 对物理机 硬件损伤也比较大。 即使你要把 Docker 数据放在主机来存储 ， 它依然不能保证不丢数 据。 使用当前的存储驱动程序， Docker 仍然存在不可靠的风险。 如果容器崩溃并数据库未 正确关闭， 则可能会损坏数据。 2、 性能问题大家都知道， MySQL属于关系型数据库， 对IO要求较高。 当一 台物理机跑多个 时， IO就会累加， 导致IO瓶颈， 大大降低MySQL的读写性能。 在一 次Docker应用的十大 难点专场上， 某国有银行的一位架构师也曾提出过： “数据库的性能瓶颈一 般出现在IO上
总结针对上面问题是不是说数据库一定不要部署在容器里吗？答案是： 并不是我们可以把 数据丢失不敏感的业务（搜索、 埋点）就可以容器化， 利用数据库分片来来增加实例数， 从而增加吞吐量。 docker适合跑轻量级或分布式数据库， 当docker服务挂掉， 会自动启动 新容器， 而不是继续重启容器服务。 数据库利用中间件和容器化系统能够自动伸缩、 容 灾、 切换、 自带多个节点， 也是可以进行容器化的。
作者： 梅西爱骑车
关千21CTO
心．， ．
足-�-皇-
一－言 ---�-·一Fra bibliotek气息·扈心．，
．
一俨-·--�又-·占玉····�--扈
' •J.. 或于有-··寥
--一了勹－｀＇匕，一
-·一.贰 . 一-···-���--�
6、 云平台的不适用性大部分人通过共有云开始项目。 云简化了虚拟机操作和替换的复杂 性， 因此不需要在夜间或周末没有人工作时间来测试新的硬件环境。 当我们可以迅速启动 一个实例的时候， 为什么我们需要担心这个实例运行的环境？这就是为什么我们向云提供 商支付很多费用的原因。 当我们为实例放置数据库容器时， 上面说的这些便利性就不存在 了。 因为数据不一 致， 新实例不会与老实例兼容， 如果要限制实例使用单机服务， 应该让 DB使用非容器化环境， 我们仅仅需要为计算服务层保留弹性扩展的能力。
7、 运行数据库的环境需求常看到DBMS容器和其他服务运行在同一 主机上。 然而这些服务 对硬件要求是非常不同的。 数据库（特别是关系型数据库）对IO的要求较高。 一 般数据 库引擎为了避免并发资源竞争而使用专用环境。 如果将你的数据库放在容器中， 那么将浪 费你的项目的资源。 因为你需要为该实例配置大量额外的资源。 在公有云， 当你需要34G 内存时， 你启动的实例却必须开64G内存。 在实践中， 这些资源并未完全使用。 怎么解 决？您可以分层设计， 并使用固定资源来启动不同层次的多个实例。 水平伸缩总是比垂直 伸缩更好。