🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 09月20日

為什麼不建議在 Docker 中跑 MySQL？

前言

今天我們來聊聊一個很有趣的話題：為什麼我不建議在 Docker 中運行 MySQL 數據庫？

有些小夥伴在工作中可能為了部署方便，習慣將所有組件都容器化，但數據庫真的適合放在容器裡嗎？

今天就專門跟大家一起聊聊這個話題，希望對你會有所幫助。

最近準備面試的小夥伴，可以看一下這個寶藏網站（Java 突擊隊）：www.susan.net.cn，裡面：面試八股文、場景設計題、面試真題、項目實戰、工作內推什麼都有。

一、容器化與數據庫：天生的矛盾？

讓我們先思考一個基本問題：容器設計的初衷是什麼？

Docker 官方網站明確說明："容器是進程的隔離環境，適合運行無狀態服務"。

而 MySQL 正是一個典型的有狀態服務。

從這張圖可以清晰看出，MySQL 作為有狀態服務，在容器化環境中面臨著獨特的挑戰。

二、性能問題：I/O 瓶頸無法避免

有些小夥伴在工作中可能遇到過 MySQL 在 Docker 中性能下降的問題，這其實不是偶然現象。

2.1 存儲 I/O 性能損耗

Docker 的存儲驅動層會增加額外的 I/O 開銷。我們來看一個簡單的性能測試對比：

# 測試原生 Linux 磁碟寫入速度
dd if=/dev/zero of=test.bin bs=1G count=1 oflag=direct

# 測試 Docker 容器內磁碟寫入速度
docker run --rm -it ubuntu dd if=/dev/zero of=test.bin bs=1G count=1 oflag=direct

在實際測試中，Docker 內部的 I/O 性能通常比原生系統低 10%-20%。

對於 MySQL 這種 I/O 密集型的應用，這種性能損耗是致命的。

2.2 網絡性能開銷

雖然 Docker 的網絡性能已經大幅改善，但仍然存在額外開銷：

每條網絡請求在 Docker 中都需要經過額外的網絡堆疊處理，增加了延遲和 CPU 開銷。

三、數據持久化：容器與數據的生命週期管理

數據丟失風險是 Docker 中運行 MySQL 最大的痛點。

3.1 數據卷的陷阱

很多教程會告訴你使用 Volume 來持久化數據：

docker run -d \
  --name mysql \
  -v mysql_data:/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=password \
  mysql:8.0

但這並不能完全解決問題。考慮以下場景：

容器意外刪除：docker rm -f mysql 然後數據卷變成孤兒卷
備份恢復複雜：需要同時備份容器配置和數據卷
遷移困難：數據卷在不同主機間的遷移複雜

3.2 數據一致性挑戰

MySQL 的寫操作需要保證數據安全落盤，但在容器環境中：

// 模擬 MySQL 寫操作流程
public class MySQLWriteProcess {
    public void writeData(Transaction transaction) {
        // 1. 寫入 redo log
        writeRedoLog(transaction);

        // 2. 刷新到磁碟
        flushToDisk(); // 這裡受容器 I 影響

        // 3. 確認提交
        confirmCommit();
    }

    // 容器崩潰可能導致這一步失敗
    private void flushToDisk() {
        // 調用系統 fsync()
        // Docker 存儲驅動增加額外層
        System.callFsync();
    }
}

容器崩潰可能導致數據沒有完全持久化到物理磁碟。

四、資源管理：無法精確控制

4.1 記憶體管理問題

MySQL 的性能高度依賴正確的記憶體配置，但 Docker 的記憶體限制可能導致問題：

# 限制容器記憶體為 2G
docker run -d --memory=2g --memory-swap=2g mysql

這種情況下，MySQL 可能因為記憶體不足而頻繁使用 swap，導致性能急劇下降。

4.2 CPU 資源競爭

在容器環境中，CPU 資源的分配和隔離不如物理機穩定：

當宿主機資源緊張時，容器間的 CPU 競爭會導致 MySQL 性能不穩定。

五、高可用與故障恢復：複雜度的指數級增長

有些小夥伴在設計系統時，往往低估了數據庫高可用的複雜度。

5.1 複製與集群的挑戰

在 Docker 中部署 MySQL 集群需要解決很多額外問題：

# docker-compose.yml 部分配置
version: '3.8'
services:
  mysql-master:
    image: mysql:8.0
    networks:
      - mysql-cluster
    environment:
      - MYSQL_REPLICATION_MODE=master
      - MYSQL_REPLICATION_USER=repl
      - MYSQL_REPLICATION_PASSWORD=password
  mysql-slave:
    image: mysql:8.0
    networks:
      - mysql-cluster
    environment:
      - MYSQL_REPLICATION_MODE=slave
      - MYSQL_REPLICATION_MASTER=mysql-master

這種配置面臨的問題：

網絡延遲：容器間網絡通信增加複製延遲
服務發現：容器 IP 變化導致複製配置失效
腦裂風險：容器調度可能導致集群腦裂

5.2 備份恢復的複雜性

在容器環境中實現可靠的備份策略更加複雜：

六、安全性與隔離性：隱藏的風險

6.1 安全隔離不足

容器提供的隔離性不如虛擬機，MySQL 數據庫可能面臨安全風險：

內核共享：所有容器共享宿主機的內核，存在漏洞擴散風險
資源洩漏：通過 /proc 或 /sys 可能洩漏其他容器信息
特權升級：配置不當可能導致容器逃逸

6.2 網絡安全隱患

Docker 的網絡模型增加了攻擊面：

# 錯誤的網絡配置示例
docker run -d \
  --network=host \  # 共享主機網絡命名空間
  -p 3306:3306 \
  mysql

這種配置雖然性能好，但嚴重降低了安全性。

七、監控與診斷：可見性降低

7.1 監控挑戰

在容器中監控 MySQL 比在物理機上更複雜：

# 容器內監控 MySQL
docker exec mysql sh -c "mysqladmin -uroot -ppassword status"

這種方法的問題：

需要進入容器執行命令
監控指標受容器資源限制影響
難以區分是 MySQL 問題還是容器環境問題

7.2 鑑斷困難

當出現性能問題時，鑑斷容器內的 MySQL 更加困難：

需要同時排查容器環境和 MySQL 本身的問題，複雜度大大增加。

最近建了一些工作內推群，各大城市都有，歡迎各位 HR 和找工作的小夥伴進群交流，群裡目前已經收集了不少的工作內推崗位。加蘇三的微信：li_su223，備註：掘金+所在城市，即可進群。

八、什麼時候可以在 Docker 中運行 MySQL？

雖然我不建議在生產環境這樣做，但在某些場景下還是可以的：

8.1 開發測試環境

在開發環境中使用 Docker 運行 MySQL 有很多好處：

# docker-compose.dev.yml
version: '3.8'
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: myapp
    ports:
      - "3306:3306"
    volumes:
      - ./data:/var/lib/mysql
      - ./config:/etc/mysql/conf.d

開發環境的優點：

快速搭建和銷毀
環境一致性
易於版本切換

8.2 特定生產場景

在滿足以下條件時，可以考慮在生產環境使用 Docker 運行 MySQL：

數據重要性低：可以接受數據丟失的場景
資源充足：宿主機資源遠遠超過 MySQL 需求
有專業團隊：具備深度容器和 MySQL 知識的團隊
完善的監控：有全面的監控和告警系統

九、生成環境推薦方案

對於生產環境，我推薦以下部署方案：

9.1 傳統物理機部署

9.2 Kubernetes StatefulSet 方案

如果必須在容器環境運行，建議使用 Kubernetes StatefulSet：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "ssd"
      resources:
        requests:
          storage: 100Gi