Basculement

Le basculement permet de promouvoir un cluster en attente vers un cluster primaire autonome lorsque le cluster primaire d'origine est totalement indisponible. Il s'agit d'une opération qui privilégie la disponibilité et qui peut entraîner la perte de données qui n'ont pas été répliquées avant la panne.

Ce guide suppose que la topologie d'origine est :

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

Après le basculement, cluster-b devient un serveur primaire autonome :

cluster-b (primary)

Quand utiliser le basculement

N'utilisez le basculement que dans les cas suivants

• Le serveur principal d'origine ne peut pas répondre aux demandes.
• Le serveur principal ne peut pas être rétabli dans un délai acceptable.
• Le rétablissement de la disponibilité en écriture est plus important que l'attente de l'ancien serveur principal.

Si le serveur principal est toujours joignable, utilisez plutôt le basculement. Le basculement permet d'éviter la perte de données.

Risque de perte de données

Le basculement n'attend pas l'ancien serveur primaire. Toutes les données écrites sur l'ancien serveur principal mais non encore répliquées sur le serveur de secours peuvent être perdues.

La perte éventuelle de données est déterminée par le décalage du CDC au moment où le serveur principal est devenu indisponible.

Avant d'exécuter le basculement, il faut comprendre le compromis :

Objectif	Basculement	Basculement
Restaurer les écritures lorsque le serveur principal est inaccessible	Non	Oui
Éviter la perte de données	Oui	Non garanti
Nécessité d'une réponse de l'ancien système primaire	Oui	Non

Avant de commencer

Confirmez ce qui suit :

• Le serveur principal d'origine n'est pas disponible.
• Vous avez décidé de ne pas attendre le rétablissement du primaire.
• Le trafic applicatif peut être redirigé vers le serveur de secours.
• L'automatisation du trafic ne renverra pas d'écritures à l'ancien primaire s'il se rétablit.
• Vous disposez de l'ID, de l'adresse, du jeton et des canaux p du cluster de secours.

L'exigence de sécurité la plus importante est d'éviter le "split brain". Après le basculement, seul le standby promu doit accepter les écritures d'application.

Construire la configuration de basculement

Construisez une configuration qui ne contient que le cluster de secours et aucune topologie de réplication. Définissez 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,
}

Promouvoir le standby

Envoyez la demande au cluster en attente.

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 demande aboutit, cluster-b devient un primaire autonome et peut accepter des écritures.

Redirection du trafic de l'application

Après la promotion :

1. Redirigez le trafic d'écriture vers cluster-b.
2. Supprimez cluster-a des points de terminaison d'écriture, des équilibreurs de charge, des enregistrements DNS et de l'automatisation.
3. Vérifiez que cluster-b accepte les écritures.
4. Maintenir cluster-a isolé jusqu'à ce qu'il soit mis hors service ou reconstruit explicitement.

Exemple de vérification de l'écriture :

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

Ajustez les champs de nom de collection et de schéma pour qu'ils correspondent à votre déploiement.

Vérifier le résultat

Vérifiez directement le cluster promu :

• Les écritures réussissent sur cluster-b.
• Les lectures renvoient les données attendues.
• Aucun composant d'application n'écrit sur cluster-a.

Gestion de l'ancien primaire

Après le basculement, traitez cluster-a comme stale. N'y envoyez pas d'écritures d'application s'il redevient accessible. Il peut contenir des données qui n'ont jamais été répliquées sur cluster-b, et cluster-b peut déjà contenir de nouvelles écritures après le basculement.

Ne reconnectez pas automatiquement cluster-a à l'ancienne topologie. La réintroduction de l'ancien primaire est une tâche de récupération distincte qui doit être planifiée avec soin.

Minimiser les pertes de données

Vous ne pouvez pas éliminer tous les risques de perte de données liés au basculement, mais vous pouvez les réduire :

• Surveillez en permanence le décalage du CDC.
• Gardez les clusters de secours provisionnés pour gérer le taux d'écriture du primaire.
• Veillez à ce que la latence du réseau inter-clusters et la perte de paquets soient faibles.
• Faites en sorte que les écritures des applications soient idempotentes.
• Réessayer les écritures dont le succès est incertain après le basculement.
• Préférer le basculement lorsque le serveur principal peut encore répondre.

QUESTIONS FRÉQUEMMENT POSÉES

Le basculement entraîne-t-il toujours des pertes de données ?

Non, mais c'est possible. Si toutes les écritures ont déjà été répliquées avant la défaillance du serveur principal, aucune donnée n'est perdue. En cas de décalage du CDC, les données en retard peuvent être perdues.

Combien de temps dure le basculement ?

Il s'effectue généralement en quelques secondes, en fonction de l'état du cluster et de la disponibilité du plan de contrôle sur le standby.

Puis-je exécuter le basculement sur l'ordinateur principal ?

Non. Le basculement est destiné à un cluster en attente. Si le système primaire actuel est disponible, utilisez le basculement.

L'ancien serveur principal peut-il se reconnecter automatiquement ?

Non. Après le basculement, l'ancien serveur primaire doit être considéré comme périmé et mis hors service ou reconstruit avant de pouvoir participer à nouveau à la réplication.

Comment éviter le "split brain" ?

Veillez à ce que seul le cluster promu reçoive des écritures. Retirez l'ancien cluster primaire de tous les chemins d'écriture avant qu'il ne puisse se rétablir et accepter du trafic.