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

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

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

圖片

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

圖片

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

圖片

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

方案一：binlog同步

圖片

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

圖片

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

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

2、內存資源問題

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

圖片

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

總結：

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

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

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