目前,容器和 Docker 依舊是技術(shù)領(lǐng)域最熱門的詞語(yǔ),無(wú)狀態(tài)的服務(wù)容器化已經(jīng)是大勢(shì)所趨,同時(shí)也帶來(lái)了一個(gè)熱點(diǎn)問(wèn)題被大家所爭(zhēng)論不以:數(shù)據(jù)庫(kù) MySQL 是否需要容器化?認(rèn)真分析大家的各種觀點(diǎn),發(fā)現(xiàn)贊同者僅僅是從容器優(yōu)勢(shì)的角度來(lái)闡述 MySQL 需要容器化,幾乎沒(méi)有什么業(yè)務(wù)場(chǎng)景進(jìn)行驗(yàn)證自己的觀點(diǎn);反過(guò)來(lái)再看反對(duì)者,他們從性能、數(shù)據(jù)安全等多個(gè)因素進(jìn)行闡述 MySQL不需要容器化,也舉證了一些不適合的業(yè)務(wù)場(chǎng)景。下面,我們就聊一下 Docker 不適合跑 MySQL 的 N 個(gè)原因!
數(shù)據(jù)安全問(wèn)題
不要將數(shù)據(jù)儲(chǔ)存在容器中,這也是 Docker 官方容器使用技巧中的一條。容器隨時(shí)可以停止、或者刪除。當(dāng)容器被rm掉,容器里的數(shù)據(jù)將會(huì)丟失。為了避免數(shù)據(jù)丟失,用戶可以使用數(shù)據(jù)卷掛載來(lái)存儲(chǔ)數(shù)據(jù)。但是容器的 Volumes 設(shè)計(jì)是圍繞 Union FS 鏡像層提供持久存儲(chǔ),數(shù)據(jù)安全缺乏保證。如果容器突然崩潰,數(shù)據(jù)庫(kù)未正常關(guān)閉,可能會(huì)損壞數(shù)據(jù)。另外,容器里共享數(shù)據(jù)卷組,對(duì)物理機(jī)硬件損傷也比較大。
性能問(wèn)題
大家都知道,MySQL 屬于關(guān)系型數(shù)據(jù)庫(kù),對(duì)IO要求較高。當(dāng)一臺(tái)物理機(jī)跑多個(gè)時(shí),IO就會(huì)累加,導(dǎo)致IO瓶頸,大大降低 MySQL 的讀寫性能。在一次Docker應(yīng)用的十大難點(diǎn)專場(chǎng)上,某國(guó)有銀行的一位架構(gòu)師也曾提出過(guò):“數(shù)據(jù)庫(kù)的性能瓶頸一般出現(xiàn)在IO上面,如果按 Docker 的思路,那么多個(gè)docker最終IO請(qǐng)求又會(huì)出現(xiàn)在存儲(chǔ)上面。現(xiàn)在互聯(lián)網(wǎng)的數(shù)據(jù)庫(kù)多是share nothing的架構(gòu),可能這也是不考慮遷移到 Docker 的一個(gè)因素吧”。其實(shí)也有相對(duì)應(yīng)的一些策略來(lái)解決這個(gè)問(wèn)題,比如:
資源隔離方面,Docker 確實(shí)不如虛擬機(jī)KVM,Docker是利用Cgroup實(shí)現(xiàn)資源限制的,只能限制資源消耗的最大值,而不能隔絕其他程序占用自己的資源。如果其他應(yīng)用過(guò)渡占用物理機(jī)資源,將會(huì)影響容器里 MySQL 的讀寫效率。需要的隔離級(jí)別越多,獲得的資源開銷就越多。相比專用環(huán)境而言,容易水平伸縮是Docker的一大優(yōu)勢(shì)。然而在 Docker 中水平伸縮只能用于無(wú)狀態(tài)計(jì)算服務(wù),數(shù)據(jù)庫(kù)并不適用。
難道 MySQL 不能跑在容器里嗎?
MySQL 也不是全然不能容器化。1)對(duì)數(shù)據(jù)丟失不敏感的業(yè)務(wù)(例如用戶搜索商品)就可以數(shù)據(jù)化,利用數(shù)據(jù)庫(kù)分片來(lái)來(lái)增加實(shí)例數(shù),從而增加吞吐量。2)docker適合跑輕量級(jí)或分布式數(shù)據(jù)庫(kù),當(dāng)docker服務(wù)掛掉,會(huì)自動(dòng)啟動(dòng)新容器,而不是繼續(xù)重啟容器服務(wù)。3)數(shù)據(jù)庫(kù)利用中間件和容器化系統(tǒng)能夠自動(dòng)伸縮、容災(zāi)、切換、自帶多個(gè)節(jié)點(diǎn),也是可以進(jìn)行容器化的。典型案例:同程旅游、京東、阿里的數(shù)據(jù)庫(kù)容器化都是不錯(cuò)的案例,大家可以自行去查看。(感謝閱讀,希望對(duì)你所有幫助)來(lái)源:toutiao.com/i6675622107390411276