Conmutación

La conmutación cambia la dirección primario-standby sin pérdida de datos. Utilícelo cuando el clúster primario actual aún sea accesible, o cuando necesite mover tráfico para mantenimiento.

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

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

Después de la conmutación, la topología pasa a ser:

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

Cuándo utilizar la conmutación

Utilice la conmutación cuando:

• Está haciendo mantenimiento en el primario actual.
• El primario está parcialmente degradado pero aún puede responder a las peticiones.
• Necesita RPO = 0 y no puede aceptar la pérdida de datos.

No utilice la conmutación si el primario no está disponible por completo. En ese caso, utilice Failover.

Antes de empezar

Compruebe lo siguiente antes de empezar:

• Ambos clusters están accesibles.
• La replicación CDC es correcta.
• El retraso de CDC es lo suficientemente bajo para su objetivo de tiempo de recuperación.
• La escritura de aplicaciones puede ser pausada o reintentada durante el cambio de rol.
• Ha preparado la configuración de la nueva topología.

La conmutación garantiza que no haya pérdida de datos, pero el tiempo de operación depende de la cantidad de datos que queden por replicar.

Cree la nueva topología

Cree una configuración de sustitución completa en la que cluster-b se convierta en el origen y cluster-a en el destino.

# If you followed Set Up CDC Replication, cluster A is the original source cluster,
# and cluster B is the original target cluster.
cluster_a_id = source_cluster_id
cluster_a_addr = source_cluster_addr
cluster_a_client_addr = source_client_addr
cluster_a_token = source_cluster_token
cluster_a_pchannels = source_cluster_pchannels

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

switchover_config = {
    "clusters": [
        {
            "cluster_id": cluster_a_id,
            "connection_param": {
                "uri": cluster_a_addr,
                "token": cluster_a_token,
            },
            "pchannels": cluster_a_pchannels,
        },
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": cluster_b_id,
            "target_cluster_id": cluster_a_id,
        }
    ],
}

Aplique la nueva topología

Aplica la misma configuración a ambos clusters. Envíe primero la solicitud al primario actual y, a continuación, envíela al secundario. Si más tarde vuelve a cambiar, invierta el orden porque cluster-b es el primario actual.

from pymilvus import MilvusClient

client_a = MilvusClient(uri=cluster_a_client_addr, token=cluster_a_token)
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_a.update_replicate_configuration(**switchover_config)
    client_b.update_replicate_configuration(**switchover_config)
finally:
    client_a.close()
    client_b.close()

El primario antiguo pasa a standby y rechaza nuevas escrituras. El standby antiguo espera los datos replicados restantes, se promueve a primario y luego acepta escrituras.

Si la solicitud falla debido a un error transitorio de la red o del servicio, vuelva a intentarlo con la misma configuración.

Redirigir el tráfico de la aplicación

Después de que cluster-b se convierta en primario:

1. Dirija el tráfico de escritura a cluster-b.
2. Confirme que las lecturas y escrituras se realizan correctamente en cluster-b.
3. Confirme que cluster-a ya no recibe escrituras de aplicaciones.
4. Siga supervisando la replicación de cluster-b a cluster-a.

Verificación del resultado

Compruebe que cluster-b funciona como nuevo primario y que los datos siguen siendo coherentes. Las comprobaciones comunes incluyen:

• Comparar los recuentos de filas de las colecciones importantes.
• Consultar claves primarias conocidas de ambos clústeres.
• Ejecutar una búsqueda representativa en el nuevo primario y en el antiguo en espera.
• Ejecutar una pequeña escritura en cluster-b y confirmar que se replica en cluster-a.

Volver atrás

Para volver a conmutar más tarde, aplique de nuevo la topología original:

cluster-a -> cluster-b

Utilice el mismo flujo de conmutación. Asegúrese de que se puede acceder al primario actual y de que la replicación es correcta antes de volver a conmutar.

PREGUNTAS FRECUENTES

¿Pierde datos la conmutación?

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

¿Debo detener las escrituras de la aplicación?

Debe pausar las escrituras o hacer que se puedan reintentar durante el cambio de rol. Se rechazan las escrituras enviadas al antiguo primario después de su degradación.

¿Por qué la conmutación tarda más de lo esperado?

La razón más común es el retraso del CDC. El nuevo primario debe recibir los datos restantes antes de que pueda tomar el relevo de forma segura con RPO = 0.

¿Puedo reintentar una petición de conmutación fallida?

Sí. Vuelva a intentarlo con la misma topología de destino.

¿Qué ocurre con el antiguo primario?

El primario antiguo se convierte en un repositorio. Ya no debería recibir escrituras de aplicaciones.