Home
Blog
如何安全地從 Milvus 2.5.x 升級到 Milvus 2.6.x

如何安全地從 Milvus 2.5.x 升級到 Milvus 2.6.x

Tutorials

December 25, 2025

Yiqing Lu

Milvus 2.6已推出一段時間，事實證明這是專案向前邁進的穩健一步。這個版本帶來了精進的架構、更強的即時效能、更低的資源消耗，以及在生產環境中更精明的擴充行為。其中許多改進直接來自使用者的回饋意見，2.6.x 的早期使用者已報告在繁重或動態工作負載下，搜尋速度明顯加快，系統效能也更可預期。

對於正在執行 Milvus 2.5.x 並評估轉移至 2.6.x 的團隊而言，本指南是您的起點。它分解了架構上的差異，強調 Milvus 2.6 中引入的關鍵功能，並提供了一個實用的逐步升級路徑，旨在將操作中斷降至最低。

如果您的工作負載涉及即時管道、多模態或混合搜尋，或大型向量作業，本部落格將協助您評估 2.6 是否符合您的需求，如果您決定繼續升級，請放心升級，同時維持資料完整性與服務可用性。

從 Milvus 2.5 到 Milvus 2.6 的架構變更

在深入了解升級工作流程之前，讓我們先了解 Milvus 2.6 的架構如何改變。

Milvus 2.5 架構

Milvus 2.5 Architecture Milvus 2.5 架構

在 Milvus 2.5 中，串流與批次工作流程交織在多個工作節點上：

QueryNode處理歷史查詢和增量（串流）查詢。
資料節點 (DataNode) 則處理歷史資料的擷取時間沖洗和背景壓縮。

這種批次與即時邏輯的混合，使得批次工作負載難以獨立擴充。這也意味著串流狀態分散在多個元件中，造成同步延遲、故障復原複雜化，並增加作業複雜度。

Milvus 2.6 架構

Milvus 2.6 Architecture Milvus 2.6 架構

Milvus 2.6 引入了專用的StreamingNode，處理所有即時資料責任：消耗訊息佇列、寫入增量區段、提供增量查詢，以及管理基於 WAL 的復原。在隔離了串流之後，其餘的元件就扮演了更乾淨、更專注的角色：

QueryNode現在只處理歷史區段的批次查詢。
DataNode現在只處理歷史資料任務，例如壓縮和索引建立。

StreamingNode 吸收了在 Milvus 2.5 中分拆在 DataNode、QueryNode 甚至 Proxy 之中的所有與串流相關的任務，使其更加清晰，並減少了跨角色的狀態共享。

Milvus 2.5.x vs Milvus 2.6.x：逐個元件比較

	Milvus 2.5.x	Milvus 2.6.x	變更內容
協調器服務	RootCoord / QueryCoord / DataCoord (或 MixCoord)	混合協調	元資料管理與任務排程合併為單一的 MixCoord，簡化協調邏輯並減少分散式的複雜性。
存取層	代理	代理層	寫入要求只經由 Streaming Node 進行資料擷取。
工作節點	-	串流節點	專用的串流處理節點，負責所有增量 (成長區段) 邏輯，包括：- 增量資料擷取- 增量資料查詢- 將增量資料持久化到物件儲存區- 基於串流的寫入- 基於 WAL 的故障復原
	查詢節點	查詢節點	批次處理節點，僅處理歷史資料的查詢。
	資料節點	資料節點	僅負責歷史資料的批次處理節點，包括壓縮和建立索引。
	索引節點	-	索引節點合併到資料節點，簡化角色定義和部署拓樸。

簡而言之，Milvus 2.6 在串流與批次工作負載之間劃清界線，消除了 2.5 所見的跨元件糾纏，創造出更具擴充性、可維護性的架構。

Milvus 2.6 功能重點

在進入升級工作流程之前，先快速瞭解 Milvus 2.6 所帶來的功能。此版本著重於降低基礎架構成本、改善搜尋效能，以及讓大型動態 AI 工作負載更容易擴充。

成本與效率改善

主索引的RaBitQ 量化- 全新的 1 位元量化方法，可將向量索引壓縮至原始大小的1/32。結合 SQ8 reranking，可將記憶體使用量降低至 ~28%，QPS 提升 4 倍，並維持 ~95% 的召回率，大幅降低硬體成本。
BM25 最佳化全文檢索- 由稀疏術語權重向量提供原生 BM25 計分功能。與 Elasticsearch 相比，關鍵字搜尋的執行速度快 3-4 倍(某些資料集最高可達7 倍)，同時將索引大小維持在原始文字資料的三分之一左右。
JSON Path 索引與 JSON Shredding- 嵌套式 JSON 的結構化篩選現在大幅提速，而且更可預測。預先索引的 JSON 路徑可將篩選延遲時間從140 毫秒減至1.5 毫秒(P99:480 毫秒 → 10 毫秒)，使混合向量搜尋 + 元資料篩選的反應速度大幅提升。
擴充資料類型支援- 加入 Int8 向量類型、幾何欄位 (POINT / LINESTRING / POLYGON) 以及結構陣列。這些擴充支援地理空間工作負載、更豐富的元資料建模，以及更簡潔的模式。
針對部分更新的 Upsert- 現在您可以使用單一主鍵呼叫插入或更新實體。部分更新只修改所提供的欄位，減少寫入擴大，並簡化經常更新元資料或嵌入的管道。

搜尋與擷取增強功能

改進的文字處理與多語言支援：新的 Lindera 和 ICU tokenizers 改善了日文、韓文和多語言文字的處理。Jieba 現在支援自訂字典。run_analyzer 有助於調試標記化行為，而多語言分析器可確保一致的跨語言搜尋。
高精度文字配對： 短語配對強制執行有序短語查詢，並可設定斜率。新的NGRAM索引可加速 VARCHAR 欄位和 JSON 路徑上的子串和LIKE 查詢，實現快速的部分文字和模糊匹配。
時間感知（Time-Aware）和元資料感知（Metadata-Aware）重排： Decay Rankers(指數式、線性式、高斯式) 使用時間戳記調整分數；Boost Rankers應用元資料驅動的規則來提升或降低結果。兩者都有助於微調檢索行為，而無需變更您的基礎資料。
簡化模型整合與自動矢量化：與 OpenAI、Hugging Face 及其他嵌入提供者的內建整合，可讓 Milvus 在插入與查詢作業期間自動向量化文字。一般使用個案不再需要手動嵌入管道。
標量欄位的線上模式更新：無需停機或重新載入，即可在現有的資料集中新增標量欄位，隨著元資料需求的增加而簡化模式演進。
MinHash 的近似重複檢測功能： MinHash+ LSH 可在大型資料集中有效率地偵測近乎重複的資料，而無需昂貴的精確比較。

架構與擴充性升級

針對冷熱資料管理的分層儲存 ：透過 SSD 與物件儲存區分冷、熱資料；支援懶惰與部分載入；無需在本端完整載入資料集；降低資源使用率高達 50%，並加快大型資料集的載入時間。
即時串流服務：新增與 Kafka/Pulsar 整合的專用串流節點，以進行連續擷取；可立即建立索引並提供查詢功能；針對即時、快速變化的工作負載，提高寫入吞吐量並加速故障復原。
增強的擴充性與穩定性：Milvus 現在支援 100,000+ 個集合，適用於大型多租戶環境。基礎架構升級 -Woodpecker(零磁碟 WAL)、Storage v2(降低 IOPS/記憶體) 及Coordinator Merge- 可改善群集的穩定性，並可在繁重的工作負載下進行可預測的擴充。

如需 Milvus 2.6 功能的完整清單，請參閱Milvus 發行紀錄。

如何從 Milvus 2.5.x 升級到 Milvus 2.6.x

為了在升級過程中盡可能保持系統的可用性，Milvus 2.5 集群應按照以下順序升級到 Milvus 2.6。

1.先啟動串流節點

提前啟動 Streaming Node。新的Delegator(查詢節點中負責處理串流資料的元件) 必須移到 Milvus 2.6 串流節點。

2.升級 MixCoord

將協調器元件升級為MixCoord。在這個步驟中，MixCoord 需要偵測 Worker Node 的版本，以便處理分散式系統內的跨版本相容性。

3.升級查詢節點

查詢節點的升級通常需要較長的時間。在這個階段，Milvus 2.5 資料節點和索引節點可以繼續處理 Flush 和索引建立等作業，有助於在查詢節點升級時減少查詢端的壓力。

4.升級資料節點

一旦 Milvus 2.5 DataNodes 離線，Flush 作業變得不可用，而 Growing Segments 中的資料可能會繼續累積，直到所有節點完全升級至 Milvus 2.6。

5.升級代理伺服器

將 Proxy 升級到 Milvus 2.6 後，Proxy 上的寫入作業將一直不可用，直到所有群集元件都升級到 2.6。

6.移除索引節點

當所有其他元件升級後，獨立的索引節點就可以安全地移除。

注意事項：

從 DataNode 升級完成到 Proxy 升級完成，Flush 作業無法使用。
從第一個 Proxy 升級到所有 Proxy 節點升級為止，某些寫入作業無法使用。
當直接從 Milvus 2.5.x 升級到 2.6.6，由於 DDL 框架的變化，在升級過程中 DDL（數據定義語言）操作不可用。

如何使用 Milvus Operator 升級到 Milvus 2.6

Milvus Operator是一個開放原始碼的 Kubernetes 操作者，提供可擴充、高可用性的方式，在目標 Kubernetes 集群上部署、管理和升級整個 Milvus 服務堆疊。由 Operator 管理的 Milvus 服務堆疊包括

Milvus 核心元件
所需的依賴項目，例如 etcd、Pulsar 和 MinIO

Milvus Operator 遵循標準的 Kubernetes Operator 模式。它引入 Milvus 自訂資源 (CR)，描述 Milvus 叢集的理想狀態，例如版本、拓樸和配置。

控制器會持續監控群集，並將實際狀態與 CR 中定義的理想狀態進行協調。當進行變更（例如升級 Milvus 版本）時，操作員會以受控且可重複的方式自動套用這些變更，以實現自動升級和持續的生命週期管理。

Milvus 自訂資源 (CR) 實例

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-milvus-mansion    
  namespace: dev       
spec:
  mode: cluster                  # cluster or standalone
  # Milvus Components
  components:
    image: milvusdb/milvus:v2.6.5
    imageUpdateMode: rollingUpgrade 
    proxy:                   
      replicas: 1          
    mixCoord:              
      replicas: 1           
    dataNode:               
      replicas: 1          
    queryNode:              
      replicas: 2           
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"  
  # Dependencies, including etcd, storage and message stream
  dependencies:
    etcd:                   
      inCluster:
        values:
          replicaCount: 3    
    storage:                 
      type: MinIO
      inCluster:
        values:
          mode: distributed     
    msgStreamType: pulsar    
    pulsar:
      inCluster:
        values:
          bookkeeper:
            replicas: 3   
  # Milvus configs
  config:
    dataCoord:
      enableActiveStandby: true

使用 Milvus Operator 從 Milvus 2.5 滾動升級到 2.6

Milvus Operator 提供內建支援，在群集模式下從 Milvus 2.5 滾動升級到 2.6，調整其行為以考量 2.6 中引入的架構變更。

1.升級情境偵測

在升級過程中，Milvus Operator 會根據叢集規格確定目標 Milvus 版本。其方法如下

檢查spec.components.image 中定義的映像標籤，或
讀取在spec.components.version

然後，操作員將此所需版本與目前執行的版本（記錄在status.currentImage 或status.currentVersion 中）進行比較。如果目前版本為 2.5，而所需版本為 2.6，則操作員將此升級識別為 2.5 → 2.6 升級方案。

2.滾動升級執行順序

當偵測到 2.5 → 2.6 升級，且升級模式設定為滾動升級 (spec.components.imageUpdateMode: rollingUpgrade ，這是預設值)，Milvus Operator 會自動按照與 Milvus 2.6 架構一致的預先定義的順序執行升級：

啟動串流節點 → 升級 MixCoord → 升級查詢節點 → 升級資料節點 → 升級代理 → 移除索引節點 3.

3.自動整合協調器

Milvus 2.6 以單一的 MixCoord 取代多個協調器元件。Milvus Operator 會自動處理此架構轉換。

當spec.components.mixCoord 設定完成後，操作員會調出 MixCoord 並等待它準備就緒。當 MixCoord 完全運作後，操作者會自動關閉傳統的協調器元件-RootCoord、QueryCoord 和 DataCoord-完成遷移，不需要任何手動介入。

從 Milvus 2.5 升級到 2.6 的步驟

1.升級 Milvus Operator 到最新版本 (在本指南中，我們使用1.3.3 版本，這是撰寫本指南時的最新版本。)

# Option 1: Using Helm
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz
 # Option 2: Using kubectl & raw manifests
 kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml

2.合併協調器元件

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}'

3.確保叢集執行 Milvus 2.5.16 或更新版本

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.5.22"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

4.升級 Milvus 至 2.6 版

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.6.5"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

如何使用 Helm 升級到 Milvus 2.6

使用 Helm 部署 Milvus 時，所有 KubernetesDeployment 資源會平行更新，沒有保證的執行順序。因此，Helm 無法嚴格控制各元件的滾動升級順序。因此，對於生產環境，強烈建議使用 Milvus Operator。

Milvus 仍可使用 Helm 從 2.5 升級到 2.6，步驟如下。

系統需求

Helm 版本：≥ 3.14.0
Kubernetes 版本: ≥1.20.0

1.將 Milvus Helm 圖表升級至最新版本。在本指南中，我們使用圖表版本 5.0.7，這是撰寫本指南時的最新版本。

helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update

2.如果集群部署了多个协调器组件，首先将 Milvus 升级到 2.5.16 或更高版本，并启用 MixCoord。

mixCoordinator
。
helm upgrade -i my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.5.22" \
  --set mixCoordinator.enabled=true \
  --set rootCoordinator.enabled=false \
  --set indexCoordinator.enabled=false \
  --set queryCoordinator.enabled=false \
  --set dataCoordinator.enabled=false \
  --set streaming.enabled=false \
  --set indexNode.enabled=true \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

3.將 Milvus 升級至版本 2.6

helm upgrade my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.6.5" \
  --set streaming.enabled=true \
  --set indexNode.enabled=false \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

Milvus 2.6 升級與作業常見問題集

Q1: Milvus Helm vs. Milvus Operator - 我應該使用哪一個？

對於生產環境，強烈建議使用 Milvus Operator。

詳情請參考官方指南：https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm

Q2: 我該如何選擇訊息佇列 (MQ)？

建議的 MQ 取決於部署模式和作業需求：

1.獨立模式：對於成本敏感的部署，建議使用 RocksMQ。

2.叢集模式

Pulsar支援 multi-tenancy，允許大型集群共享基礎架構，並提供強大的水平擴展性。
Kafka有更成熟的生態系統，在大多數主要的雲端平台上都有可管理的 SaaS 產品。

3.Woodpecker (Milvus 2.6 中引入)：Woodpecker 不需要外部訊息佇列，可降低成本和作業複雜度。

目前僅支援嵌入式 Woodpecker 模式，此模式輕巧且易於操作。
對於 Milvus 2.6 獨立部署，建議使用 Woodpecker。
對於生產集群部署，一旦即將推出的 Woodpecker 集群模式可用，建議使用該模式。

問題 3：在升級過程中，訊息佇列可以切換嗎？

目前不支援在升級過程中切換訊息佇列。未來版本將推出管理 API，支援在 Pulsar、Kafka、Woodpecker 和 RocksMQ 之間切換。

Q4: Milvus 2.6需要更新速率限制配置嗎？

不需要。現有的速率限制配置仍然有效，也適用於新的 Streaming Node。不需要變更。

Q5: 協調器合併後，監控角色或配置會改變嗎？

監控角色維持不變 (RootCoord,QueryCoord,DataCoord)。
現有的組態選項繼續照常運作。
引入了新的配置選項mixCoord.enableActiveStandby ，如果沒有明確設定，則會回退到rootcoord.enableActiveStandby 。