為什么不建議把數(shù)據(jù)庫部署在Docker容器內(nèi)

　　Docker在過去ocker非常受歡迎。開發(fā)人員迫不及待地想將所有應(yīng)用程序部署在Docker容器中，但你確定你也應(yīng)該部署數(shù)據(jù)庫容器嗎？這個問題不是空的，因為你可以在網(wǎng)上找到很多操作手冊和視頻教程。這里整理了一些數(shù)據(jù)庫不適合容器化的原因供您參考。同時，我希望您在使用時能謹慎。到目前為止，將數(shù)據(jù)庫容器化是非常不合理的，但我相信所有開發(fā)人員都嘗到了容器化的優(yōu)勢。我希望隨著技術(shù)的發(fā)展，能出現(xiàn)更完美的解決方案。

為什么不建議在Docker容器中部署數(shù)據(jù)庫？

部署數(shù)據(jù)庫的七個原因不適合Docker。

　1.不要將數(shù)據(jù)存儲在容器中，這也是Docker官方容器使用技能之一。容器可以隨時停止。或刪除。當容器被RM丟失時，容器中的數(shù)據(jù)將丟失。為了避免數(shù)據(jù)丟失，用戶可以使用數(shù)據(jù)卷來存儲數(shù)據(jù)。然而，容器的Volumes設(shè)計是圍繞UnionFS鏡像層提供持久存儲，數(shù)據(jù)安全缺乏保證。如果容器突然崩潰，數(shù)據(jù)庫沒有正常關(guān)閉，數(shù)據(jù)可能會損壞。此外，容器中共享的數(shù)據(jù)卷對物理機器的硬件也有很大的損壞。即使你想將Docker數(shù)據(jù)存儲在主機中，它仍然不能保證不丟失數(shù)據(jù)。使用當前的存儲驅(qū)動程序，Docker仍然存在不可靠的風險。如果容器崩潰，數(shù)據(jù)庫沒有正確關(guān)閉，數(shù)據(jù)可能會損壞。

　2.眾所周知，MySQL是一個關(guān)系數(shù)據(jù)庫，對IO有很高的要求。當一臺物理機運行多次時，IO會累積，導致IO瓶頸，大大降低MySQL的讀寫性能。在Docker應(yīng)用的十大難點特別節(jié)目中，一家國有銀行的一位架構(gòu)師也提出：數(shù)據(jù)庫的性能瓶頸通常出現(xiàn)在IO上。如果遵循Docker的想法，許多docker最終的IO請求將再次出現(xiàn)在存儲上。現(xiàn)在互聯(lián)網(wǎng)上的大多數(shù)數(shù)據(jù)庫都是sharenothing的架構(gòu)，這可能是一個不考慮遷移到docker的因素。

一些學生也可能有相應(yīng)的解決性能問題的方案：

(1)數(shù)據(jù)庫程序與數(shù)據(jù)分離。

如果使用Docker運行MySQL，則需要將數(shù)據(jù)庫程序與數(shù)據(jù)分離，將數(shù)據(jù)存儲在共享存儲中，并將程序放入容器中。如果容器異常或MySQL服務(wù)異常，自動啟動新容器。此外，建議不要將數(shù)據(jù)存儲在宿主機中。宿主機和容器共享卷對宿主機的損壞有很大影響。

(2)運行輕量級或分布式數(shù)據(jù)庫。

Docker部署了輕量級或分布式數(shù)據(jù)庫。Docker本身建議掛斷服務(wù)，自動啟動新容器，而不是繼續(xù)重啟容器服務(wù)。

(3)合理布局應(yīng)用。

對于IO要求較高的應(yīng)用或服務(wù)，更適合在物理機或KVM中部署數(shù)據(jù)庫。目前TX云的TDSQL和阿里的Oceanbase直接部署在物理機上，而不是Docker。

3.如果你想了解Docker網(wǎng)絡(luò)，你必須對網(wǎng)絡(luò)虛擬化有深入的了解。數(shù)據(jù)庫需要特殊和持久的吞吐量來實現(xiàn)更高的負載。未解決的Docker網(wǎng)絡(luò)問題仍未在1.9版本中解決。將這些問題放在一起，容器化使數(shù)據(jù)庫容器難以管理。你需要多少時間來解決Docker網(wǎng)絡(luò)問題？把數(shù)據(jù)庫放在一個特殊的環(huán)境中不是更好嗎？節(jié)省時間專注于真正重要的業(yè)務(wù)目標。

4.在Docker中包裝無狀態(tài)服務(wù)非常酷，可以安排容器，解決單點故障問題。但是數(shù)據(jù)庫呢？將數(shù)據(jù)庫放置在同一環(huán)境中，它將處于狀態(tài)，并使系統(tǒng)故障范圍更大。下一次，您的應(yīng)用程序?qū)嵗驊?yīng)用程序崩潰可能會影響數(shù)據(jù)庫。知識點：在Docker中，水平伸縮只能用于無狀態(tài)計算服務(wù)，而不是數(shù)據(jù)庫。Docker快速擴展的一個重要特點是無狀態(tài)。具有數(shù)據(jù)狀態(tài)的不適合直接放置在Docker中。如果數(shù)據(jù)庫安裝在Docker中，則需要單獨提供存儲服務(wù)。目前，TX云的TDSQL（金融分布式數(shù)據(jù)庫）和阿里云的Oceanbase（分布式數(shù)據(jù)庫系統(tǒng)）直接在物理機器上運行，而不是使用易于管理的Docker。

5.在資源隔離方面，Docker確實不如虛擬機KVM。Docker利用Cgroup實現(xiàn)資源限制。它只能限制資源消耗的最大值，而不能隔離其他程序來占用自己的資源。如果其他應(yīng)用程序過渡占用物理機器資源，則會影響容器中MySQL的讀寫效率。隔離級別越高，資源成本就越高。與特殊環(huán)境相比，易于水平伸縮是Docker的一大優(yōu)勢。然而，在Docker中，水平伸縮只能用于無狀態(tài)計算服務(wù)，不適用于數(shù)據(jù)庫。我們沒有看到任何數(shù)據(jù)庫隔離功能。我們?yōu)槭裁匆阉旁谌萜骼铮?/p>

6.大多數(shù)人通過共享云開始項目。云簡化了虛擬機操作和更換的復雜性，因此沒有必要在夜間或周末測試新的硬件環(huán)境。當我們可以快速啟動一個例子時，為什么我們需要擔心這個例子的操作環(huán)境呢？這就是為什么我們向云提供商支付了大量的費用。當我們將數(shù)據(jù)庫容器放置為例子時，上述便利性并不存在。由于數(shù)據(jù)不一致，新的例子不會與舊的例子兼容。如果我們想限制單機服務(wù)的使用，我們應(yīng)該讓DB使用非容器環(huán)境，我們只需要保持靈活擴展計算服務(wù)層的能力。

7.DBMS容器和其他服務(wù)經(jīng)常在同一主機上運行。然而，這些服務(wù)對硬件有非常不同的要求。數(shù)據(jù)庫（特別是關(guān)系數(shù)據(jù)庫）對IO有很高的要求。一般數(shù)據(jù)庫引擎使用特殊環(huán)境，以避免并發(fā)資源競爭。如果將您的數(shù)據(jù)庫放入容器中，則將浪費您的項目資源。因為你需要為這個例子配置大量的額外資源。在公共云中，當您需要34G內(nèi)存時，您必須打開64G內(nèi)存。在實踐中，這些資源并沒有完全使用。如何解決它？您可以分層設(shè)計，并使用固定資源來啟動不同層次的多個例子。水平伸縮總是比垂直伸縮好。

綜上所述，對于上述問題，數(shù)據(jù)庫是否不能部署在容器中？答案是：我們不能將數(shù)據(jù)丟失和不敏感的業(yè)務(wù)（搜索。埋點）集成，并使用數(shù)據(jù)庫分片來增加實例數(shù)，從而增加吞吐量。docker適用于運行輕量級或分布式數(shù)據(jù)庫。當docker服務(wù)掛斷時，新容器將自動啟動，而不是繼續(xù)重新啟動容器服務(wù)。數(shù)據(jù)庫可以通過中間件和集成系統(tǒng)自動擴展。容災(zāi)。切換。它有多個節(jié)點，也可以集成。