MySQL 到底能不能放到 Docker 里跑

　　Close親愛的讀者：我們最近添加了一些個人消息定制功能，您只需選擇感興趣的技術主題，即可獲取重要資訊的郵件和網頁通知。

　　Talk is cheap，show me the demo。MySQL 到底能不能放到 Docker 里跑？同程旅游目前已經有超過一千個 MySQL 實例安全穩定地跑在 Docker 平臺上。

　　前言

　　前幾月經常看到有 MySQL 到底能不能放到 Docker 里跑的各種討論。這樣做是錯的！這樣做是對的！說錯的理由也說了一大堆MySQL文章入庫助手，說對的思想也很明確。大家都有道理。但是我本人覺得這樣的討論落地意義不大。因為對與錯還是要實踐來得出的。

　　所以同程旅游也很早開始了 MySQL 的 Docker 化實踐，到目前已經有超一千多個 MySQL 實例在 Docker 平臺安全穩定地跑著，DB 運維能力發生了質的提高（DBA 再也不用擔心刪庫跑路了）。

　　相關廠商內容

　　一堂課教你看懂技術創新與商業模式

　　面向未來的原生化Web開發 Airbnb的閃訂功能和增長策略 Dubbo開源現狀與未來規劃 Apache Kafka的過去mysql文件入庫工具 ，現在，和未來

　　相關贊助商

　　當然這樣是不是可以證明之前的討論結論——是對的mysql文章入庫軟件 。我想也不一定，因為我們還只是一只在學飛行的小鳥，還要更多的學習，所以我們特將我們在 MySQL 的 Docker 化上的實踐分享給大家。

　　背景介紹

　　同程旅游早期的數據庫都以 MSSQL 為主，這個產品有個特點就是 UI 操作很棒。但是批量和自動化管理很難做，人力的工作很多。后來逐漸替換為 MySQL 后也是按照傳統的運維方式管理。導致大部分的工作需要人肉運維。

　　當然像我們早期使用過的 MSSQL 也是有優點的：就是單機性能比較好，在當年那個資源不夠的年代里我們常可以在高可用的實例上運行多個庫。這種情況下物理機數量與實例數量還是比較可控的，相對數量比較少，人肉運維完全可以應對。

　　但是 MSSQL 的缺陷也很多，比如做水平拆分比較困難，導致數據庫成為系統中最大的一個瓶頸。但在我們使用 MySQL+ 中間件（我們做這個中間件也是下了不少心思的，以后可以分享一下）做水平拆分后就開始解決了這個瓶頸mysql文章入庫軟件。

　　水平拆分的引入也帶來了一個小缺點，就是會造成數據庫實例數量大幅上升。舉個例子我們做 1024 分片的話一般是做 32 個 node，一主一從是必須的（大部分情況是一主兩從），那么至少 64 個實例，再加上應急擴展和備份用的節點那就更多了（中間件的開發者更希望是 1024 片就是 1024 個實例）。

　　一次上線做一個 32node 分片擴展從庫，兩個 DBA 足足花了 4 個小時。另外，如果做單機單實例那肯定更不行了，別的不說，成本也會是個大問題，且物理機的資源也未能最大化利用。況且因為 MySQL 單體的性能沒優勢所以分片居多所以大部分情況下并不是每個庫都能跑滿整個物理機的。即使有部分能跑滿整機資源的庫，它的多節點備份，環境一至性和運維動作統一等問題也會讓 DBA 一頭糟，忙碌又容易出錯的工作其實是無意義的。

　　有了單機多實例運行 MySQL 實例的需求。單機多實例要思考的主要問題就是如果進行資源隔離和限制，實現方案有很多，怎么選mysql文章入庫軟件？KVM，Docker，Cgroups 是目前的可以實現隔離主流方案。

　　KVM 對一個 DB 的隔離來說太重了，性能影響太大，在生產環境用不合適。這是因為 MySQL 運行的就是個進程而且對 IO 要求比較高，所以 KVM 不滿足要求 (雖然優化以后 IO 能有點提升)。

　　cgroups 比較輕，雖然隔離性不是很高，但對于我們的 MySQL 多實例隔離來說是完全夠用了（Docker 的資源限制用的就是 cgroups）。但是我們還想針對每個 MySQL 實例運行額外的管理進程 (比如監控等等)。用 cgroups 實現起來會比較復雜，并且我們還想讓實例管理和物理機區分開，那 cgroups 也放棄。

　　至于 Docker，那就很不錯了，那些裸用 cgroups 的麻煩它都給搞定了。并且有 API 可以提供支持，開發成本低。而且我們可以基于 Docker 鏡像來做部署自動化，那么環境的一至性也可輕松解決。所以最終我們選擇了 Docker 作為云平臺的資源隔離方案 (當然過程中也做了很多性能、穩定性等的適配工作，這里就不贅述了)。