Milvus CDC

Milvus CDC (Change Data Capture) réplique les modifications de données d'un cluster Milvus à un autre. Vous pouvez utiliser CDC pour construire une topologie de reprise après sinistre primaire-standby pour Milvus.

Dans une topologie primaire-standby, un cluster agit en tant que primaire et accepte les écritures. Un ou plusieurs clusters en attente reçoivent en permanence les modifications du cluster principal et peuvent prendre en charge le trafic de lecture. Lorsque le cluster primaire devient indisponible ou nécessite une maintenance, vous pouvez basculer le trafic de service vers un cluster en attente.

L'architecture

Une topologie typique comprend

• Cluster primaire: Le cluster source pour la réplication. Il accepte les lectures et les écritures.
• Cluster de secours: Un cluster cible pour la réplication. Il reçoit les modifications du cluster primaire et est en lecture seule tant qu'il reste en attente.
• Nœud CDC: Un composant Milvus qui transmet les modifications WAL du cluster primaire actuel aux clusters en attente. Déployer le CDC sur chaque cluster susceptible de devenir primaire après un basculement ou une défaillance.
• Topologie de réplication: La relation source-cible configurée, telle que cluster-a -> cluster-b. Voici une illustration de la topologie. Flux de travail CDC

Topologies prises en charge

Le déploiement CDC le plus courant est celui d'un primaire et d'un standby :

Application writes
      |
      v
Primary cluster A  -- CDC replication -->  Standby cluster B

Milvus CDC prend également en charge une topologie simple primaire et multi-standby :

Primary cluster A  -- CDC replication -->  Standby cluster B
                  \-- CDC replication -->  Standby cluster C

Milvus CDC ne prend pas en charge les déploiements multi-primaires ou actif-actif, dans lesquels deux clusters ou plus acceptent le trafic d'écriture en même temps.

Comportement primaire et de secours

Rôle	Lecture	Écritures	Comportement de réplication
Primaire	Oui	Oui	Envoie les modifications aux clusters en standby
En attente	Oui	Non	Reçoit les modifications répliquées du cluster primaire

Un cluster en attente rejette les demandes d'écriture directes. Cela permet d'éviter le "split brain" et de maintenir la cohérence de la topologie de réplication.

Basculement planifié ou basculement

Milvus CDC propose deux façons de déplacer le trafic de service du primaire actuel vers un cluster en attente.

Fonctionnement	Utilisation en cas de	Perte de données	Comportement attendu
Basculement	Le système primaire actuel est toujours joignable, ou vous effectuez une maintenance planifiée.	RPO = 0	Attente des données répliquées restantes avant le changement de rôle
Basculement	Le serveur principal actuel est indisponible et ne peut pas être rétabli rapidement.	Possible	Promouvoir immédiatement l'état de veille pour que les écritures puissent reprendre.

Utiliser le basculement chaque fois que le serveur principal actuel peut encore répondre. N'utilisez le basculement que si le rétablissement de la disponibilité est plus important que l'attente du serveur principal d'origine.

Le décalage du CDC et son importance

Le décalage du CDC correspond à la quantité de données qui ont été écrites sur le cluster primaire mais qui n'ont pas encore été appliquées à un cluster de secours.

Le décalage du CDC affecte les deux options de récupération :

• Lors du basculement, un délai CDC plus faible signifie généralement que l'opération se termine plus rapidement.
• Lors du basculement, le décalage du CDC représente la fenêtre de données qui risque d'être perdue si le cluster primaire d'origine n'est pas disponible.

Vous devez surveiller en permanence le décalage du CDC et le maintenir à un niveau aussi bas que possible. La page Configurer la réplication CDC contient un exemple de PromQL pour estimer le décalage CDC.

Limitations

Milvus CDC présente actuellement les limites suivantes :

• Il ne prend en charge que les topologies monoprimaires.
• Il ne prend pas en charge les écritures actives-actives ou multi-primaires.
• Les clusters en veille peuvent servir le trafic de lecture, mais ils rejettent les écritures directes tant qu'ils restent en veille.
• Le basculement peut perdre des données qui ont été écrites sur l'ancien primaire mais qui n'ont pas encore été répliquées sur le standby.
• La configuration de pchannels doit correspondre à la disposition réelle des canaux de chaque cluster.

FAQ

Un cluster en standby peut-il servir des requêtes ?

Oui. Un cluster en attente peut servir le trafic de lecture. Il ne peut pas accepter d'écritures tant qu'il n'est pas devenu primaire.

Milvus CDC prend-il en charge les écritures actives-actives ?

Non. Milvus CDC est conçu pour une topologie primaire unique. L'écriture sur plusieurs clusters en même temps peut entraîner un fractionnement du cerveau et une divergence des données.

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.

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

C'est possible. Toutes les données écrites sur l'ancien serveur principal mais qui n'ont pas encore été répliquées sur le serveur de secours peuvent être perdues.

Quelle quantité de données peut être perdue lors d'un basculement ?

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