爲何不建議把數據庫部署在Docker容器內

近2年Docker很是的火熱，各位開發者巴不得把全部的應用、軟件都部署在Docker容器中，可是您肯定也要把數據庫也部署的容器中嗎？這個問題不是子虛烏有，由於在網上可以找到不少各類操做手冊和視頻教程，這裏整理了一些數據庫不適合容器化的緣由供你們參考，同時也但願你們在使用時可以謹慎一點。目前爲止將數據庫容器化是很是不合理的，可是容器化的優勢相信各位開發者都嚐到了甜頭，但願隨着技術的發展可以更加完美的解決方案出現。

Docker不適合部署數據庫的7大緣由

一、數據安全問題

不要將數據儲存在容器中，這也是 Docker 官方容器使用技巧中的一條。容器隨時能夠中止、或者刪除。當容器被rm掉，容器裏的數據將會丟失。爲了不數據丟失，用戶可使用數據卷掛載來存儲數據。可是容器的 Volumes 設計是圍繞 Union FS 鏡像層提供持久存儲，數據安全缺少保證。若是容器忽然崩潰，數據庫未正常關閉，可能會損壞數據。另外，容器裏共享數據卷組，對物理機硬件損傷也比較大。即便你要把 Docker 數據放在主機來存儲 ，它依然不能保證不丟數據。使用當前的存儲驅動程序，Docker 仍然存在不可靠的風險。若是容器崩潰並數據庫未正確關閉，則可能會損壞數據。

二、性能問題

你們都知道，MySQL 屬於關係型數據庫，對IO要求較高。當一臺物理機跑多個時，IO就會累加，致使IO瓶頸，大大下降 MySQL 的讀寫性能。在一次Docker應用的十大難點專場上，某國有銀行的一位架構師也曾提出過：「數據庫的性能瓶頸通常出如今IO上面，若是按 Docker 的思路，那麼多個docker最終IO請求又會出如今存儲上面。如今互聯網的數據庫可能是share nothing的架構，可能這也是不考慮遷移到 Docker 的一個因素吧」。

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

(1)數據庫程序與數據分離

若是使用Docker 跑 MySQL，數據庫程序與數據須要進行分離，將數據存放到共享存儲，程序放到容器裏。若是容器有異常或 MySQL 服務異常，自動啓動一個全新的容器。另外，建議不要把數據存放到宿主機裏，宿主機和容器共享卷組，對宿主機損壞的影響比較大。

(2)跑輕量級或分佈式數據庫　

Docker 裏部署輕量級或分佈式數據庫，Docker 自己就推薦服務掛掉，自動啓動新容器，而不是繼續重啓容器服務。

(3)合理佈局應用

對於IO要求比較高的應用或者服務，將數據庫部署在物理機或者KVM中比較合適。目前TX雲的TDSQL和阿里的Oceanbase都是直接部署在物理機器，而非Docker 。

三、網絡問題

要理解 Docker 網絡，您必須對網絡虛擬化有深刻的瞭解。數據庫須要專用的和持久的吞吐量，以實現更高的負載。未解決的 Docker 網絡問題在1.9版本依然沒有獲得解決。把這些問題放在一塊兒，容器化使數據庫容器很難管理。你須要花多少時間解決 Docker 網絡問題？將數據庫放在專用環境不會更好嗎？節省時間來專一於真正重要的業務目標。

四、狀態

在 Docker 中打包無狀態服務是很酷的，能夠實現編排容器並解決單點故障問題。可是數據庫呢？將數據庫放在同一個環境中，它將會是有狀態的，並使系統故障的範圍更大。下次您的應用程序實例或應用程序崩潰，可能會影響數據庫。知識點:在 Docker 中水平伸縮只能用於無狀態計算服務，而不是數據庫。Docker 快速擴展的一個重要特徵就是無狀態，具備數據狀態的都不適合直接放在 Docker 裏面，若是 Docker 中安裝數據庫，存儲服務須要單獨提供。目前，TX雲的TDSQL(金融分佈式數據庫)和阿里雲的Oceanbase(分佈式數據庫系統)都直接運行中在物理機器上，並不是使用便於管理的 Docker 上。

五、資源隔離

資源隔離方面，Docker 確實不如虛擬機KVM，Docker是利用Cgroup實現資源限制的，只能限制資源消耗的最大值，而不能隔絕其餘程序佔用本身的資源。若是其餘應用過渡佔用物理機資源，將會影響容器裏 MySQL 的讀寫效率。須要的隔離級別越多，得到的資源開銷就越多。相比專用環境而言，容易水平伸縮是Docker的一大優點。然而在 Docker 中水平伸縮只能用於無狀態計算服務，數據庫並不適用。咱們沒有看到任何針對數據庫的隔離功能，那爲何咱們應該把它放在容器中呢？

六、雲平臺的不適用性

大部分人經過共有云開始項目。雲簡化了虛擬機操做和替換的複雜性，所以不須要在夜間或週末沒有人工做時間來測試新的硬件環境。當咱們能夠迅速啓動一個實例的時候，爲何咱們須要擔憂這個實例運行的環境？這就是爲何咱們向雲提供商支付不少費用的緣由。當咱們爲實例放置數據庫容器時，上面說的這些便利性就不存在了。由於數據不一致，新實例不會與老實例兼容，若是要限制實例使用單機服務，應該讓 DB 使用非容器化環境，咱們僅僅須要爲計算服務層保留彈性擴展的能力。

七、運行數據庫的環境需求

常看到 DBMS 容器和其餘服務運行在同一主機上。然而這些服務對硬件要求是很是不一樣的。數據庫（特別是關係型數據庫）對 IO 的要求較高。通常數據庫引擎爲了不併發資源競爭而使用專用環境。若是將你的數據庫放在容器中，那麼將浪費你的項目的資源。由於你須要爲該實例配置大量額外的資源。在公有云，當你須要 34G 內存時，你啓動的實例卻必須開 64G 內存。在實踐中，這些資源並未徹底使用。怎麼解決？您能夠分層設計，並使用固定資源來啓動不一樣層次的多個實例。水平伸縮老是比垂直伸縮更好。

總結

針對上面問題是否是說數據庫必定不要部署在容器裏嗎？答案是：並非咱們能夠把數據丟失不敏感的業務（搜索、埋點）就能夠容器化，利用數據庫分片來來增長實例數，從而增長吞吐量。docker適合跑輕量級或分佈式數據庫，當docker服務掛掉，會自動啓動新容器，而不是繼續重啓容器服務。數據庫利用中間件和容器化系統可以自動伸縮、容災、切換、自帶多個節點，也是能夠進行容器化的。

原文連接：http://l.wz2.in/0AC做者：梅西愛騎車