Milvus CDC
Milvus CDC (Change Data Capture) replica los cambios en los datos de un clúster de Milvus a otro. Puedes utilizar CDC para crear una topología de recuperación ante desastres de tipo «primario-secundario» para Milvus.
En una topología primaria-secundaria, un clúster actúa como primario y acepta operaciones de escritura. Uno o varios clústeres secundarios reciben continuamente los cambios del primario y pueden atender el tráfico de lectura. Cuando el clúster primario deja de estar disponible o necesita mantenimiento, se puede desviar el tráfico del servicio a un clúster secundario.
Arquitectura
Una topología típica contiene:
- Clúster primario: el clúster de origen para la replicación. Acepta operaciones de lectura y escritura.
- Clúster de reserva: un clúster de destino para la replicación. Recibe los cambios del clúster primario y es de solo lectura mientras permanece en estado de reserva.
- Nodo CDC: un componente de Milvus que reenvía los cambios del WAL desde el clúster primario actual a los clústeres en espera. Implemente el CDC en cada clúster que pueda convertirse en primario tras una conmutación o una conmutación por error.
- Topología de replicación: la relación configurada entre origen y destino, como clúster-a -> clúster-b.
A continuación se muestra una ilustración de la topología.
Flujo de trabajo de CDC
Topologías compatibles
La implementación más habitual de CDC es la de un clúster primario y uno de reserva:
Application writes
|
v
Primary cluster A -- CDC replication --> Standby cluster B
Milvus CDC también admite una topología de un clúster primario y varios clústeres en espera:
Primary cluster A -- CDC replication --> Standby cluster B
\-- CDC replication --> Standby cluster C
Milvus CDC no admite implementaciones multiprimarias ni activas-activas, en las que dos o más clústeres aceptan tráfico de escritura al mismo tiempo.
Comportamiento de los clústeres primario y de reserva
| Función | Lecturas | Escrituras | Comportamiento de replicación |
|---|---|---|---|
| Primario | Sí | Sí | Envía los cambios a los clústeres de espera |
| De reserva | Sí | No | Recibe los cambios replicados del clúster primario |
Un clúster en espera rechaza las solicitudes de escritura directa. Esto evita el «split brain» y mantiene la coherencia de la topología de replicación.
Conmutación planificada frente a conmutación por error
Milvus CDC ofrece dos formas de trasladar el tráfico del servicio desde el clúster primario actual a un clúster de reserva.
| Operación | Se utiliza cuando | Pérdida de datos | Comportamiento esperado |
|---|---|---|---|
| Conmutación | El primario actual sigue estando accesible, o se está realizando un mantenimiento planificado | RPO = 0 | Espera a que se reciban los datos replicados restantes antes de que cambien los roles |
| Conmutación por fallo | El primario actual no está disponible y no se puede recuperar rápidamente | Posible | Promueve el servidor en espera de inmediato para que puedan reanudarse las escrituras |
Utiliza la conmutación siempre que el primario actual aún pueda responder. Utiliza la conmutación por error solo cuando restaurar la disponibilidad sea más importante que esperar al primario original.
El 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 al clúster en espera.
El retraso de CDC afecta a ambas opciones de recuperación:
- Durante la conmutación, un menor retraso de CDC suele significar que la operación se completa más rápido.
- Durante la conmutación por error, el retraso de CDC representa la ventana de datos que se podría perder si el primario original no está disponible.
Debes supervisar el retraso de CDC de forma continua y mantenerlo lo más bajo posible. La página «Configurar la replicación de CDC» incluye un ejemplo de PromQL para estimar el retraso de CDC.
Importación masiva en la replicación CDC
En una topología de replicación CDC, la importación masiva debe utilizar el modo de confirmación en dos fases (2PC) con auto_commit=false. Ejecute la importación y la confirmación únicamente en el clúster primario, y asegúrese de que los archivos de importación estén disponibles tanto para el clúster primario como para el clúster de reserva. Para obtener más detalles, consulte «Importación masiva en la replicación CDC».
Limitaciones
Milvus CDC tiene actualmente las siguientes limitaciones:
- Solo admite topologías con un único clúster primario.
- No admite escrituras activas-activas ni multiprimarias.
- Los clústeres de reserva pueden atender el tráfico de lectura, pero rechazan las escrituras directas mientras permanezcan en estado de reserva.
- La conmutación por error puede provocar la pérdida de datos que se hayan escrito en el antiguo primario pero que aún no se hayan replicado en el clúster en espera.
- La configuración de «
pchannels» debe coincidir con la disposición real de los canales de cada clúster.
Preguntas frecuentes
¿Puede un clúster en espera atender consultas?
Sí. Un clúster en espera puede gestionar el tráfico de lectura. No puede aceptar escrituras hasta que se convierta en el clúster primario.
¿Admite Milvus CDC las escrituras en modo activo-activo?
No. Milvus CDC está diseñado para una topología de un único clúster primario. Escribir en varios clústeres al mismo tiempo puede provocar un «split brain» y divergencias en los datos.
¿Se pierden datos durante la conmutación?
No. La conmutación espera a que se repliquen los datos restantes antes de que el clúster en espera pase a ser primario.
¿Se pierden datos durante la conmutación por error?
Es posible. Cualquier dato escrito en el antiguo primario pero que aún no se haya replicado en el secundario puede perderse.
¿Cuántos datos se pueden perder 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 servidor primario dejó de estar disponible.
