Home
Blog
Cómo actualizar con seguridad de Milvus 2.5.x a Milvus 2.6.x

Cómo actualizar con seguridad de Milvus 2.5.x a Milvus 2.6.x

Tutorials

December 25, 2025

Yiqing Lu

Milvus 2.6 lleva un tiempo en funcionamiento y está demostrando ser un sólido paso adelante para el proyecto. La versión aporta una arquitectura refinada, un mayor rendimiento en tiempo real, un menor consumo de recursos y un comportamiento de escalado más inteligente en entornos de producción. Muchas de estas mejoras han surgido directamente de los comentarios de los usuarios, y los primeros usuarios de 2.6.x ya han informado de búsquedas notablemente más rápidas y de un rendimiento del sistema más predecible bajo cargas de trabajo pesadas o dinámicas.

Para los equipos que utilizan Milvus 2.5.x y están evaluando el paso a 2.6.x, esta guía es su punto de partida. Desglosa las diferencias arquitectónicas, destaca las capacidades clave introducidas en Milvus 2.6 y proporciona una ruta de actualización práctica, paso a paso, diseñada para minimizar la interrupción operativa.

Si sus cargas de trabajo implican canalizaciones en tiempo real, búsquedas multimodales o híbridas, u operaciones vectoriales a gran escala, este blog le ayudará a evaluar si 2.6 se ajusta a sus necesidades y, si decide seguir adelante, actualizar con confianza manteniendo la integridad de los datos y la disponibilidad del servicio.

Cambios en la arquitectura de Milvus 2.5 a Milvus 2.6

Antes de sumergirnos en el flujo de trabajo de actualización propiamente dicho, entendamos primero cómo cambia la arquitectura de Milvus en Milvus 2.6.

Arquitectura de Milvus 2.5

Milvus 2.5 Architecture Arquitectura de Milvus 2.5

En Milvus 2.5, los flujos de trabajo en flujo y por lotes estaban entrelazados a través de múltiples nodos trabajadores:

QueryNode gestionaba tanto las consultas históricas como las incrementales (streaming).
DataNode gestionaba tanto la descarga en tiempo de ingesta como la compactación en segundo plano de los datos históricos.

Esta mezcla de lógica por lotes y en tiempo real dificultaba el escalado independiente de las cargas de trabajo por lotes. También significaba que el estado de streaming estaba disperso entre varios componentes, lo que introducía retrasos en la sincronización, complicaba la recuperación en caso de fallo y aumentaba la complejidad operativa.

Arquitectura de Milvus 2.6

Milvus 2.6 Architecture Arquitectura de Milvus 2.6

Milvus 2.6 introduce un StreamingNode dedicado que maneja todas las responsabilidades de los datos en tiempo real: consumir la cola de mensajes, escribir segmentos incrementales, servir consultas incrementales y gestionar la recuperación basada en WAL. Con el streaming aislado, el resto de componentes asumen funciones más limpias y centradas:

QueryNode gestiona ahora sólo consultas por lotes sobre segmentos históricos.
DataNode gestiona ahora sólo las tareas de datos históricos, como la compactación y la creación de índices.

El StreamingNode absorbe todas las tareas relacionadas con el streaming que se dividían entre DataNode, QueryNode e incluso el Proxy en Milvus 2.5, aportando claridad y reduciendo la compartición de estados entre roles.

Milvus 2.5.x frente a Milvus 2.6.x: Comparación componente por componente

	Milvus 2.5.x	Milvus 2.6.x	Qué ha cambiado
Servicios de coordinación	RootCoord / QueryCoord / DataCoord (o MixCoord)	MixCoord	La gestión de metadatos y la programación de tareas se consolidan en un único MixCoord, lo que simplifica la lógica de coordinación y reduce la complejidad distribuida.
Capa de acceso	Proxy	Proxy	Las solicitudes de escritura se enrutan únicamente a través del nodo de transmisión para la ingestión de datos.
Nodos de trabajo	-	Nodo de transmisión	Nodo dedicado al procesamiento de secuencias responsable de toda la lógica incremental (segmentos crecientes), incluyendo:- Ingesta de datos incrementales- Consulta de datos incrementales- Persistencia de datos incrementales en el almacenamiento de objetos- Escrituras basadas en secuencias- Recuperación de fallos basada en WAL
	Nodo de consulta	Nodo de consulta	Nodo de procesamiento por lotes que sólo gestiona consultas sobre datos históricos.
	Nodo de datos	Nodo de datos	Nodo de procesamiento por lotes responsable únicamente de los datos históricos, incluida la compactación y la creación de índices.
	Nodo de índices	-	El nodo de índice se fusiona con el nodo de datos, lo que simplifica la definición de funciones y la topología de despliegue.

En resumen, Milvus 2.6 traza una línea clara entre las cargas de trabajo de streaming y batch, eliminando el enredo entre componentes visto en 2.5 y creando una arquitectura más escalable y fácil de mantener.

Características destacadas de Milvus 2.6

Antes de entrar en el flujo de trabajo de la actualización, he aquí un rápido vistazo a lo que Milvus 2.6 pone sobre la mesa. Esta versión se centra en reducir los costes de infraestructura, mejorar el rendimiento de las búsquedas y facilitar el escalado de cargas de trabajo de IA dinámicas y de gran tamaño.

Mejoras en costes y eficiencia

CuantizaciónRaBitQ para índices primarios: un nuevo método de cuantización de 1 bit que comprime los índices vectoriales a 1/32 de su tamaño original. Combinado con el reordenamiento SQ8, reduce el uso de memoria en un 28%, aumenta los QPS en 4 veces y mantiene una recuperación del 95%, lo que reduce significativamente los costes de hardware.
Búsqueda de texto completooptimizada para BM25: puntuación nativa de BM25 basada en vectores de ponderación de términos dispersos. La búsqueda por palabras clave se ejecuta entre 3 y 4 veces más rápido (hasta 7 veces en algunos conjuntos de datos) en comparación con Elasticsearch, manteniendo el tamaño del índice en torno a un tercio de los datos de texto originales.
Indexación de rutas JSON con JSON Shredding - El filtrado estructurado en JSON anidado es ahora mucho más rápido y predecible. Las rutas JSON previamente indexadas reducen la latencia del filtro de 140 ms → 1,5 ms (P99: 480 ms → 10 ms), lo que hace que la búsqueda vectorial híbrida + el filtrado de metadatos respondan significativamente mejor.
Soporte ampliado de tipos de datos: añade tipos de vectores Int8, campos de geometría (POINT / LINESTRING / POLYGON) y matrices de estructuras. Estas extensiones soportan cargas de trabajo geoespaciales, un modelado de metadatos más rico y esquemas más limpios.
Upsert para actualizaciones parciales - Ahora puede insertar o actualizar entidades utilizando una única llamada de clave primaria. Las actualizaciones parciales sólo modifican los campos proporcionados, lo que reduce la amplificación de escritura y simplifica los procesos que actualizan con frecuencia los metadatos o las incrustaciones.

Mejoras en la búsqueda y recuperación

Procesamiento de texto y soporte multilingüe mejorados: Los nuevos tokenizadores Lindera e ICU mejoran el tratamiento de textos en japonés, coreano y multilingües. Jieba es ahora compatible con diccionarios personalizados. run_analyzer ayuda a depurar el comportamiento de la tokenización, y los analizadores multilingües garantizan la coherencia de la búsqueda en varios idiomas.
Concordancia detexto de alta precisión: la concordancia de frases impone consultas de frases ordenadas con inclinación configurable. El nuevo índice NGRAM acelera las consultas de subcadenas y LIKE tanto en campos VARCHAR como en rutas JSON, lo que permite una rápida coincidencia parcial y difusa del texto.
Reordenación en función del tiempo y los metadatos: Los Clasificadores de Decaimiento (exponencial, lineal, gaussiano) ajustan las puntuaciones utilizando marcas de tiempo; los Clasificadores de Impulso aplican reglas basadas en metadatos para promover o degradar los resultados. Ambos ayudan a ajustar el comportamiento de recuperación sin cambiar los datos subyacentes.
Integración simplificada de modelos y vectorización automática: Las integraciones incorporadas con OpenAI, Hugging Face y otros proveedores de incrustación permiten a Milvus vectorizar automáticamente el texto durante las operaciones de inserción y consulta. Se acabaron las canalizaciones de incrustación manuales para casos de uso comunes.
Actualizaciones de esquema en línea para campos escalares: Añada nuevos campos escalares a las colecciones existentes sin tiempo de inactividad ni recargas, simplificando la evolución del esquema a medida que crecen los requisitos de metadatos.
Detección de casi duplicados con MinHash: MinHash + LSH permite una detección eficaz de casi duplicados en grandes conjuntos de datos sin costosas comparaciones exactas.

Mejoras de arquitectura y escalabilidad

Almacenamiento por niveles para la gestión de datos calientes y fríos: Separa los datos calientes y fríos en SSD y almacenamiento de objetos; admite la carga lenta y parcial; elimina la necesidad de cargar completamente las colecciones de forma local; reduce el uso de recursos hasta en un 50% y acelera los tiempos de carga para grandes conjuntos de datos.
Servicio de streaming en tiempo real: Añade nodos de streaming dedicados e integrados con Kafka/Pulsar para una ingestión continua; permite la indexación inmediata y la disponibilidad de consultas; mejora el rendimiento de escritura y acelera la recuperación de fallos para cargas de trabajo en tiempo real que cambian rápidamente.
Escalabilidad y estabilidad mejoradas: Milvus admite ahora más de 100.000 colecciones para grandes entornos multiempresa. Las actualizaciones de infraestructura - Woodpecker (WAL sin disco), Storage v2 (IOPS/memoria reducidas) y Coordinator Merge - mejoran la estabilidad del clúster y permiten un escalado predecible bajo cargas de trabajo pesadas.

Para obtener una lista completa de las características de Milvus 2.6, consulte las notas de la versión de Milvus.

Cómo actualizar de Milvus 2.5.x a Milvus 2.6.x

Para mantener el sistema lo más disponible posible durante la actualización, los clusters Milvus 2.5 deben actualizarse a Milvus 2.6 en el siguiente orden.

1. Inicie primero el nodo de transmisión

Inicie el Nodo de Transmisión por adelantado. El nuevo Delegator (el componente en el Query Node responsable del manejo de los datos de streaming) debe moverse al Milvus 2.6 Streaming Node.

2. Actualizar MixCoord

Actualice los componentes del coordinador a MixCoord. Durante este paso, MixCoord necesita detectar las versiones de los Worker Nodes para manejar la compatibilidad entre versiones dentro del sistema distribuido.

3. Actualizar el nodo de consulta

Las actualizaciones del Nodo de Consulta suelen llevar más tiempo. Durante esta fase, los Nodos de Datos y los Nodos de Índice de Milvus 2.5 pueden continuar manejando operaciones como Flush y la construcción de Índices, ayudando a reducir la presión del lado de la consulta mientras se actualizan los Nodos de Consulta.

4. Actualizar el Nodo de Datos

Una vez que los Nodos de Datos Milvus 2.5 se desconectan, las operaciones de Flush dejan de estar disponibles y los datos en Segmentos Crecientes pueden seguir acumulándose hasta que todos los nodos se actualicen completamente a Milvus 2.6.

5. Actualizar el proxy

Después de actualizar un Proxy a Milvus 2.6, las operaciones de escritura en ese Proxy seguirán sin estar disponibles hasta que todos los componentes del clúster se actualicen a 2.6.

6. Eliminar el nodo de índice

Una vez que todos los demás componentes estén actualizados, el Nodo de Índice autónomo puede retirarse de forma segura.

Notas:

Desde la finalización de la actualización del DataNode hasta la finalización de la actualización del Proxy, las operaciones de Flush no están disponibles.
Desde el momento en que se actualiza el primer Proxy hasta que se actualizan todos los nodos Proxy, algunas operaciones de escritura no están disponibles.
Cuando se actualiza directamente de Milvus 2.5.x a 2.6.6, las operaciones DDL (Lenguaje de Definición de Datos) no están disponibles durante el proceso de actualización debido a cambios en el marco DDL.

Cómo actualizar a Milvus 2.6 con Milvus Operator

Milvus Operator es un operador Kubernetes de código abierto que proporciona una forma escalable y altamente disponible de desplegar, gestionar y actualizar toda la pila de servicios Milvus en un clúster Kubernetes de destino. La pila de servicios Milvus gestionada por el operador incluye:

Componentes centrales de Milvus
Dependencias necesarias como etcd, Pulsar y MinIO

Milvus Operator sigue el patrón estándar de Kubernetes Operator. Introduce un Recurso Personalizado Milvus (CR) que describe el estado deseado de un clúster Milvus, como su versión, topología y configuración.

Un controlador supervisa continuamente el clúster y concilia el estado real con el estado deseado definido en el CR. Cuando se realizan cambios, como actualizar la versión de Milvus, el operador los aplica automáticamente de forma controlada y repetible, lo que permite actualizaciones automatizadas y una gestión continua del ciclo de vida.

Ejemplo de recurso personalizado (CR) de Milvus

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

Actualizaciones continuas de Milvus 2.5 a 2.6 con Milvus Operator

Milvus Operator proporciona soporte integrado para actualizaciones continuas de Mil vus 2.5 a 2.6 en modo clúster, adaptando su comportamiento para tener en cuenta los cambios arquitectónicos introducidos en 2.6.

1. Detección del escenario de actualización

Durante una actualización, Milvus Operator determina la versión de Milvus de destino a partir de la especificación del clúster. Esto se hace

Inspeccionando la etiqueta de imagen definida en spec.components.image, o
Leyendo la versión explícita especificada en spec.components.version

A continuación, el operador compara esta versión deseada con la versión actualmente en ejecución, que se registra en status.currentImage o status.currentVersion. Si la versión actual es 2.5 y la versión deseada es 2.6, el operador identifica la actualización como un escenario de actualización 2.5 → 2.6.

2. Orden de ejecución de la actualización progresiva

Cuando se detecta una actualización 2.5 → 2.6 y el modo de actualización está configurado como actualización continua (spec.components.imageUpdateMode: rollingUpgrade, que es el valor predeterminado), Milvus Operator realiza automáticamente la actualización en un orden predefinido alineado con la arquitectura de Milvus 2.6:

Iniciar el nodo de transmisión → Actualizar MixCoord → Actualizar el nodo de consulta → Actualizar el nodo de datos → Actualizar el proxy → Eliminar el nodo de índice.

3. Consolidación automática de coordinadores

Milvus 2.6 sustituye múltiples componentes de coordinador por un único MixCoord. Milvus Operator maneja esta transición arquitectónica automáticamente.

Cuando se configura spec.components.mixCoord, el operador trae MixCoord y espera hasta que esté listo. Una vez que MixCoord está totalmente operativo, el operador apaga los componentes del coordinador heredado -RootCoord, QueryCoord y DataCoord- completando la migración sin necesidad de intervención manual.

Pasos de actualización de Milvus 2.5 a 2.6

1.Actualice Milvus Operator a la última versión (En esta guía, utilizamos la versión 1.3.3, que era la última versión en el momento de redactar este documento).

# 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.Fusione los componentes del coordinador

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

3. Asegúrese de que el clúster ejecuta Milvus 2.5.16 o posterior.

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.Actualice Milvus a la versión 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

Cómo actualizar a Milvus 2.6 con Helm

Al desplegar Milvus utilizando Helm, todos los recursos de Kubernetes Deployment se actualizan en paralelo, sin un orden de ejecución garantizado. Como resultado, Helm no proporciona un control estricto sobre las secuencias de actualización entre componentes. Para entornos de producción, se recomienda encarecidamente el uso de Milvus Operator.

Milvus aún puede actualizarse de 2.5 a 2.6 utilizando Helm siguiendo los pasos que se indican a continuación.

Requisitos del sistema

Versión deHelm: ≥ 3.14.0
Versión de Kubernetes: ≥ 1.20.0

1.Actualice la carta Milvus Helm a la última versión. En esta guía, utilizamos la versión 5.0.7 del gráfico, que era la más reciente en el momento de la redacción.

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

2.Si el cluster está desplegado con múltiples componentes coordinadores, primero actualice Milvus a la versión 2.5.16 o posterior y habilite 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.Actualice Milvus a la versión 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

Preguntas frecuentes sobre la actualización y el funcionamiento de Milvus 2.6

P1: Milvus Helm vs. Milvus Operator - ¿cuál debería usar?

Para entornos de producción, se recomienda encarecidamente Milvus Operator.

Consulte la guía oficial para más detalles: https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm

P2: ¿Cómo debo elegir una cola de mensajes (MQ)?

La MQ recomendada depende del modo de despliegue y de los requisitos operativos:

1. Modo autónomo: Para despliegues sensibles a los costes, se recomienda RocksMQ.

2. Modo clúster

Pulsar soporta multi-tenancy, permite a grandes clusters compartir infraestructura y ofrece una fuerte escalabilidad horizontal.
Kafka tiene un ecosistema más maduro, con ofertas SaaS gestionadas disponibles en la mayoría de las principales plataformas en la nube.

3. Woodpecker (introducido en Milvus 2.6): Woodpecker elimina la necesidad de una cola de mensajes externa, reduciendo el coste y la complejidad operativa.

Actualmente, sólo se admite el modo Woodpecker integrado, que es ligero y fácil de manejar.
Para las implantaciones independientes de Milvus 2.6, se recomienda el uso de Woodpecker.
Para los despliegues de clúster de producción, se recomienda utilizar el próximo modo de clúster Woodpecker una vez que esté disponible.

P3: ¿Se puede cambiar la cola de mensajes durante una actualización?

No. Actualmente no es posible cambiar la cola de mensajes durante una actualización. En futuras versiones se introducirán API de gestión para permitir el cambio entre Pulsar, Kafka, Woodpecker y RocksMQ.

P4: ¿Es necesario actualizar las configuraciones de limitación de velocidad para Milvus 2.6?

No. Las configuraciones de limitación de velocidad existentes siguen siendo efectivas y también se aplican al nuevo Streaming Node. No es necesario realizar ningún cambio.

P5: Tras la fusión de coordinadores, ¿cambian las funciones de supervisión o las configuraciones?

Los roles de monitorización permanecen sin cambios (RootCoord, QueryCoord, DataCoord).
Las opciones de configuración existentes siguen funcionando como antes.
Se introduce una nueva opción de configuración, mixCoord.enableActiveStandby, que volverá a rootcoord.enableActiveStandby si no se establece explícitamente.

P6: ¿Cuál es la configuración de recursos recomendada para StreamingNode?

Para ingestión ligera en tiempo real o cargas de trabajo ocasionales de escritura y consulta, basta con una configuración pequeña, como 2 núcleos de CPU y 8 GB de memoria.
Para una ingestión intensa en tiempo real o cargas de trabajo continuas de escritura y consulta, se recomienda asignar recursos comparables a los del Nodo de Consulta.

P7: ¿Cómo actualizo una implantación independiente que utiliza Docker Compose?

Para despliegues autónomos basados en Docker Compose, simplemente actualice la etiqueta de imagen Milvus en docker-compose.yaml.

Consulte la guía oficial para más detalles: https://milvus.io/docs/upgrade_milvus_standalone-docker.md

Conclusión

Milvus 2.6 marca una mejora importante tanto en la arquitectura como en las operaciones. Al separar el streaming y el procesamiento por lotes con la introducción de StreamingNode, consolidando los coordinadores en MixCoord y simplificando los roles de los trabajadores, Milvus 2.6 proporciona una base más estable, escalable y fácil de operar para cargas de trabajo vectoriales a gran escala.

Estos cambios arquitectónicos hacen que las actualizaciones, especialmente desde Milvus 2.5, sean más sensibles al orden. Una actualización satisfactoria depende de que se respeten las dependencias de los componentes y las restricciones de disponibilidad temporal. Para entornos de producción, Milvus Operator es el enfoque recomendado, ya que automatiza la secuencia de actualización y reduce el riesgo operativo, mientras que las actualizaciones basadas en Helm son más adecuadas para casos de uso no relacionados con la producción.

Con capacidades de búsqueda mejoradas, tipos de datos más ricos, almacenamiento por niveles y opciones de cola de mensajes mejoradas, Milvus 2.6 está bien posicionado para soportar aplicaciones de IA modernas que requieren ingestión en tiempo real, alto rendimiento de consulta y operaciones eficientes a escala.

¿Tiene alguna pregunta o desea profundizar en alguna característica de la última versión de Milvus? Únase a nuestro canal de Discord o presente incidencias en GitHub. También puede reservar una sesión individual de 20 minutos para obtener información, orientación y respuestas a sus preguntas a través de Milvus Office Hours.