Rocket.Chat Docker Compose 自架完整教學

建置內容

一套完全由你擁有的私人團隊聊天系統：在自有 VPS 上透過 Docker Compose 執行 Rocket.Chat，使用 TLS termination，所有訊息都儲存在 MongoDB 資料庫中，可供你備份與搬遷。Rocket.Chat 是成熟的開放原始碼 Slack 與 Teams 替代方案，提供頻道、直接訊息、討論串、檔案分享，以及語音與視訊功能，全部執行於由你租用並控管的硬體上。不過，它不是唯一可靠的選項。如果你仍在選擇，Mattermost、Rocket.Chat、Synapse 與 Zulip 比較會依照日後最容易造成問題的項目進行比較：RAM、資料庫、行動推播、SSO 與升級。應用程式本身只需單一容器，幾分鐘內即可啟動。實際發生的問題大多位於旁邊的資料庫，因此本指南大部分內容都與 MongoDB 有關，尤其是第一​次使用時最容易令人意外的一項要求：Rocket.Chat 無法連線至獨立執行的 MongoDB。它需要 replica set，即使該「set」只有單一節點也是如此。

先備妥條件，以及沒人告訴你的 RAM 計算方式

請如實評估伺服器規格。小型團隊的實際最低需求是 2 vCPU 和 4 GB RAM。Rocket.Chat 的 Node.js 程序本身約需 1 到 1.5 GB，而 MongoDB 的 WiredTiger 快取預設取以下兩者中較大者：總 RAM 扣除 1 GB 後的 50%，或 0.256 GB。此預設值假設 mongod 獨占整台機器：它是根據總 RAM 計算，不會考慮 Node 已使用的記憶體，因此在 4 GB 主機上會得到 1.5 GB，在 2 GB 主機上約為 0.5 GB。這些記憶體還不包括 Node 的 heap、mongod 在快取之外使用的記憶體，以及作業系統本身的需求。在 2 GB VPS 上，兩者開機時尚可容納，但實際流量一到就會互相爭用：MongoDB 擴大快取，Node 擴大 heap，核心耗盡可用頁面，out-of-memory killer 會終止記憶體占用最大的程序，通常是 mongod。容器會輸出 Killed，Docker 隨即重新啟動容器，結果聊天伺服器在本應能輕鬆處理的負載下，每隔幾分鐘就中斷。2 GB 適合兩人試用；不適合作為團隊伺服器。請從 4 GB 開始；如果預期有數十名同時上線的使用者、視訊通話或持續增加的上傳紀錄，請提供 8 GB。也要為主機需要承載的其他服務預留資源：若在同一台 VPS 上部署 Notion 風格的 AFFiNE 工作區，就會多出 4 個容器競爭相同的記憶體頁面，因此這些容器所需的 RAM 必須額外加上，而不是從 Rocket.Chat 的配置中挪用。

開始之前，還需要先準備 3 項條件。第一是網域名稱，並建立指向 VPS 公開 IP 的 A record；Rocket.Chat 的即時功能和行動用戶端需要穩定的主機名稱，不能只使用 IP。第二是在伺服器防火牆和供應商的網路防火牆上開放 80 和 443 埠；多數控制面板中的供應商防火牆是獨立的控制項。第三是全新的 Ubuntu 24.04 KVM VPS，並具備 root 或 sudo 權限。如果你仍在評估聊天伺服器是否適合作為第一個部署的服務，請參閱 2026 年值得自行託管的服務指南，其中整理了各項取捨。

安裝 Docker engine 與 Compose plugin

請使用 Docker 自有的 apt repository，不要使用 Ubuntu 提供的 docker.io package，也不要使用已過時的獨立 docker-compose Python binary。現代 Compose 是 Docker plugin，使用方式是 docker compose，中間以空格分隔，而不是連字號。舊版 docker-compose v1 已終止生命週期，無法正確處理下方的 healthcheck 與相依性語法。

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

確認這兩個元件都已存在：

sudo docker version
sudo docker compose version

docker compose version 顯示版本行才是需要確認的結果。目前版本會顯示 Docker Compose version v5.x（v5.6.0 於 2 October 2026 發布；截至 2026-10-10，這是最新版本）；較舊的安裝仍可能顯示 v2.x，而 Docker 同時支援這兩個版本。Docker 說明 Compose v5 在功能上與 v2 相同，改用 v5 編號是為了避免與舊版 v2 和 v3 compose file format 混淆，因此本指南使用任一版本皆可。如果出現 docker: 'compose' is not a docker command 錯誤，表示 plugin 尚未安裝。後續操作將因此出現難以判斷的錯誤，請在此處先修正。

Compose 檔案：MongoDB 作為單節點 replica set

這是最容易出錯的部分，請仔細閱讀。Rocket.Chat 使用 MongoDB 的 change streams，即時將新訊息推送給已連線的用戶端，而 change streams 只有在 replica set 上才能使用。若將 Rocket.Chat 指向一般的獨立 mongod，它會成功連線，但無法開啟 change stream，之後不斷重新啟動。解決方式並不複雜：執行單一的一般 MongoDB 容器，但以 --replSet 啟動，接著初始化一個單成員的 set。

建立工作目錄與 compose.yml：

services:
  mongodb:
    image: mongo:8.0
    restart: always
    command: ["mongod", "--replSet", "rs0", "--bind_ip_all", "--oplogSize", "128"]
    volumes:
      - mongodb_data:/data/db
      - mongodb_config:/data/configdb
    healthcheck:
      test: ["CMD", "mongosh", "--quiet", "--eval", "db.adminCommand('ping')"]
      interval: 10s
      timeout: 10s
      retries: 12

  rocketchat:
    image: registry.rocket.chat/rocketchat/rocket.chat:8.5.1
    restart: always
    depends_on:
      mongodb:
        condition: service_healthy
    environment:
      MONGO_URL: "mongodb://mongodb:27017/rocketchat?replicaSet=rs0"
      MONGO_OPLOG_URL: "mongodb://mongodb:27017/local?replicaSet=rs0"
      ROOT_URL: "https://chat.example.com"
      PORT: "3000"
    ports:
      - "127.0.0.1:3000:3000"

volumes:
  mongodb_data:
  mongodb_config:

這裡有幾項設定是刻意安排的。Rocket.Chat 的連接埠發布至 127.0.0.1:3000，而不是 0.0.0.0。應用程式本身沒有 TLS，因此只有同一台主機上的反向代理應能連線；若綁定到所有介面，未加密的登入頁面就會直接暴露在公開網際網路上。MongoDB 完全不發布至主機，只能透過 Compose 的內部網路，以 mongodb 這個名稱連線；這正是 MONGO_URL 使用的主機名稱。MONGO_URL 搭配 ?replicaSet=rs0，明確指定 set 名稱；MongoDB 建議設定此項，以確保不同驅動程式的行為一致。不設定本身不會造成問題：directConnection 預設為 false，因此只要初始化 set 時使用 Rocket.Chat 能解析的主機名稱，驅動程式仍會找到 replica set，並將操作傳送至 primary；下一節會處理這項設定。MONGO_OPLOG_URL 指向存放 oplog 的 local 資料庫；新版 Rocket.Chat 偏好使用 change streams，但設定此項沒有副作用，也能讓較舊的程式碼路徑正常運作。depends_on 使用 condition: service_healthy，因此 Compose 會先等待 MongoDB 回應 ping，才啟動 Rocket.Chat；這就是 healthcheck 的用途。

請在兩個映像上都固定實際的版本標籤，包含 mongo:8.0，以及此處所示的明確 Rocket.Chat 版本，例如 8.5.1；絕不要使用 :latest，因為這會將無人值守的 docker pull 變成意外且無法遷移的升級。固定版本前，請先確認目前穩定的 Rocket.Chat 版本，以及該版本支援的 MongoDB 版本。Rocket.Chat 會為每個版本發布可由機器讀取的資訊文件：對 8.5.1 而言，curl -s https://releases.rocket.chat/8.5.1/info | jq '{compatibleMongoVersions, lts}' 會回傳 compatibleMongoVersions: ["8.0"]，因此 mongo:8.0 是唯一受支援的引擎；文件也會提供 lts 旗標，指出該版本是否為適合固定在伺服器上的 long-term-support 版本，讓你不必持續手動維護。並非所有專案都會發布具版本標記的映像；遇到這種情況，應改為固定來源版本：自行託管 openGym 運動追蹤器表示簽出特定的 git tag 並據此建置，而不是跟隨持續變動的分支。

初始化副本集

啟動堆疊：

sudo docker compose up -d

Rocket.Chat 會立即崩潰，Docker 也會持續重新啟動它。這是預期行為，因為副本集尚未建立。請手動建立一次：

sudo docker compose exec mongodb mongosh --eval 'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongodb:27017"}]})'

正確結果為 { ok: 1 }。幾秒內，這個單一節點會自行選出為 primary；使用以下指令確認：

sudo docker compose exec mongodb mongosh --quiet --eval 'rs.status().members[0].stateStr'

你應看到 PRIMARY。本頁最重要的細節是 host: "mongodb:27017" 引數。如果執行不含 members 清單的基本 rs.initiate()，MongoDB 會使用容器的內部主機名稱公布副本集，例如隨機產生的雜湊值 a1b2c3d4e5f6。Rocket.Chat 從自己的容器連線時無法解析該名稱，因此 MongoDB driver 的 DNS 解析會失敗，並持續記錄 MongoServerSelectionError: getaddrinfo ENOTFOUND a1b2c3d4e5f6。務必使用與 MONGO_URL 相符的明確服務名稱來初始化。

首次啟動：監看服務啟動

設定為 primary 後，Rocket.Chat 下一次重新啟動時就能順利連線，並開始首次啟動時的 migration。查看日誌：

sudo docker compose logs -f rocketchat

請等待啟動橫幅出現：

+--------------------------------------------+
        SERVER RUNNING
   Rocket.Chat Version: 8.5.1
        NodeJS Version: 22.22.3 - x64
+--------------------------------------------+

首次啟動需要較長時間，因為應用程式會執行資料庫 migration 並建立索引。因此，請先等待 1 到 2 分鐘，再判斷是否發生問題。如果日誌持續重複 MongoServerSelectionError: Server selection timed out after 30000 ms，且拓撲描述的類型為 ReplicaSetNoPrimary，表示 replica set 尚未初始化；如果日誌持續對隨機 hash 重複 getaddrinfo ENOTFOUND，表示初始化時使用了錯誤的主機。無論是哪種情況，都請返回上一步。看到 SERVER RUNNING 後，表示 Rocket.Chat 正在 127.0.0.1:3000 上監聽，此時即可為它設定正式主機名稱與 TLS。

置於 TLS 後方

絕不要讓 Rocket.Chat 透過純 HTTP 對外提供服務。只要曾經透過 http:// 登入一次，就等於把管理員密碼交給路徑上的任何人。請在同一台主機上的反向代理終止 TLS，再將流量轉送至 127.0.0.1:3000。有兩點很重要：代理必須轉送 WebSocket upgrade 標頭，因為 Rocket.Chat 是即時應用程式，缺少這些標頭就會失效；此外，容器的 ROOT_URL 必須與使用者輸入的公開 HTTPS 位址完全一致。

先建立純 HTTP 的 nginx server block，將請求代理至應用程式，並轉送 upgrade 標頭。將其儲存為 /etc/nginx/sites-available/rocketchat，建立符號連結至 sites-enabled，然後重新載入：

server {
    listen 80;
    server_name chat.example.com;

    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

目前先讓它使用 80 埠。包含 listen 443 ssl; 且沒有憑證的設定區塊甚至無法通過 sudo nginx -t。重新載入 nginx（sudo nginx -t && sudo systemctl reload nginx），然後申請憑證。在 Ubuntu 上，最簡單的方法是使用 使用 Certbot 和 nginx 申請 Let’s Encrypt TLS 憑證：certbot --nginx 會直接改寫上述設定區塊，加入 listen 443 ssl;、ssl_certificate 行，以及自動將 80 轉向 443 的設定，並為你排程續期。如果你已經透過同一個代理管理多個容器，使用 Traefik 為多個 Docker 應用程式自動設定 TLS 會更簡潔；只要在 rocketchat 服務加入 router 和 service labels，Traefik 就會代為申請及續期憑證，完全不需要 nginx block。無論採用哪種方式，請在 compose.yml 將 ROOT_URL 設為 https://chat.example.com，然後重新執行 sudo docker compose up -d，讓容器套用變更。若你希望伺服器只能從自己的網路存取，而不是公開網際網路，請在前方配置 VPS 上的自架 WireGuard VPN，並將代理繫結至 VPN 通道位址。

首次執行設定精靈

瀏覽至 https://chat.example.com，Rocket.Chat 會引導您完成簡短的設定精靈。首先設定 管理員帳號，包括真實姓名、使用者名稱、電子郵件地址及強密碼；這是目前唯一存在的帳號，請務必妥善保管。接著設定 組織與伺服器資訊，包括名稱、產業、規模、網站名稱及預設語言；這些設定僅影響外觀，填妥後繼續即可。接下來是實際重要的選擇：向 Rocket.Chat Cloud 註冊此工作區，或維持 獨立模式。

註冊後可透過 Rocket.Chat 的 gateway 啟用行動推播通知，並使用附加元件市集，但代價是與 Rocket.Chat cloud 建立控制平面關係；透過 gateway 發送的推播也會計入工作區的每月額度。獨立模式可讓伺服器完全保持私有，且不依賴外部服務，但官方 iOS 和 Android 應用程式將無法再接收推播通知，因為 Rocket.Chat 文件指出，這些應用程式只能搭配其 cloud gateway 使用，而 gateway 不會在未註冊的工作區上運作。替代方式是自行建立行動應用程式的白標版本：在 Push 設定中關閉 gateway，填入您自己的 APNs 憑證和 Firebase Cloud Messaging 憑證，並要求使用者安裝您的應用程式，而非官方應用程式。如果隱私是主要考量，且使用者主要使用網頁應用程式，或您準備自行發布行動應用程式，請選擇獨立模式；如果官方應用程式的推播通知不可或缺，請選擇註冊。之後仍可在 Admin 中變更此設定。

先做好限制，再邀請其他人加入

Rocket.Chat 預設會開啟註冊功能，Registration Form 預設設為 Public，因此任何找到 URL 的人都能建立帳號。對公開主機名稱而言，這等同於直接敞開入口。前往 Admin → Settings → Accounts → Registration，將 Registration Form 設為 Disabled，如此即可手動建立帳號或使用邀請連結；也可以設為 Secret URL。在同一頁關閉 Allow Anonymous Read 和 Allow Anonymous Write，除非你確實需要公開的唯讀頻道。如果逐一手動建立帳號過於繁瑣，而且這不是團隊登入的唯一服務，請將 Rocket.Chat 的 OAuth 登入導向自架的 Authentik SSO 伺服器，如此即可在同一處一次處理新進與離職人員，不必逐一修改每個應用程式。

也要決定上傳檔案的儲存位置。預設的 File Upload 儲存方式是 GridFS，會將每張圖片和每個附件直接儲存在 MongoDB 中。這種方式簡單，但代表資料庫及你建立的每個 mongodump，都會隨著使用者貼上螢幕擷取畫面而持續增長。前往 Admin → Settings → File Upload，即可將儲存方式切換為本機檔案系統或相容於 S3 的儲存貯體，並設定合理的檔案大小上限。如果團隊交換的是完整的相片庫，而不是偶爾分享螢幕擷取畫面，這些檔案應存放在專用相片伺服器，而不是聊天資料庫；PhotoPrism 與 Immich 比較會說明兩者的 RAM 成本，以及各自需要的備份命令。小型團隊使用 GridFS 沒有問題，但請注意備份會隨時間變得更大。

使用 mongodump 備份

所有資料都存放在 mongodb_data volume 中。不要在資料庫執行期間直接複製 volume。請使用 mongodump 建立一致性 dump，並將輸出串流至主機上的檔案：

sudo docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > rocketchat-$(date +%F).archive.gz

這個 gzip 壓縮封存檔包含完整的工作區：使用者、頻道、訊息、設定，以及在 uploads 保留於 GridFS 的情況下，還包括檔案。如果你已將 uploads 移至檔案系統或 S3，請另外備份該儲存區。要還原至全新的 stack，請先初始化 replica set，然後執行：

sudo docker compose exec -T mongodb mongorestore --archive --gzip --drop < rocketchat-2026-07-15.archive.gz

將封存檔複製到主機以外的位置，例如 object storage 或其他伺服器。無論選擇哪個位置，都不能讓 VPS 損毀時連同備份一併遺失，並使用 cron 每晚執行 dump。從未實際還原過的備份只是希望，不算備份。請先在一次性 VPS 上演練還原，確認程序可正常運作，再等到真正需要時才使用。

升級：固定標籤、閱讀版本說明，遵循 MongoDB 相容性矩陣

遵守兩項規則，就能讓升級流程保持單純。第一，Rocket.Chat 一次只升級一個主要版本。 Rocket.Chat 啟動時會執行結構描述遷移，其升級文件也要求跨主要版本時一律依序更新，並警告跳過主要版本可能造成嚴重的相容性問題。不要假設軟體會阻止不安全的升級：其文件沒有保證從 6.x 直接跳到 8.x 時會安全拒絕，而且遷移若中途失敗，會留下鎖定狀態，需要手動修復。將映像檔標籤更新到下一個主要版本的最新版本，閱讀該版本的版本說明以了解重大變更，執行 docker compose up -d，並監看日誌，確認遷移完成後再繼續。第二，遵循 MongoDB 相容性矩陣。 每個 Rocket.Chat 版本支援特定的 MongoDB 版本範圍，curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions 會告訴你適用哪些版本。升級 MongoDB 時，例如從 7.0 升級到 8.0，也要一次升級一個主要版本，並在每次升級後設定功能相容性版本。在 MongoDB 8.0 上，該命令需要明確指定 confirm: true，否則會拒絕執行，並顯示訊息要求你重新執行命令並加入確認旗標：

sudo docker compose exec mongodb mongosh --eval 'db.adminCommand({setFeatureCompatibilityVersion: "8.0", confirm: true})'

每次升級任一元件前，都要先執行 mongodump。這就是完整的保險措施。

故障模式與確切字串

Rocket.Chat 在 docker compose up 後立即反覆重新啟動，且 docker compose logs rocketchat 填滿 MongoServerSelectionError。 MongoDB 正在執行，但 driver 無法選取 primary；確切字串會指出設定錯誤。Server selection timed out after 30000 ms 顯示拓撲類型為 ReplicaSetNoPrimary，表示你尚未執行 rs.initiate()，因此 replica set 尚未設定。getaddrinfo ENOTFOUND 後接隨機 hash，表示你未指定明確的 host: "mongodb:27017" 就進行初始化，因此 MongoDB 公告了無法解析的容器主機名稱。使用 sudo docker compose exec mongodb mongosh --eval 'rs.status()' 進行診斷：若出現 MongoServerError: no replset config has been received 錯誤，請初始化 replica set；若顯示某個成員的 name 是隨機 hash，請改用服務名稱重新初始化。

Web UI 可以載入，但登入一直轉圈且永遠無法完成。 開啟瀏覽器主控台，你會看到 WebSocket connection to 'wss://chat.example.com/websocket' failed。這幾乎總是 ROOT_URL 不一致，或代理未轉送 upgrade 標頭所造成。確認 ROOT_URL 等於包含 https:// 的完整公開位址，並確認你的 nginx location 區塊使用 Upgrade 和 Connection "upgrade" 設定 proxy_http_version 1.1。修改任一項後，重新執行 docker compose up -d。

容器持續停止，且 docker compose ps 顯示 Restarting。 docker compose logs 在中途截斷，sudo dmesg | tail 顯示 oom-killer 造成的 Out of memory: Killed process 12345 (mongod)；結束代碼為 137。表示主機的 RAM 不足。真正的解決方式是使用更大的 VPS，最低需要 4 GB。暫時可增加 swap，並在 MongoDB 的 command 中使用 --wiredTigerCacheSizeGB 限制快取；設定值應低於預設值，而不是高於預設值。例如，4 GB 主機可使用 1（預設值為 1.5），2 GB 主機可使用 0.3（預設值約為 0.5）。但在實際負載下，swap 只能延後下一次 OOM：

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

docker compose up 失敗並顯示 Error response from daemon: driver failed programming external connectivity ... bind: address already in use。 已有其他程序占用 port 3000，通常是先前未正常停止的 Rocket.Chat 容器，或其他應用程式。使用 sudo ss -ltnp | grep :3000 找出占用者，停止該程序或容器；或者將映射的主機端改為 127.0.0.1:3001:3000，並同步更新代理的 proxy_pass。

FAQ

Rocket.Chat 真的需要 MongoDB replica set 嗎？

需要，即使只有一台伺服器和一個資料庫節點也一樣。Rocket.Chat 透過 MongoDB change streams 即時傳送訊息，而 change streams 只有 replica set 支援，獨立執行的 mongod 無法建立 change stream。您不需要多台機器；只要使用 --replSet rs0 啟動一個 MongoDB 容器，再以 rs.initiate() 初始化單成員 replica set 即可。略過這個步驟後，driver 就找不到 primary，Rocket.Chat 會因 MongoServerSelectionError: Server selection timed out 持續重新啟動，始終無法完成啟動。

自架 Rocket.Chat 需要多少 RAM？

實務上至少準備 4 GB，忙碌團隊則準備 8 GB。Rocket.Chat 的 Node 程序約使用 1 至 1.5 GB，而 MongoDB 預設的 WiredTiger cache 大小是「總 RAM 減去 1 GB」後的一半，計算時假設伺服器上沒有其他程序執行。在 2 GB 的伺服器上，該 cache、Node heap 與 mongod 本身的額外耗用會互相爭用記憶體；只要有實際負載，out-of-memory killer 就會終止 mongod，並在日誌中顯示 Killed，退出碼為 137。2 GB 只足以讓幾位測試使用者評估軟體。

如何讓 Rocket.Chat 使用 HTTPS？

在同一台 VPS 上執行 reverse proxy，由它終止 TLS，並將請求轉送至 127.0.0.1:3000；同時將容器的 ROOT_URL 設為公開的 https:// 位址。代理必須轉送 WebSocket upgrade 標頭，否則登入會停滯。使用 nginx 搭配 Certbot 是單一應用程式最簡單的設定；若要在同一個代理後方執行多個容器，並需要自動管理憑證，Traefik 會更適合。

如何備份自架的 Rocket.Chat？

使用 mongodump 建立一致的資料庫 dump，不要直接複製 volume：docker compose exec -T mongodb mongodump --db rocketchat --archive --gzip > backup.archive.gz。該 archive 包含使用者、頻道、訊息和設定；如果檔案仍儲存在 GridFS，也會包含上傳的檔案。將 archive 複製到伺服器外部，使用 cron 每晚自動執行，並在臨時伺服器上演練 mongorestore，確認還原確實可用。

如何升級 Rocket.Chat，避免破壞 MongoDB？

每次只升級 Rocket.Chat 一個 major version。它會在啟動時執行 migrations，而官方文件警告，跳過 major version 可能造成嚴重的相容性問題，不會保證程序會阻止您這麼做。更新固定的 image tag 前，先閱讀各版本的 release notes。使用 curl -s https://releases.rocket.chat/<version>/info | jq .compatibleMongoVersions 檢查目標版本支援的 MongoDB 版本；升級 MongoDB 時，每次只升級一個 major version，並在每次升級後使用 confirm: true 設定 setFeatureCompatibilityVersion。務必先建立 mongodump。