Milvus CDC

Milvus CDC (Change Data Capture) replica los cambios de datos de un cluster Milvus a otro. Puede utilizar CDC para construir una topología de recuperación de desastres primaria-standby para Milvus.

En una topología primaria-standby, un cluster actúa como primario y acepta escrituras. Uno o más clusters en espera reciben continuamente cambios del primario y pueden servir tráfico de lectura. Cuando el clúster primario deja de estar disponible o necesita mantenimiento, puede cambiar el tráfico de servicio a un clúster en espera.

Arquitectura

Una topología típica contiene

• Clúster primario: El clúster de origen para la replicación. Acepta lecturas y escrituras.
• Clúster en espera: Un clúster de destino para la replicación. Recibe cambios del primario y es de sólo lectura mientras permanece en espera.
• Nodo CDC: Un componente de Milvus que reenvía los cambios de WAL desde el primario actual a los clústeres en espera. Despliegue el CDC en cada clúster que pueda convertirse en primario tras una conmutación o conmutación por error.
• Topología de replicación: La relación fuente-destino configurada, como clúster-a -> clúster-b. A continuación se ilustra la topología. Flujo de trabajo de CDC

Topologías soportadas

El despliegue CDC más común es uno primario y uno en espera:

Application writes
      |
      v
Primary cluster A  -- CDC replication -->  Standby cluster B

Milvus CDC también admite una topología de un solo primario y varios en espera:

Primary cluster A  -- CDC replication -->  Standby cluster B
                  \-- CDC replication -->  Standby cluster C

Milvus CDC no soporta despliegues multi-primarios o activo-activo, donde dos o más clusters aceptan tráfico de escritura al mismo tiempo.

Comportamiento primario y en espera

Función	Lecturas	Escrituras	Comportamiento de replicación
Primario	Sí	Sí	Envía los cambios a los clusters en espera
En espera	Sí	No	Recibe cambios replicados del primario

Un clúster en espera rechaza las solicitudes de escritura directa. Esto evita la división del cerebro y mantiene la coherencia de la topología de replicación.

Conmutación planificada frente a conmutación por error

Milvus CDC proporciona dos formas de mover el tráfico de servicio del primario actual a un clúster en espera.

Operación	Uso cuando	Pérdida de datos	Comportamiento esperado
Conmutación	Todavía se puede acceder al primario actual o se está realizando un mantenimiento planificado	RPO = 0	Espera los datos replicados restantes antes de cambiar los roles
Conmutación por error	El primario actual no está disponible y no se puede recuperar rápidamente	Posible	Promueve el standby inmediatamente para que las escrituras puedan reanudarse

Utiliza la conmutación por error siempre que el primario actual aún pueda responder. Utilice la conmutación por error sólo cuando restaurar la disponibilidad sea más importante que esperar al primario original.

Retraso de CDC y por qué es importante

El retraso de CDC es la cantidad de datos que se han escrito en el clúster primario pero que aún no se han aplicado a un clúster en espera.

El retraso de CDC afecta a ambas opciones de recuperación:

• Durante la conmutación, un menor CDC lag suele significar que la operación se completa más rápido.
• Durante la conmutación por error, el CDC lag representa la ventana de datos que puede perderse si el primario original no está disponible.

Debe monitorizar el retardo CDC continuamente y mantenerlo lo más bajo posible. La página Configurar Replicación CDC incluye un ejemplo PromQL para estimar el retardo CDC.

Limitaciones

Milvus CDC tiene actualmente las siguientes limitaciones:

• Sólo admite topologías monoprimarias.
• No soporta escrituras activo-activo o multi-primario.
• Los clusters en espera pueden servir tráfico de lectura, pero rechazan las escrituras directas mientras permanezcan en espera.
• La conmutación por error puede perder datos que se escribieron en el primario antiguo pero que aún no se replicaron en el clúster en espera.
• La dirección pchannels configurada debe coincidir con la disposición real de los canales de cada clúster.

PREGUNTAS FRECUENTES

¿Puede un cluster en espera servir consultas?

Sí. Un clúster en espera puede servir tráfico de lectura. No puede aceptar escrituras hasta que se convierta en el principal.

¿Milvus CDC admite escrituras activo-activo?

No. Milvus CDC está diseñado para una topología de un único primario. Escribir en varios clústeres al mismo tiempo puede provocar la división del cerebro y la divergencia de datos.

¿Pierde datos la conmutación?

No. La conmutación espera a que se repliquen los datos restantes antes de que el clúster en espera se convierta en primario.

¿Pierde datos la conmutación por error?

Es posible. Pueden perderse los datos escritos en el antiguo primario que aún no se hayan replicado en el servidor en espera.

¿Cuántos datos pueden perderse durante la conmutación por error?

La pérdida potencial de datos está limitada por el retraso del CDC en el momento en que el primario dejó de estar disponible.