Conmutación por error

La conmutación por error promueve un clúster en espera a un primario independiente cuando el primario original no está disponible por completo. Se trata de una operación que da prioridad a la disponibilidad y puede provocar la pérdida de datos que no estaban replicados antes del fallo.

Esta guía asume que la topología original es:

cluster-a (primary)  ->  cluster-b (standby)

Después de la conmutación por error, cluster-b se convierte en un primario autónomo:

cluster-b (primary)

Cuándo utilizar la conmutación por error

Utilice la conmutación por error sólo cuando:

• El primario original no puede responder a las peticiones.
• El primario no puede recuperarse en un tiempo aceptable.
• Restaurar la disponibilidad de escritura es más importante que esperar al primario antiguo.

Si el primario todavía está accesible, utilice Switchover en su lugar. La conmutación evita la pérdida de datos.

Riesgo de pérdida de datos

La conmutación por error no espera al primario original. Cualquier dato escrito en el primario antiguo pero aún no replicado en el standby puede perderse.

La posible pérdida de datos viene determinada por el retardo del CDC en el momento en que el primario dejó de estar disponible.

Antes de ejecutar la conmutación por error, comprenda las ventajas y desventajas:

Objetivo	Conmutación	Conmutación por error
Restaurar escrituras mientras el primario está inaccesible	No	Sí
Evitar la pérdida de datos	Sí	No garantizado
Requiere que el antiguo primario responda	Sí	No

Antes de empezar

Confirme lo siguiente:

• El primario original no está disponible.
• Ha decidido no esperar a la recuperación del primario.
• El tráfico de aplicaciones puede redirigirse al primario en espera.
• La automatización del tráfico no enviará escrituras de vuelta al primario antiguo si éste se recupera.
• Dispone del ID del clúster en espera, la dirección, el token y los pchannels.

El requisito de seguridad más importante es evitar el "split brain". Después de la conmutación por error, sólo el standby promovido debe aceptar escrituras de aplicaciones.

Construir la configuración de conmutación por error

Cree una configuración que contenga sólo el clúster en espera y ninguna topología de replicación. Configure force_promote=True.

# If you followed Set Up CDC Replication, cluster B is the original target cluster.
cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels

failover_config = {
    "clusters": [
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        }
    ],
    "cross_cluster_topology": [],
    "force_promote": True,
}

Promover el Standby

Envíe la solicitud al clúster en espera.

from pymilvus import MilvusClient

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.update_replicate_configuration(**failover_config)
finally:
    client_b.close()

Si la solicitud tiene éxito, cluster-b se convierte en un primario autónomo y puede aceptar escrituras.

Redirigir el tráfico de la aplicación

Después de la promoción:

1. Redirija el tráfico de escritura a cluster-b.
2. Elimine cluster-a de los puntos finales de escritura, los equilibradores de carga, los registros DNS y la automatización.
3. Verifique que cluster-b acepta escrituras.
4. Mantenga cluster-a aislado hasta que sea desmantelado o reconstruido explícitamente.

Ejemplo de verificación de escritura:

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.insert(
        collection_name="test_collection",
        data=[{"id": 1, "vector": [0.1] * 128}],
    )
finally:
    client_b.close()

Ajuste los campos de nombre de colección y esquema para que coincidan con su despliegue.

Verificación del resultado

Verifique directamente el clúster promocionado:

• Las escrituras se realizan correctamente en cluster-b.
• Las lecturas devuelven los datos esperados.
• Ningún componente de aplicación escribe en cluster-a.

Manejo del antiguo primario

Después de la conmutación por error, trate cluster-a como obsoleto. No envíes escrituras de aplicación a él si vuelve a estar accesible. Puede contener datos que nunca fueron replicados a cluster-b, y cluster-b puede contener nuevas escrituras después de la conmutación por error.

No reconecte cluster-a a la topología antigua automáticamente. Reintroducir el primario antiguo es una tarea de recuperación separada que debe planificarse cuidadosamente.

Minimizar la pérdida de datos

No puede eliminar todo el riesgo de pérdida de datos de la conmutación por error, pero puede reducirlo:

• Supervise continuamente el retraso de CDC.
• Mantenga los clústeres en espera aprovisionados para gestionar la tasa de escritura del primario.
• Mantenga baja la latencia de red entre clusters y la pérdida de paquetes.
• Haga que las escrituras de la aplicación sean idempotentes.
• Reintentar las escrituras cuyo éxito sea incierto después de la conmutación por error.
• Prefiera la conmutación siempre que el primario aún pueda responder.

PREGUNTAS FRECUENTES

¿La conmutación por error siempre pierde datos?

No, pero puede ocurrir. Si todas las escrituras ya se habían replicado antes de que fallara el primario, no se perderá ningún dato. Si existía retraso de CDC, los datos retrasados pueden perderse.

¿Cuánto tarda la conmutación por error?

Normalmente se completa en cuestión de segundos, dependiendo del estado del cluster y de la disponibilidad del plano de control en el standby.

¿Puedo ejecutar la conmutación por error en el primario?

No. La conmutación por error está pensada para un clúster en espera. Si el primario actual está disponible, utilice la conmutación por error.

¿Puede el antiguo primario reincorporarse automáticamente?

No. Después de la conmutación por error, el primario antiguo debe tratarse como obsoleto y desmantelarse o reconstruirse antes de que pueda volver a participar en la replicación.

¿Cómo evito el cerebro dividido?

Asegúrese de que sólo el clúster promovido recibe escrituras. Elimine el primario antiguo de todas las rutas de escritura antes de que pueda recuperarse y aceptar tráfico.