看到網路上一片文章說：資料庫不適合Docker及容器化？

Question

文章連結
剛開始用docker，有點疑惑？

Answer 1

關於資料庫不適合放在docker裡面，有兩個歪果仁的文章，其一就是樓主所貼，其二是這篇，譯文

還是那個觀點：

量小的時候隨便搞，量大了有些東西就不行了，傳統型數據庫和docker並不對路，建議不要直接容器化，非要把數據庫容器化，那麼需要各種系統的支撐，包括中間件系統、容器化系統。

如果你的資料庫能夠自動伸縮、容災、切換、自帶多節點解決方案等，docker算是比較好的方案。

但是如果不能，還是不要用docker。

原文也說得很清楚：

在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。

---

流量小的情況下，什麼東西容器化都行。資料庫，應用，hadoop，各種節點，nginx。

---

量大的情況下，儲存相關的不適合容器化，應用層、業務層等無狀態的服務適合容器化，快取這類記憶體密集的服務可以容器化。

簡單來說就是三個問題，容災、效能和資料一致性。

就mysql這種傳統資料庫而言，光是我所能列出來的問題就有如下這麼多：

1. mysql怎麼容器化？

2. 主庫mysqld跪了怎麼辦？

3. 主庫dockerd跪了怎麼辦？

4. 從庫mysqld跪了怎麼辦？

5. 從庫dockerd跪了怎麼辦？

6. 能否在高峰來臨之際透過容器快速擴容mysql？方案？

7. 資料主從切換方案？一致性如何保證？

8. 高峰時期量夠大，有時候一般一台實體機的容量只夠一個mysql進程。

9. 那麼同樣是單一機器，為什麼不能直接啟動mysql？

10. 為什麼還要外面套一層容器？對性能損耗多少？

11. mysql如何升級？

12. 資料卷是否會遺失資料？ （損壞容器我遇過很多次了…）

但是mysql也不是全然不能容器化。
對資料遺失不敏感的業務（例如京東搜尋搜到的商品）就可以資料化，利用資料庫分片來實現透過增加實例數增加吞吐量。

題主原文中提到的問題，有些東西是有槽點的，但是考慮的很周全。例如以下問題就很有槽點（關於共享資料目錄）：

容易水平伸缩？是否要在多个实例之间共享数据目录？你不害怕直接数据并发问题和可能的数据损坏吗？使用专用数据环境部署多个实例不会更安全吗？最后搞一个主从复制？

就我目前接觸到的資料庫來看，只有cassandra這類（個）（還有tidb和cockroachdb，但是目前還沒遇到大公司的用例）資料庫適合容器化。

但是cassandra本身也接近是無狀態了：自己提供容災，擴容，切換方案。

---

以下提一下京東。

京東是個異類，但是京東也提到類似的問題和需要注意的地方。

计算类应用、无状态应用优先，例如微服务特别容易迁移到弹性云。
应用迁移到弹性云，最好选择统一的规格，避免各个实例的负载不均衡。
应用从物理机迁移到弹性云后，实例数量会增加，相应对后端服务的连接数会增加，特别是数据库连接，所以需要防止连接过载。
在弹性云上共享磁盘IO，要避免应用刷日志，减少本地读写文件，采用JFS或JIMDB来满足文件存储或共享数据需求。
容器的CPU核数原低于原有物理机的核数，应用需要根据CPU核数来合理地配置线程数和网络参数。
修改底层，让应用在运行时能准确地拿到自身容器的核数。

甚至，對docker做了很多的客製化。

可以看京東分享。

Answer 2

不適合, 而不是不能.

如果單機沒什麼問題, 在某些情況下還是有利的. 例如之前我公司的oracle資料庫調參數時導致資料庫崩潰徹底起不來了, 還好那時用的是docker, 直接run一個, 把資料目錄指向原來的就好了.

集群的話不管怎麼樣, 用docker手工組, 或swarm這類工具也好, 都不太好搞. 還不如直接在物理機上搭建省事.

國外有家公司就是專屬docker的資料儲存方案的. 例如flocker, 還有rancher的convoy

Answer 3

docker放更適合無狀態，不會變更服務。

如大量的集群時：
編寫好docker file。然後當程式碼上傳到程式碼倉庫的後，然後部署讓好docker file以後，再讓發布腳本批次建置docker服務並將服務程式碼放進去。

不只是MySQL，類似redis，mc都不適合放入docker中，或是說放把資料庫放docker中有為了使用docker而這樣做，並沒有太多的好處。

Answer 4

是的，因為docker的特性決定了它是不適合做資料儲存的，不只是資料庫，所有儲存相關的服務都不適合用docker。

Answer 5

官方mysql鏡像是把資料儲存在哪個目錄的我都看不明白。