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

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

　　上海聚搜信息技術有限公司是阿里云的代理商網(wǎng)址:http://www.gzjcsc123.com/可以直接在網(wǎng)站上聯(lián)系阿里云代理商客服進行咨詢服務器架構和配置以及優(yōu)惠價格！騰訊云產(chǎn)品http://tx.4526.cn/（聚搜營銷介紹鏈接：http://www.jusoucn.com/meiyou/）是一家致力于搜索引聚搜營銷及全網(wǎng)營銷，致力于為客戶提供搜索營銷領域的服務，幫助廣告客戶在搜索引聚搜獲取的投資回報，包括搜索引聚搜競價服務(SEM)，搜索引聚搜優(yōu)化服務（seo）和搜索營銷代運營服務，能夠有效為廣告主帶來高效的投放回報，我們的理念一直是：讓搜索營銷營銷具有價值。

　　聚搜營銷團隊于2015年在上海成立，團隊核心均來自百度搜索部門和國內(nèi)知名服務商的成員，有非常豐富的產(chǎn)品和項目優(yōu)化經(jīng)驗，這兩年來，服務于國內(nèi)很多大中型企業(yè)和很多初創(chuàng)公司，通過我們多年的經(jīng)驗和服務，幫助他們在搜索營銷領域上取得了不斷的成功。

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

　　Docker不適合部署數(shù)據(jù)庫的7大原因

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

　　不要將數(shù)據(jù)儲存在容器中，這也是Docker官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。當容器被rm掉，容器里的數(shù)據(jù)將會丟失。為了避免數(shù)據(jù)丟失，用戶可以使用數(shù)據(jù)卷掛載來存儲數(shù)據(jù)。但是容器的Volumes設計是圍繞Union FS鏡像層提供持久存儲，數(shù)據(jù)安全缺乏保證。如果容器突然崩潰，數(shù)據(jù)庫未正常關閉，可能會損壞數(shù)據(jù)。另外，容器里共享數(shù)據(jù)卷組，對物理機硬件損傷也比較大。

　　即使你要把Docker數(shù)據(jù)放在主機來存儲，它依然不能保證不丟數(shù)據(jù)。Docker Volumes的設計圍繞Union FS鏡像層提供持久存儲，但它仍然缺乏保證。

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

　　2、性能問題

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

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

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

　　數(shù)據(jù)庫程序與數(shù)據(jù)分離，如果使用Docker跑MySQL，數(shù)據(jù)庫程序與數(shù)據(jù)需要進行分離，將數(shù)據(jù)存放到共享存儲，程序放到容器里。如果容器有異?；騇ySQL服務異常，自動啟動一個全新的容器。另外，建議不要把數(shù)據(jù)存放到宿主機里，宿主機和容器共享卷組，對宿主機損壞的影響比較大。

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

　　合理布局應用，對于IO要求比較高的應用或者服務，將數(shù)據(jù)庫部署在物理機或者KVM中比較合適。目前騰訊云的TDSQL和阿里的Oceanbase都是直接部署在物理機器，而非Docker。

　　3、網(wǎng)絡問題

　　要理解Docker網(wǎng)絡，您必須對網(wǎng)絡虛擬化有深入的了解。也必須準備應付好意外情況。你可能需要在沒有支持或沒有額外工具的情況下，進行bug修復。

　　我們知道：數(shù)據(jù)庫需要專用的和持久的吞吐量，以實現(xiàn)更高的負載。我們還知道容器是虛擬機管理程序和主機虛擬機背后的一個隔離層。然而網(wǎng)絡對于數(shù)據(jù)庫復制是至關重要的，其中需要主從數(shù)據(jù)庫間24/7的穩(wěn)定連接。未解決的Docker網(wǎng)絡問題在1.9版本依然沒有得到解決。

　　把這些問題放在一起，容器化使數(shù)據(jù)庫容器很難管理。我知道你是一個頂級的工程師，什么問題都可以得到解決。但是，你需要花多少時間解決Docker網(wǎng)絡問題？將數(shù)據(jù)庫放在專用環(huán)境不會更好嗎？節(jié)省時間來專注于真正重要的業(yè)務目標。

　　4、狀態(tài)

　　在Docker中打包無狀態(tài)服務是很酷的，可以實現(xiàn)編排容器并解決單點故障問題。但是數(shù)據(jù)庫呢？將數(shù)據(jù)庫放在同一個環(huán)境中，它將會是有狀態(tài)的，并使系統(tǒng)故障的范圍更大。下次您的應用程序實例或應用程序崩潰，可能會影響數(shù)據(jù)庫。

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

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

　　5、資源隔離

　　資源隔離方面，Docker確實不如虛擬機KVM，Docker是利用Cgroup實現(xiàn)資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程序占用自己的資源。如果其他應用過渡占用物理機資源，將會影響容器里MySQL的讀寫效率。

　　需要的隔離級別越多，獲得的資源開銷就越多。相比專用環(huán)境而言，容易水平伸縮是Docker的一大優(yōu)勢。然而在Docker中水平伸縮只能用于無狀態(tài)計算服務，數(shù)據(jù)庫并不適用。

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

　　6、云平臺的不適用性

　　大部分人通過共有云開始項目。云簡化了虛擬機操作和替換的復雜性，因此不需要在夜間或周末沒有人工作時間來測試新的硬件環(huán)境。當我們可以迅速啟動一個實例的時候，為什么我們需要擔心這個實例運行的環(huán)境？

　　這就是為什么我們向云提供商支付很多費用的原因。當我們?yōu)閷嵗胖脭?shù)據(jù)庫容器時，上面說的這些便利性就不存在了。因為數(shù)據(jù)不匹配，新實例不會與現(xiàn)有的實例兼容，如果要限制實例使用單機服務，應該讓DB使用非容器化環(huán)境，我們僅僅需要為計算服務層保留彈性擴展的能力。

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

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

　　數(shù)據(jù)庫（特別是關系型數(shù)據(jù)庫）對IO的要求較高。一般數(shù)據(jù)庫引擎為了避免并發(fā)資源競爭而使用專用環(huán)境。如果將你的數(shù)據(jù)庫放在容器中，那么將浪費你的項目的資源。因為你需要為該實例配置大量額外的資源。在公有云，當你需要34G內(nèi)存時，你啟動的實例卻必須開64G內(nèi)存。在實踐中，這些資源并未完全使用。

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

　　總結

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

　　答案是：并不是。

　　我們可以把數(shù)據(jù)丟失不敏感的業(yè)務（搜索、埋點）就可以數(shù)據(jù)化，利用數(shù)據(jù)庫分片來來增加實例數(shù)，從而增加吞吐量。

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

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