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 架构的变化。

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现在只处理对历史数据段的批量查询。
数据节点现在只处理历史数据任务，如压缩和索引构建。

StreamingNode 吸收了在 Milvus 2.5 中分属 DataNode、QueryNode 甚至 Proxy 的所有与流相关的任务，从而提高了清晰度并减少了跨角色状态共享。

Milvus 2.5.x 与 Milvus 2.6.x：逐个组件比较

	Milvus 2.5.x	Milvus 2.6.x	变化
协调器服务	根协调器 / 查询协调器 / 数据协调器（或混合协调器）	混合协调	元数据管理和任务调度合并为单一的 MixCoord，简化了协调逻辑，降低了分布式复杂性。
访问层	代理	代理	写入请求只通过流节点进行数据摄取。
工作节点	-	流节点	专用流处理节点，负责所有增量（增长段）逻辑，包括：- 增量数据摄取- 增量数据查询- 将增量数据持久化到对象存储- 基于流的写入- 基于 WAL 的故障恢复
	查询节点	查询节点	批处理节点，仅处理历史数据查询。
	数据节点	数据节点	批量处理节点，只负责历史数据，包括压缩和建立索引。
	索引节点	-	索引节点并入数据节点，简化了角色定义和部署拓扑。

简而言之，Milvus 2.6 在流式工作负载和批处理工作负载之间划清了界限，消除了 2.5 中出现的跨组件纠缠，创建了更具可扩展性和可维护性的架构。

Milvus 2.6 功能亮点

在进入升级工作流程之前，先来快速了解一下 Milvus 2.6 带来了什么。该版本重点关注降低基础架构成本、提高搜索性能，以及使大型动态人工智能工作负载更易于扩展。

成本和效率改进

主索引的RaBitQ 量化- 一种新的 1 位量化方法，可将向量索引压缩到原始大小的1/32。结合 SQ8 Rerankers，它可将内存使用率降低至 ~28%，将 QPS 提高 4 倍，并保持 ~95% 的召回率，从而显著降低硬件成本。
BM25 优化的全文搜索--稀疏术语权向量支持本地 BM25 评分。与 Elasticsearch 相比，关键词搜索的运行速度提高了 3-4倍（在某些数据集上提高了7 倍），同时将索引大小保持在原始文本数据的三分之一左右。
JSON 路径索引与 JSON 切碎--嵌套 JSON 的结构化过滤现在大大加快，而且更可预测。预先索引的 JSON 路径将过滤延迟从140 毫秒→1.5 毫秒（P99：480 毫秒→10 毫秒）缩短，使混合向量搜索和元数据过滤的响应速度显著提高。
扩展数据类型支持--添加 Int8 向量类型、几何字段（POINT / LINESTRING / POLYGON）和结构数组。这些扩展支持地理空间工作负载、更丰富的元数据模型和更简洁的 Schema。
针对部分更新的 Upsert- 现在，您可以使用单个主键调用插入或更新实体。部分更新只修改所提供的字段，从而减少了写入放大，简化了经常刷新元数据或嵌入的管道。

搜索和检索功能增强

改进了文本处理和多语言支持：新的 Lindera 和 ICU 标记器改进了日语、韩语和多语言文本处理。Jieba 现在支持自定义词典。run_analyzer 可帮助调试标记化行为，多语言分析器可确保跨语言搜索的一致性。
高精度文本匹配： 短语匹配通过可配置的斜率执行有序短语查询。新的NGRAM索引可加速 VARCHAR 字段和 JSON 路径上的子串和LIKE 查询，实现快速的部分文本和模糊匹配。
时间感知和元数据感知 Reranking： 衰减排名器（指数、线性、高斯）使用时间戳调整分数；提升排名器应用元数据驱动的规则对结果进行提升或降级。两者都有助于在不改变基础数据的情况下对检索行为进行微调。
简化的模型集成和自动向量化：通过与 OpenAI、Embedging Face 和其他嵌入提供商的内置集成，Milvus 可在插入和查询操作过程中自动矢量化文本。普通用例不再需要手动嵌入管道。
标量字段的在线 Schema 更新：在现有 Collections 中添加新的标量字段，无需停机或重新加载，从而简化了随着元数据需求增长而发生的 Schema 演变。
使用 MinHash 进行近似重复检测： MinHash+ LSH 可在大型数据集中实现高效的近似重复检测，而无需进行昂贵的精确比较。

架构和可扩展性升级

用于冷热数据管理的分层存储 ：在 SSD 和对象存储中分离热数据和冷数据；支持懒加载和部分加载；无需在本地完全加载 Collections；降低资源使用率达 50%，并加快大型数据集的加载时间。
实时流服务：增加了与 Kafka/Pulsar 集成的专用流节点，以实现连续摄取；实现即时索引和查询可用性；提高写吞吐量，加快故障恢复，以适应实时、快速变化的工作负载。
增强的可扩展性和稳定性：Milvus 现在支持 100,000+ Collections，适用于大型多租户环境。基础架构升级--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.首先启动流节点

提前启动流节点。新的Delegator（查询节点中负责流数据处理的组件）必须移到 Milvus 2.6 流节点。

2.升级 MixCoord

将协调器组件升级到MixCoord。在此步骤中，MixCoord 需要检测工作节点的版本，以便在分布式系统内处理跨版本兼容性问题。

3.升级查询节点

查询节点的升级通常需要较长的时间。在这一阶段，Milvus 2.5 数据节点和索引节点可以继续处理 Flush 和索引构建等操作，有助于在升级查询节点的同时减轻查询端压力。

4.升级数据节点

一旦 Milvus 2.5 数据节点下线，Flush 操作将变得不可用，而 Growing Segments 中的数据可能会继续累积，直到所有节点完全升级到 Milvus 2.6。

5.升级代理

将代理升级到 Milvus 2.6 后，该代理上的写操作将一直不可用，直到所有集群组件都升级到 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 服务栈。操作符管理的 Milvus 服务栈包括

Milvus 核心组件
所需的依赖项，如 etcd、Pulsar 和 MinIO

Milvus 操作符遵循标准的 Kubernetes 操作符模式。它引入 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 操作符会自动按照与 Milvus 2.6 架构一致的预定义顺序执行升级：

启动流节点 → 升级 MixCoord → 升级查询节点 → 升级数据节点 → 升级代理 → 删除索引节点 3.

3.自动合并协调器

Milvus 2.6 用一个 MixCoord 取代多个协调器组件。Milvus 操作符自动处理这一架构过渡。

当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 操作符。

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 与 Milvus Operator - 我应该使用哪一个？

对于生产环境，强烈推荐使用 Milvus Operator。

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

问题 2：我应该如何选择消息队列（MQ）？

推荐的 MQ 取决于部署模式和操作符：

1.独立模式：对于成本敏感型部署，推荐使用 RocksMQ。

2.集群模式

Pulsar支持多租户，允许大型集群共享基础设施，并提供强大的横向扩展能力。
Kafka拥有更成熟的生态系统，在大多数主要云平台上都提供托管 SaaS 产品。

3.啄木鸟（在 Milvus 2.6 中引入）：Woodpecker 消除了对外部消息队列的需求，降低了成本和操作复杂性。

目前，只支持 Embedded Woodpecker 模式，该模式轻量级且易于操作。
对于 Milvus 2.6 独立部署，推荐使用 Woodpecker。
对于生产集群部署，建议使用即将推出的 Woodpecker 集群模式。

问题 3：升级期间能否切换消息队列？

目前不支持在升级期间切换消息队列。未来版本将引入管理 API，以支持在 Pulsar、Kafka、Woodpecker 和 RocksMQ 之间切换。

问题 4：Milvus 2.6 需要更新速率限制配置吗？

现有的速率限制配置仍然有效，也适用于新的流节点。无需更改。

问题 5：协调器合并后，监控角色或配置会改变吗？

监控角色保持不变 (RootCoord,QueryCoord,DataCoord)。
现有的配置选项继续像以前一样工作。
引入了一个新的配置选项mixCoord.enableActiveStandby ，如果没有明确设置，将返回到rootcoord.enableActiveStandby 。

问题 6：StreamingNode 的推荐资源设置是什么？

对于轻型实时摄取或偶尔的写入查询工作负载，较小的配置（如 2 个 CPU 内核和 8 GB 内存）就足够了。
对于重度实时摄取或连续写入和查询工作负载，建议分配与查询节点相当的资源。

问题 7：如何升级使用 Docker Compose 的独立部署？

对于基于 Docker Compose 的独立部署，只需更新docker-compose.yaml 中的 Milvus 映像标签即可。

详情请参考官方指南：https://milvus.io/docs/upgrade_milvus_standalone-docker.md

结论

Milvus 2.6 标志着架构和操作符的重大改进。Milvus 2.6 通过引入流节点（StreamingNode）将流处理和批处理分离开来，将协调器合并到 MixCoord 中，并简化了工作者角色，从而为大规模向量工作负载提供了一个更稳定、更可扩展、更易操作的基础。

这些架构上的变化使得升级--尤其是从 Milvus 2.5 升级--对顺序更加敏感。成功的升级取决于对组件依赖性和临时可用性限制的尊重。对于生产环境，Milvus Operator 是推荐的方法，因为它能自动进行升级排序并降低操作风险，而基于 Helm 的升级更适合非生产用例。

凭借增强的搜索功能、更丰富的数据类型、分层存储和改进的消息队列选项，Milvus 2.6 能够很好地支持需要实时摄取、高查询性能和大规模高效操作的现代人工智能应用。

对最新 Milvus 的任何功能有疑问或想深入了解？加入我们的 Discord 频道或在 GitHub 上提交问题。您还可以通过 Milvus Office Hours 预订 20 分钟的一对一课程，以获得见解、指导和问题解答。

有关 Milvus 2.6 的更多资源

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started

Like the article? Spread the word

如何安全地从 Milvus 2.5.x 升级到 Milvus 2.6.x

从 Milvus 2.5 到 Milvus 2.6 的架构变化

Milvus 2.5 架构

Milvus 2.6 架构

Milvus 2.5.x 与 Milvus 2.6.x：逐个组件比较

Milvus 2.6 功能亮点

成本和效率改进

搜索和检索功能增强

架构和可扩展性升级

如何从 Milvus 2.5.x 升级到 Milvus 2.6.x

如何使用 Milvus Operator 升级到 Milvus 2.6

Milvus 定制资源（CR）示例

使用 Milvus Operator 从 Milvus 2.5 到 2.6 的滚动升级

从 Milvus 2.5 升级到 2.6 的步骤

如何使用 Helm 将 Milvus 升级到 2.6 版

关于 Milvus 2.6 升级和操作符的常见问题

Q1: Milvus Helm 与 Milvus Operator - 我应该使用哪一个？

问题 2：我应该如何选择消息队列（MQ）？

问题 3：升级期间能否切换消息队列？

问题 4：Milvus 2.6 需要更新速率限制配置吗？

问题 5：协调器合并后，监控角色或配置会改变吗？

问题 6：StreamingNode 的推荐资源设置是什么？

问题 7：如何升级使用 Docker Compose 的独立部署？

结论

有关 Milvus 2.6 的更多资源

Try Managed Milvus for Free

扩展阅读

MinIO 停止接受社区修改：评估 RustFS 作为 Milvus S3 兼容对象存储后端的可行性

Milvus RBAC 解读：用基于角色的访问控制保护你的向量数据库

Milvus 2.6 中的词组匹配与泔水：如何提高词组级全文搜索的准确性

利用 Milvus 构建了解用户需求的人工智能搜索管道

如何安全地从 Milvus 2.5.x 升级到 Milvus 2.6.x

从 Milvus 2.5 到 Milvus 2.6 的架构变化

Milvus 2.5 架构

Milvus 2.6 架构

Milvus 2.5.x 与 Milvus 2.6.x：逐个组件比较

Milvus 2.6 功能亮点

成本和效率改进

搜索和检索功能增强

架构和可扩展性升级

如何从 Milvus 2.5.x 升级到 Milvus 2.6.x

如何使用 Milvus Operator 升级到 Milvus 2.6

Milvus 定制资源（CR）示例

使用 Milvus Operator 从 Milvus 2.5 到 2.6 的滚动升级

从 Milvus 2.5 升级到 2.6 的步骤

如何使用 Helm 将 Milvus 升级到 2.6 版

关于 Milvus 2.6 升级和操作符的常见问题

Q1: Milvus Helm 与 Milvus Operator - 我应该使用哪一个？

问题 2： 我应该如何选择消息队列（MQ）？

问题 3：升级期间能否切换消息队列？

问题 4：Milvus 2.6 需要更新速率限制配置吗？

问题 5：协调器合并后，监控角色或配置会改变吗？

问题 6：StreamingNode 的推荐资源设置是什么？

问题 7：如何升级使用 Docker Compose 的独立部署？

结论

有关 Milvus 2.6 的更多资源

Try Managed Milvus for Free

扩展阅读

MinIO 停止接受社区修改：评估 RustFS 作为 Milvus S3 兼容对象存储后端的可行性

Milvus RBAC 解读：用基于角色的访问控制保护你的向量数据库

Milvus 2.6 中的词组匹配与泔水：如何提高词组级全文搜索的准确性

利用 Milvus 构建了解用户需求的人工智能搜索管道

问题 2：我应该如何选择消息队列（MQ）？