docker可以從遠程倉庫拉取鏡像然后通過鏡像快速的部署應(yīng)用，非常的方便快捷，但是今天來聊聊為什么Mysql不推薦使用Docker部署這個問題。

1、數(shù)據(jù)庫擴容麻煩

    Mysql是用來存儲的數(shù)據(jù)，docker部署Mysql之后數(shù)據(jù)不會存儲在容器上，因為容器關(guān)閉之后數(shù)據(jù)就丟失了，所以容器是需要掛載到宿主機器上，如下圖所示：

    隨著業(yè)務(wù)的持續(xù)不斷的發(fā)展，Mysql難免會出現(xiàn)需要擴容的情況，但是擴容的時候就會出現(xiàn)一些困難，如下所示：

    此時Mysql2是無法掛載到文件1上的，因為宿主機的數(shù)據(jù)文件是容器獨占的，無法實現(xiàn)兩個容器實例共享一份數(shù)據(jù)文件。

    每個Mysql的容器都掛載了各自的文件上，如何實現(xiàn)文件1和文件2的數(shù)據(jù)共享呢？此時有如下的解決方案：

方案一：binlog同步

方案二：先全量dump，然后再使用binlog增量同步

    方案一是不推薦使用，Mysql擴容是因為業(yè)務(wù)數(shù)據(jù)量達到瓶頸了，那么大數(shù)據(jù)量下使用binlog同步是不合適的。

    方案二中全量dump數(shù)據(jù)的時候需要停機，目的是先讓數(shù)據(jù)同步到另一份文件上，因為數(shù)據(jù)需要同步進而讓業(yè)務(wù)在一段時間內(nèi)無法使用，在某種情況下也是不合適的。

2、內(nèi)存資源問題

    我們都知道docker是通過應(yīng)用來做隔離的，而不是通過資源做隔離的，如下圖所示：

    假設(shè)Mysql應(yīng)用、MQ應(yīng)用以及Redis應(yīng)用都是docker部署的，此時上圖區(qū)域的內(nèi)存是三個應(yīng)用共享的。這里就存在一個問題，如果MQ應(yīng)用占用了80%的內(nèi)存，那么Mysql和Redis就只能共用剩余20%的內(nèi)存，假設(shè)這個剩余的內(nèi)存不夠Mysql使用，這個時候就會出現(xiàn)Mysql無法提供正常的服務(wù)導致整個上層的應(yīng)用崩潰。

總結(jié)：

（1）從數(shù)據(jù)庫擴容角度來看，由于宿主機的數(shù)據(jù)文件是容器獨占的，所以多個容器就會掛載在多個宿主機文件上，盡管我們可以有方案解決宿主機文件數(shù)據(jù)共享的問題，但是數(shù)據(jù)同步方案中存在一定弊端。

（2）內(nèi)存資源上來考慮，由于docker部署的應(yīng)用是共享內(nèi)存的，所以一旦某個應(yīng)用占用內(nèi)存過大就會導致其他應(yīng)用因為內(nèi)存不足而無法對外提供服務(wù)的問題。

（3）不是說不能使用docker部署Mysql，在某些情況下docker部署的Mysql還是比較合適的，如能夠利用中間件和容器化系統(tǒng)能夠自動伸縮、容災(zāi)、切換、自帶多個節(jié)點等場景下是合適進行容器化。