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

[[352003]] 

圖片來自 Pexels

這個(gè)問題不是子虛烏有，因?yàn)樵诰W(wǎng)上能夠找到很多各種操作手冊和視頻教程，這里整理了一些數(shù)據(jù)庫不適合容器化的原因供大家參考，同時(shí)也希望大家在使用時(shí)能夠謹(jǐn)慎一點(diǎn)。

目前為止將數(shù)據(jù)庫容器化是非常不合理的，但是容器化的優(yōu)點(diǎn)相信各位開發(fā)者都嘗到了甜頭，希望隨著技術(shù)的發(fā)展能夠更加完美的解決方案出現(xiàn)。

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

1.數(shù)據(jù)安全問題

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

當(dāng)容器被 rm 掉，容器里的數(shù)據(jù)將會丟失。為了避免數(shù)據(jù)丟失，用戶可以使用數(shù)據(jù)卷掛載來存儲數(shù)據(jù)。

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

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

使用當(dāng)前的存儲驅(qū)動程序，Docker 仍然存在不可靠的風(fēng)險(xiǎn)。如果容器崩潰并數(shù)據(jù)庫未正確關(guān)閉，則可能會損壞數(shù)據(jù)。

2.性能問題

大家都知道，MySQL 屬于關(guān)系型數(shù)據(jù)庫，對 IO 要求較高。當(dāng)一臺物理機(jī)跑多個(gè)時(shí)，IO 就會累加，導(dǎo)致 IO 瓶頸，大大降低 MySQL 的讀寫性能。

在一次 Docker 應(yīng)用的十大難點(diǎn)專場上，某國有銀行的一位架構(gòu)師也曾提出過：“數(shù)據(jù)庫的性能瓶頸一般出現(xiàn)在 IO 上面，如果按 Docker 的思路，那么多個(gè) Docker 最終 IO 請求又會出現(xiàn)在存儲上面。現(xiàn)在互聯(lián)網(wǎng)的數(shù)據(jù)庫多是 share nothing 的架構(gòu)，可能這也是不考慮遷移到 Docker 的一個(gè)因素吧”。

針對性能問題有些同學(xué)可能也有相對應(yīng)的方案來解決：

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

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

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

②跑輕量級或分布式數(shù)據(jù)庫

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

③合理布局應(yīng)用

對于 IO 要求比較高的應(yīng)用或者服務(wù)，將數(shù)據(jù)庫部署在物理機(jī)或者 KVM 中比較合適。

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

3.網(wǎng)絡(luò)問題

要理解 Docker 網(wǎng)絡(luò)，您必須對網(wǎng)絡(luò)虛擬化有深入的了解。數(shù)據(jù)庫需要專用的和持久的吞吐量，以實(shí)現(xiàn)更高的負(fù)載。

未解決的 Docker 網(wǎng)絡(luò)問題在 1.9 版本依然沒有得到解決。把這些問題放在一起，容器化使數(shù)據(jù)庫容器很難管理。

你需要花多少時(shí)間解決 Docker 網(wǎng)絡(luò)問題?將數(shù)據(jù)庫放在專用環(huán)境不會更好嗎?節(jié)省時(shí)間來專注于真正重要的業(yè)務(wù)目標(biāo)。

4.狀態(tài)

在 Docker 中打包無狀態(tài)服務(wù)是很酷的，可以實(shí)現(xiàn)編排容器并解決單點(diǎn)故障問題。

但是數(shù)據(jù)庫呢?將數(shù)據(jù)庫放在同一個(gè)環(huán)境中，它將會是有狀態(tài)的，并使系統(tǒng)故障的范圍更大。下次您的應(yīng)用程序?qū)嵗驊?yīng)用程序崩潰，可能會影響數(shù)據(jù)庫。

知識點(diǎn)：在 Docker 中水平伸縮只能用于無狀態(tài)計(jì)算服務(wù)，而不是數(shù)據(jù)庫。

Docker 快速擴(kuò)展的一個(gè)重要特征就是無狀態(tài)，具有數(shù)據(jù)狀態(tài)的都不適合直接放在 Docker 里面，如果 Docker 中安裝數(shù)據(jù)庫，存儲服務(wù)需要單獨(dú)提供。

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

5.資源隔離

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

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

相比專用環(huán)境而言，容易水平伸縮是 Docker 的一大優(yōu)勢。然而在 Docker 中水平伸縮只能用于無狀態(tài)計(jì)算服務(wù)，數(shù)據(jù)庫并不適用。

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

6.云平臺的不適用性

大部分人通過共有云開始項(xiàng)目。云簡化了虛擬機(jī)操作和替換的復(fù)雜性，因此不需要在夜間或周末沒有人工作時(shí)間來測試新的硬件環(huán)境。

當(dāng)我們可以迅速啟動一個(gè)實(shí)例的時(shí)候，為什么我們需要擔(dān)心這個(gè)實(shí)例運(yùn)行的環(huán)境?

這就是為什么我們向云提供商支付很多費(fèi)用的原因。當(dāng)我們?yōu)閷?shí)例放置數(shù)據(jù)庫容器時(shí)，上面說的這些便利性就不存在了。

因?yàn)閿?shù)據(jù)不一致，新實(shí)例不會與老實(shí)例兼容，如果要限制實(shí)例使用單機(jī)服務(wù)，應(yīng)該讓 DB 使用非容器化環(huán)境，我們僅僅需要為計(jì)算服務(wù)層保留彈性擴(kuò)展的能力。

7.運(yùn)行數(shù)據(jù)庫的環(huán)境需求

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

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

如果將你的數(shù)據(jù)庫放在容器中，那么將浪費(fèi)你的項(xiàng)目的資源。因?yàn)槟阈枰獮樵搶?shí)例配置大量額外的資源。

在公有云，當(dāng)你需要 34G 內(nèi)存時(shí)，你啟動的實(shí)例卻必須開 64G 內(nèi)存。在實(shí)踐中，這些資源并未完全使用。

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

8.總結(jié)

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

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

Docker 適合跑輕量級或分布式數(shù)據(jù)庫，當(dāng) Docker 服務(wù)掛掉，會自動啟動新容器，而不是繼續(xù)重啟容器服務(wù)。

數(shù)據(jù)庫利用中間件和容器化系統(tǒng)能夠自動伸縮、容災(zāi)、切換、自帶多個(gè)節(jié)點(diǎn)，也是可以進(jìn)行容器化的。

作者：梅西愛騎車

編輯：陶家龍

出處：http://l.wz2.in/0AC