近 2 年 Docker 非常的火熱，各位開發者恨不得把所有的應用、軟件都部署在 Docker 容器中，但是您確定也要把數據庫也部署的容器中嗎?

這個問題不是子虛烏有，因為在網上能夠找到很多各種操作手冊和視頻教程，這里整理了一些數據庫不適合容器化的原因供大家參考，同時也希望大家在使用時能夠謹慎一點。

目前為止將數據庫容器化是非常不合理的，但是容器化的優點相信各位開發者都嘗到了甜頭，希望隨著技術的發展能夠更加完美的解決方案出現。

接下來，我們來討論一下 Docker 不適合部署數據庫的七大原因：

1.數據安全問題

不要將數據儲存在容器中，這也是 Docker 官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。

當容器被 rm 掉，容器里的數據將會丟失。為了避免數據丟失，用戶可以使用數據卷掛載來存儲數據。

但是容器的 Volumes 設計是圍繞 Union FS 鏡像層提供持久存儲，數據安全缺乏保證。如果容器突然崩潰，數據庫未正常關閉，可能會損壞數據。

另外，容器里共享數據卷組，對物理機硬件損傷也比較大。即使你要把 Docker 數據放在主機來存儲 ，它依然不能保證不丟數據。

使用當前的存儲驅動程序，Docker 仍然存在不可靠的風險。如果容器崩潰并數據庫未正確關閉，則可能會損壞數據。

2.性能問題

大家都知道，MySQL 屬于關系型數據庫，對 IO 要求較高。當一臺物理機跑多個時，IO 就會累加，導致 IO 瓶頸，大大降低 MySQL 的讀寫性能。

在一次 Docker 應用的十大難點專場上，某國有銀行的一位架構師也曾提出過：“數據庫的性能瓶頸一般出現在 IO 上面，如果按 Docker 的思路，那么多個 Docker 最終 IO 請求又會出現在存儲上面。現在互聯網的數據庫多是 share nothing 的架構，可能這也是不考慮遷移到 Docker 的一個因素吧”。

針對性能問題有些同學可能也有相對應的方案來解決：

①數據庫程序與數據分離

如果使用 Docker 跑 MySQL，數據庫程序與數據需要進行分離，將數據存放到共享存儲，程序放到容器里。如果容器有異常或 MySQL 服務異常，自動啟動一個全新的容器。

另外，建議不要把數據存放到宿主機里，宿主機和容器共享卷組，對宿主機損壞的影響比較大。

②跑輕量級或分布式數據庫

Docker 里部署輕量級或分布式數據庫，Docker 本身就推薦服務掛掉，自動啟動新容器，而不是繼續重啟容器服務。

③合理布局應用

對于 IO 要求比較高的應用或者服務，將數據庫部署在物理機或者 KVM 中比較合適。

目前 TX 云的 TDSQL 和阿里的 Oceanbase 都是直接部署在物理機器，而非 Docker 。

3.網絡問題

要理解 Docker 網絡，您必須對網絡虛擬化有深入的了解。數據庫需要專用的和持久的吞吐量，以實現更高的負載。

未解決的 Docker 網絡問題在 1.9 版本依然沒有得到解決。把這些問題放在一起，容器化使數據庫容器很難管理。

你需要花多少時間解決 Docker 網絡問題?將數據庫放在專用環境不會更好嗎?節省時間來專注于真正重要的業務目標。

4.狀態

在 Docker 中打包無狀態服務是很酷的，可以實現編排容器并解決單點故障問題。

但是數據庫呢?將數據庫放在同一個環境中，它將會是有狀態的，并使系統故障的范圍更大。下次您的應用程序實例或應用程序崩潰，可能會影響數據庫。

知識點：在 Docker 中水平伸縮只能用于無狀態計算服務，而不是數據庫。

Docker 快速擴展的一個重要特征就是無狀態，具有數據狀態的都不適合直接放在 Docker 里面，如果 Docker 中安裝數據庫，存儲服務需要單獨提供。

目前，TX 云的(金融分布式數據庫)和阿里云的 Oceanbase(分布式數據庫系統)都直接運行中在物理機器上，并非使用便于管理的 Docker 上。

5.資源隔離

資源隔離方面，Docker 確實不如虛擬機 KVM，Docker 是利用 Cgroup 實現資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程序占用自己的資源。

如果其他應用過渡占用物理機資源，將會影響容器里 MySQL 的讀寫效率。需要的隔離級別越多，獲得的資源開銷就越多。

相比專用環境而言，容易水平伸縮是 Docker 的一大優勢。然而在 Docker 中水平伸縮只能用于無狀態計算服務，數據庫并不適用。

我們沒有看到任何針對數據庫的隔離功能，那為什么我們應該把它放在容器中呢?

6.云平臺的不適用性

大部分人通過共有云開始項目。云簡化了虛擬機操作和替換的復雜性，因此不需要在夜間或周末沒有人工作時間來測試新的硬件環境。

當我們可以迅速啟動一個實例的時候，為什么我們需要擔心這個實例運行的環境?

這就是為什么我們向云提供商支付很多費用的原因。當我們為實例放置數據庫容器時，上面說的這些便利性就不存在了。

因為數據不一致，新實例不會與老實例兼容，如果要限制實例使用單機服務，應該讓 DB 使用非容器化環境，我們僅僅需要為計算服務層保留彈性擴展的能力。

7.運行數據庫的環境需求

常看到 DBMS 容器和其他服務運行在同一主機上。然而這些服務對硬件要求是非常不同的。

數據庫(特別是關系型數據庫)對 IO 的要求較高。一般數據庫引擎為了避免并發資源競爭而使用專用環境。

如果將你的數據庫放在容器中，那么將浪費你的項目的資源。因為你需要為該實例配置大量額外的資源。

在公有云，當你需要 34G 內存時，你啟動的實例卻必須開 64G 內存。在實踐中，這些資源并未完全使用。

怎么解決?您可以分層設計，并使用固定資源來啟動不同層次的多個實例。水平伸縮總是比垂直伸縮更好。

8.總結

針對上面問題是不是說數據庫一定不要部署在容器里嗎?

答案是：并不是我們可以把數據丟失不敏感的業務(搜索、埋點)就可以容器化，利用數據庫分片來來增加實例數，從而增加吞吐量。

Docker 適合跑輕量級或分布式數據庫，當 Docker 服務掛掉，會自動啟動新容器，而不是繼續重啟容器服務。

數據庫利用中間件和容器化系統能夠自動伸縮、容災、切換、自帶多個節點，也是可以進行容器化的。

總結

以上是生活随笔為你收集整理的不建议在Docker中部署数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。