Docker 爲什麼不適合跑 MySQL

容器的定義：容器是爲了解決“在切換運行環境時，如何保證軟件能夠正常運行”這一問題。
目前，容器和 Docker 依舊是技術領域最熱門的詞語，無狀態的服務容器化已經是大勢所趨，同時也帶來了一個熱點問題被大家所爭論不以：數據庫 MySQL 是否需要容器化？認真分析大家的各種觀點，發現贊同者僅僅是從容器優勢的角度來闡述 MySQL 需要容器化，幾乎沒有什麼業務場景進行驗證自己的觀點；反過來再看反對者，他們從性能、數據安全等多個因素進行闡述 MySQL不需要容器化，也舉證了一些不適合的業務場景。下面，我們就聊一下 Docker 不適合跑 MySQL 的 N 個原因！1 數據持久性： 默認情況下，Docker 容器是臨時的，意味着容器關閉後容器內的數據會丟失。雖然可以使用 Docker 卷或者綁定掛載來實現數據的持久性，但是這增加了管理和配置的複雜性2 性能： 在 Docker 容器中運行數據庫可能會導致性能下降。數據庫通常需要高速 I/O 和大量的內存，而容器化環境可能會對這些要求產生一些限制。3 資源限制： Docker 容器可以受到物理主機資源的限制，這可能會影響數據庫的性能和可擴展性。當容器共享主機的 CPU、內存和網絡資源時，可能會導致資源競爭。4 複雜性： 數據庫系統通常需要進行復雜的配置、優化和監控，容器化環境可能增加了部署和管理的複雜性。儘管如此，許多人仍然使用 Docker 部署 MySQL，特別是在開發和測試環境中，因爲 Docker 提供了快速部署、輕量級和隔離性等優勢。在生產環境中，如果需要高可用性和性能，可能會考慮使用更傳統的部署方法，如虛擬機或物理服務器。其實也有相對應的一些策略來解決這個問題，比如1）數據庫程序與數據分離
如果使用Docker 跑 MySQL，數據庫程序與數據需要進行分離，將數據存放到共享存儲，程序放到容器裏。如果容器有異常或 MySQL 服務異常，自動啓動一個全新的容器。另外，建議不要把數據存放到宿主機裏，宿主機和容器共享卷組，對宿主機損壞的影響比較大。2）跑輕量級或分佈式數據庫
Docker 裏部署輕量級或分佈式數據庫，Docker 本身就推薦服務掛掉，自動啓動新容器，而不是繼續重啓容器服務。3）合理佈局應用
對於IO要求比較高的應用或者服務，將數據庫部署在物理機或者KVM中比較合適。目前騰訊雲的TDSQL和阿里的Oceanbase都是直接部署在物理機器，而非Docker 。狀態問題
在 Docker 中水平伸縮只能用於無狀態計算服務，而不是數據庫。
Docker 快速擴展的一個重要特徵就是無狀態，具有數據狀態的都不適合直接放在 Docker 裏面，如果 Docker 中安裝數據庫，存儲服務需要單獨提供。目前，騰訊雲的TDSQL（金融分佈式數據庫）和阿里雲的Oceanbase（分佈式數據庫系統）都直接運行中在物理機器上，並非使用便於管理的 Docker 上。資源隔離方面
資源隔離方面，Docker 確實不如虛擬機KVM，Docker是利用Cgroup實現資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程序佔用自己的資源。如果其他應用過渡佔用物理機資源，將會影響容器裏 MySQL 的讀寫效率。需要的隔離級別越多，獲得的資源開銷就越多。相比專用環境而言，容易水平伸縮是Docker的一大優勢。然而在 Docker 中水平伸縮只能用於無狀態計算服務，數據庫並不適用。