容器的定義：容器是為了解決“在切換運行環境時，如何保證軟體能夠正常運行”這一問題。
目前，容器和 Docker 依旧是技术领域最热门的词语，无状态的服务容器化已经是大势所趋，同时也带来了一个热点问题被大家所争论不以：数据库 MySQL 是否需要容器化？
认真分析大家的各种观点，发现赞同者仅仅是从容器优势的角度来阐述 MySQL 需要容器化，几乎没有什么业务场景进行验证自己的观点；反过来再看反对者，他们从性能、数据安全等多个因素进行阐述 MySQL 不需要容器化，也举证了一些不适合的业务场景。下面，我们就聊一下 Docker 不适合跑 MySQL 的 N 个原因！
數據安全問題
不要將數據儲存在容器中，這也是 docker 官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。當容器被 rm 掉，容器里的數據將會丟失。為了避免數據丟失，用戶可以使用數據卷掛載來存儲數據。但是容器的 volumes 設計是圍繞 union fs 鏡像層提供持久存儲，數據安全缺乏保證。如果容器突然崩潰，資料庫未正常關閉，可能會損壞數據。另外，容器里共享數據卷組，對物理機硬體損傷也比較大。
性能問題
大家都知道，mysql 屬於關係型資料庫，對 io 要求較高。當一台物理機跑多個時，io 就會累加，導致 io 瓶頸，大大降低 mysql 的讀寫性能。
在一次 docker 應用的十大難點專場上，某國有銀行的一位架構師也曾提出過：“資料庫的性能瓶頸一般出現在 io 上面，如果按 docker 的思路，那麼多個 docker 最終 io 請求又會出現在存儲上面。現在網際網路的資料庫多是 share nothing 的架構，可能這也是不考慮遷移到 docker 的一個因素吧”。
其實也有相對應的一些策略來解決這個問題，比如：
- 資料庫程式與數據分離
如果使用 docker 跑 mysql，資料庫程式與數據需要進行分離，將數據存放到共享存儲，程式放到容器里。如果容器有異常或 mysql 服務異常，自動啟動一個全新的容器。另外，建議不要把數據存放到宿主機里，宿主機和容器共享卷組，對宿主機損壞的影響比較大。
- 跑輕量級或分布式資料庫
docker 里部署輕量級或分布式資料庫，docker 本身就推薦服務掛掉，自動啟動新容器，而不是繼續重啟容器服務。
- 合理布局應用
對於 io 要求比較高的應用或者服務，將資料庫部署在物理機或者 kvm 中比較合適。目前騰訊雲的 tdsql 和阿里的 oceanbase 都是直接部署在物理機器，而非 docker 。
狀態問題
在 docker 中水平伸縮只能用於無狀態計算服務，而不是資料庫。
docker 快速擴展的一個重要特徵就是無狀態，具有數據狀態的都不適合直接放在 docker 裡面，如果 docker 中安裝資料庫，存儲服務需要單獨提供。
目前，騰訊雲的 tdsql（金融分布式資料庫）和阿里雲的 oceanbase（分布式資料庫系統）都直接運行中在物理機器上，並非使用便於管理的 docker 上。
資源隔離方面
資源隔離方面，docker 確實不如虛擬機 kvm，docker 是利用 cgroup 實現資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程式占用自己的資源。如果其他應用過渡占用物理機資源，將會影響容器里 mysql 的讀寫效率。
需要的隔離級別越多，獲得的資源開銷就越多。相比專用環境而言，容易水平伸縮是 docker 的一大優勢。然而在 docker 中水平伸縮只能用於無狀態計算服務，資料庫並不適用。
難道 mysql 不能跑在容器里嗎？
mysql 也不是全然不能容器化。
對數據丟失不敏感的業務（例如用戶搜索商品）就可以數據化，利用資料庫分片來來增加實例數，從而增加吞吐量。
docker 適合跑輕量級或分布式資料庫，當 docker 服務掛掉，會自動啟動新容器，而不是繼續重啟容器服務。
資料庫利用中間件和容器化系統能夠自動伸縮、容災、切換、自帶多個節點，也是可以進行容器化的。
典型案例： 同程旅遊、京東、阿里的資料庫容器化都是不錯的案例，大家可以自行去查看。
原文作者：老王談運維
原文連結：https://www.toutiao.com/i6675622107390411276? wid=1640184427889