Basculement

Le basculement modifie la direction primaire-standby sans perte de données. Utilisez-le lorsque le cluster primaire actuel est encore accessible, ou lorsque vous devez déplacer le trafic pour des raisons de maintenance.

Ce guide part du principe que la topologie actuelle est la suivante :

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

Après le basculement, la topologie devient :

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

Quand utiliser le basculement

Utilisez le basculement lorsque :

• Vous effectuez des opérations de maintenance sur le serveur principal actuel.
• Le primaire est partiellement dégradé mais peut encore répondre aux demandes.
• Vous avez besoin d'un RPO = 0 et ne pouvez pas accepter de perte de données.

N'utilisez pas le basculement si le serveur principal est totalement indisponible. Dans ce cas, utilisez le basculement.

Avant de commencer

Vérifiez les points suivants avant de commencer :

• Les deux clusters sont accessibles.
• La réplication CDC est saine.
• Le décalage du CDC est suffisamment faible pour votre objectif de temps de récupération.
• Les écritures d'applications peuvent être interrompues ou réessayées pendant le changement de rôle.
• Vous avez préparé la nouvelle configuration topologique.

Le basculement garantit l'absence de perte de données, mais la durée de l'opération dépend de la quantité de données restant à répliquer.

Construire la nouvelle topologie

Créez une configuration de remplacement complet où cluster-b devient la source et cluster-a la cible.

# 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,
        }
    ],
}

Appliquer la nouvelle topologie

Appliquez la même configuration aux deux clusters. Envoyez d'abord la requête à l'unité primaire actuelle, puis à l'unité de secours. Si vous revenez plus tard, inversez l'ordre car cluster-b est le primaire actuel.

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()

L'ancien primaire passe en standby et rejette les nouvelles écritures. L'ancien standby attend les données répliquées restantes, devient primaire, puis accepte les écritures.

Si la demande échoue en raison d'une erreur transitoire de réseau ou de service, réessayez avec la même configuration.

Redirection du trafic de l'application

Une fois que cluster-b est devenu primaire :

1. Diriger le trafic d'écriture vers cluster-b.
2. Confirmez que les lectures et les écritures réussissent sur cluster-b.
3. Confirmez que cluster-a ne reçoit plus d'écritures d'application.
4. Continuez à surveiller la réplication de cluster-b vers cluster-a.

Vérifier le résultat

Vérifiez que cluster-b sert de nouveau serveur principal et que les données restent cohérentes. Les vérifications les plus courantes sont les suivantes

• Comparer le nombre de lignes pour les collections importantes.
• Interroger les clés primaires connues des deux clusters.
• Exécutez une recherche représentative sur le nouveau primaire et l'ancien standby.
• Exécutez une petite écriture sur cluster-b et confirmez qu'elle est répliquée sur cluster-a.

Revenir en arrière

Pour rebasculer ultérieurement, appliquez à nouveau la topologie d'origine :

cluster-a -> cluster-b

Utilisez le même flux de basculement. Assurez-vous que le primaire actuel est joignable et que la réplication est saine avant de rebasculer.

FAQ

Le basculement entraîne-t-il une perte de données ?

Non. Le basculement attend que les données restantes soient répliquées avant que le standby ne devienne primaire.

Dois-je arrêter les écritures sur les applications ?

Vous devez interrompre les écritures ou faire en sorte que les écritures puissent être tentées à nouveau pendant le changement de rôle. Les écritures envoyées à l'ancien serveur principal après sa rétrogradation sont rejetées.

Pourquoi le basculement prend-il plus de temps que prévu ?

La raison la plus fréquente est le décalage du CDC. Le nouveau serveur principal doit recevoir les données restantes avant de pouvoir prendre le relais en toute sécurité avec RPO = 0.

Puis-je réessayer une demande de basculement qui a échoué ?

Oui. Réessayez avec la même topologie cible.

Qu'arrive-t-il à l'ancien serveur principal ?

L'ancien serveur principal devient un serveur de secours. Il ne doit plus recevoir d'écritures d'application.