為什麼不建議把資料庫部署在Docker容器內?

2021-10-17 07:43:11 字數 2411 閱讀 5130

docker不適合部署資料庫的7大原因

1、資料安全問題

不要將資料儲存在容器中,這也是 docker 官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。當容器被rm掉,容器裡的資料將會丟失。為了避免資料丟失,使用者可以使用資料卷掛載來儲存資料。但是容器的 volumes 設計是圍繞 union fs 映象層提供持久儲存,資料安全缺乏保證。如果容器突然崩潰,資料庫未正常關閉,可能會損壞資料。另外,容器裡共享資料捲組,對物理機硬體損傷也比較大。即使你要把 docker 資料放在主機來儲存 ,它依然不能保證不丟資料。使用當前的儲存驅動程式,docker 仍然存在不可靠的風險。如果容器崩潰並資料庫未正確關閉,則可能會損壞資料。

2、效能問題

大家都知道,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 。

3、網路問題

要理解 docker 網路,您必須對網路虛擬化有深入的了解。資料庫需要專用的和持久的吞吐量,以實現更高的負載。未解決的 docker 網路問題在1.9版本依然沒有得到解決。把這些問題放在一起,容器化使資料庫容器很難管理。你需要花多少時間解決 docker 網路問題?將資料庫放在專用環境不會更好嗎?節省時間來專注於真正重要的業務目標。

4、狀態

在 docker 中打包無狀態服務是很酷的,可以實現編排容器並解決單點故障問題。但是資料庫呢?將資料庫放在同乙個環境中,它將會是有狀態的,並使系統故障的範圍更大。下次您的應用程式例項或應用程式崩潰,可能會影響資料庫。知識點:在 docker 中水平伸縮只能用於無狀態計算服務,而不是資料庫。docker 快速擴充套件的乙個重要特徵就是無狀態,具有資料狀態的都不適合直接放在 docker 裡面,如果 docker 中安裝資料庫,儲存服務需要單獨提供。目前,tx雲的tdsql(金融分布式資料庫)和阿里雲的oceanbase(分布式資料庫系統)都直接執行中在物理機器上,並非使用便於管理的 docker 上。

5、資源隔離

資源隔離方面,docker 確實不如虛擬機器kvm,docker是利用cgroup實現資源限制的,只能限制資源消耗的最大值,而不能隔絕其他程式占用自己的資源。如果其他應用過渡占用物理機資源,將會影響容器裡 mysql 的讀寫效率。需要的隔離級別越多,獲得的資源開銷就越多。相比專用環境而言,容易水平伸縮是docker的一大優勢。然而在 docker 中水平伸縮只能用於無狀態計算服務,資料庫並不適用。我們沒有看到任何針對資料庫的隔離功能,那為什麼我們應該把它放在容器中呢?

6、雲平台的不適用性

大部分人通過共有雲開始專案。雲簡化了虛擬機器操作和替換的複雜性,因此不需要在夜間或週末沒有人工作時間來測試新的硬體環境。當我們可以迅速啟動乙個例項的時候,為什麼我們需要擔心這個例項執行的環境?這就是為什麼我們向雲提供商支付很多費用的原因。當我們為例項放置資料庫容器時,上面說的這些便利性就不存在了。因為資料不一致,新例項不會與老例項相容,如果要限制例項使用單機服務,應該讓 db 使用非容器化環境,我們僅僅需要為計算服務層保留彈性擴充套件的能力。

7、執行資料庫的環境需求

常看到 dbms 容器和其他服務執行在同一主機上。然而這些服務對硬體要求是非常不同的。資料庫(特別是關係型資料庫)對 io 的要求較高。一般資料庫引擎為了避免併發資源競爭而使用專用環境。如果將你的資料庫放在容器中,那麼將浪費你的專案的資源。因為你需要為該例項配置大量額外的資源。在公有雲,當你需要 34g 記憶體時,你啟動的例項卻必須開 64g 記憶體。在實踐中,這些資源並未完全使用。怎麼解決?您可以分層設計,並使用固定資源來啟動不同層次的多個例項。水平伸縮總是比垂直伸縮更好。

總結 了解

為什麼不建議把資料庫部署在Docker容器內?

為什麼不建議把資料庫部署在docker容器內?近2年docker非常的火熱,各位開發者恨不得把所有的應用 軟體都部署在docker容器中,但是您確定也要把資料庫也部署的容器中嗎?目前為止將資料庫容器化是非常不合理的,但是容器化的優點相信各位開發者都嘗到了甜頭,希望隨著技術的發展能夠更加完美的解決方案...

為什麼不建議把資料庫部署在Docker容器內?

1 資料安全問題不要將資料儲存在容器中,這也是 docker 官方容器使用技巧中的一條。容器隨時可以停止 或者刪除。當容器被rm掉,容器裡的資料將會丟失。為了避免資料丟失,使用者可以使用資料卷掛載來儲存資料。但是容器的 volumes 設計是圍繞 union fs 映象層提供持久儲存,資料安全缺乏保...

為什麼不建議把資料庫部署在Docker容器內

不要將資料儲存在容器中,這也是 docker 官方容器使用技巧中的一條。容器隨時可以停止 或者刪除。當容器被rm掉,容器裡的資料將會丟失。為了避免資料丟失,使用者可以使用資料卷掛載來儲存資料。但是容器的 volumes 設計是圍繞 union fs 映象層提供持久儲存,資料安全缺乏保證。如果容器突然...