Configuration de la réplication CDC

Ce guide montre comment déployer deux clusters Milvus autonomes avec Milvus Operator et configurer la réplication CDC d'un cluster source vers un cluster cible.

Les exemples utilisent :

• source-cluster comme cluster primaire.
• target-cluster comme cluster de secours.
• milvus comme espace de noms pour les clusters Milvus.
• milvus-operator comme espace de noms pour Milvus Operator.

Avant de commencer, lisez Milvus CDC pour comprendre le modèle primaire-standby et les options de basculement.

Conditions préalables

• Milvus v2.6.16 ou version ultérieure.
• Milvus Operator v1.3.4 ou version ultérieure.
• Un cluster Kubernetes est disponible.
• Les clusters source et cible peuvent se connecter l'un à l'autre sur le réseau.
• Vous disposez d'informations d'identification d'administrateur pour les deux clusters Milvus.
• Vous connaissez le nombre de canaux physiques pour chaque cluster.

Etape 1 : Mise à niveau de Milvus Operator

Ajouter le référentiel Milvus Operator Helm :

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/

Mettre à jour le référentiel :

helm repo update zilliztech-milvus-operator

Installer ou mettre à niveau Milvus Operator :

helm -n milvus-operator upgrade --install milvus-operator \
  zilliztech-milvus-operator/milvus-operator \
  --create-namespace

Vérifier que le pod opérateur est en cours d'exécution :

kubectl get pods -n milvus-operator

Exemple de sortie :

NAME                               READY   STATUS    RESTARTS   AGE
milvus-operator-6f7d8c9c7d-xm4tj   1/1     Running   0          54s

Étape 2 : Déploiement du cluster source

Créer un fichier nommé milvus_source_cluster.yaml:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: source-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: standalone
  components:
    image: milvusdb/milvus:v2.6.16
    cdc:
      replicas: 1
  dependencies:
    msgStreamType: woodpecker

Appliquer la configuration :

kubectl create namespace milvus
kubectl apply -f milvus_source_cluster.yaml

Vérifier que les pods du cluster source sont en cours d'exécution :

kubectl get pods -n milvus

Exemple de résultat :

NAME                                                   READY   STATUS    RESTARTS   AGE
source-cluster-etcd-0                                  1/1     Running   0          3m
source-cluster-minio-6d8f7d9b9f-9t7j2                  1/1     Running   0          3m
source-cluster-milvus-standalone-7f8d9c8f6d-r2m5x      1/1     Running   0          2m
source-cluster-milvus-cdc-66d64747bd-sckxj             1/1     Running   0          2m

Assurez-vous que le pod CDC, tel que source-cluster-milvus-cdc-..., est dans l'état Running.

Étape 3 : Déployer le cluster cible

Créez un fichier nommé milvus_target_cluster.yaml:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: target-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: standalone
  components:
    image: milvusdb/milvus:v2.6.16
    cdc:
      replicas: 1
  dependencies:
    msgStreamType: woodpecker

Le composant CDC est également activé sur le cluster cible. Il est inactif tant que la cible est en standby, mais il est nécessaire si la cible devient primaire après le basculement.

Appliquez la configuration :

kubectl apply -f milvus_target_cluster.yaml

Vérifiez que les pods du cluster cible sont en cours d'exécution :

kubectl get pods -n milvus | grep -E 'NAME|target-cluster'

Exemple de sortie :

NAME                                                   READY   STATUS    RESTARTS   AGE
target-cluster-etcd-0                                  1/1     Running   0          3m
target-cluster-minio-5f7c8d9b6f-k8s2q                  1/1     Running   0          3m
target-cluster-milvus-standalone-66dc8d9f7f-5n6bp      1/1     Running   0          2m
target-cluster-milvus-cdc-7f8c9d6b8c-q4t9m             1/1     Running   0          2m

Étape 4 : Préparation des informations sur le cluster

Obtenir les adresses de service Milvus pour les deux clusters :

kubectl get svc -n milvus | grep -E 'NAME|source-cluster|target-cluster'

Exemple de résultat :

NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)              AGE
source-cluster-milvus                 ClusterIP   10.98.124.90     <none>        19530/TCP,9091/TCP   8m
target-cluster-milvus                 ClusterIP   10.109.234.172   <none>        19530/TCP,9091/TCP   3m

Préparer deux types d'adresses :

• Les adresses de cluster sont écrites dans la configuration de réplication et utilisées par les composants CDC. Ces adresses doivent être accessibles à partir des modules CDC.
• Les adresses client sont utilisées uniquement par votre client Python lors de l'appel des API Milvus. Si vous exécutez le client Python en dehors du cluster Kubernetes, exposez les services Milvus via votre méthode d'accès normale, telle qu'un équilibreur de charge, un ingress ou un port-forward.

Préparez les informations de connexion et les listes pchannel pour les deux clusters :

source_cluster_addr = "http://source-cluster-milvus.milvus.svc.cluster.local:19530"
target_cluster_addr = "http://target-cluster-milvus.milvus.svc.cluster.local:19530"

source_client_addr = source_cluster_addr
target_client_addr = target_cluster_addr

# If your Python client runs outside the Kubernetes cluster, replace only
# source_client_addr and target_client_addr with externally reachable addresses.
# Keep source_cluster_addr and target_cluster_addr reachable from CDC pods.
# For example:
# source_client_addr = "http://127.0.0.1:19530"
# target_client_addr = "http://127.0.0.1:19531"

source_cluster_token = "root:Milvus"
target_cluster_token = "root:Milvus"

source_cluster_id = "source-cluster"
target_cluster_id = "target-cluster"

pchannel_num = 16
source_cluster_pchannels = [
    f"{source_cluster_id}-rootcoord-dml_{i}"
    for i in range(pchannel_num)
]
target_cluster_pchannels = [
    f"{target_cluster_id}-rootcoord-dml_{i}"
    for i in range(pchannel_num)
]

Remplacer les adresses par les adresses réelles des services Milvus dans votre environnement. Ne définissez pas source_cluster_addr ou target_cluster_addr sur une adresse locale de transfert de port, sauf si les pods CDC peuvent également atteindre cette adresse. La liste pchannel doit correspondre à votre déploiement Milvus. Ne copiez pas les valeurs de l'exemple sans vérifier la configuration de votre cluster.

Etape 5 : Créer la configuration de réplication

Créer une configuration de réplication de source-cluster vers target-cluster:

replicate_config = {
    "clusters": [
        {
            "cluster_id": source_cluster_id,
            "connection_param": {
                "uri": source_cluster_addr,
                "token": source_cluster_token,
            },
            "pchannels": source_cluster_pchannels,
        },
        {
            "cluster_id": target_cluster_id,
            "connection_param": {
                "uri": target_cluster_addr,
                "token": target_cluster_token,
            },
            "pchannels": target_cluster_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": source_cluster_id,
            "target_cluster_id": target_cluster_id,
        }
    ],
}

Etape 6 : Appliquer la configuration de réplication

Appliquez la même configuration aux deux clusters :

from pymilvus import MilvusClient

source_client = MilvusClient(
    uri=source_client_addr,
    token=source_cluster_token,
)
target_client = MilvusClient(
    uri=target_client_addr,
    token=target_cluster_token,
)

try:
    source_client.update_replicate_configuration(**replicate_config)
    target_client.update_replicate_configuration(**replicate_config)
finally:
    source_client.close()
    target_client.close()

Pour l'automatisation de la production, utilisez des clients distincts de courte durée pour cette opération du plan de contrôle. Cela évite de partager le même canal gRPC avec le trafic DML de l'application pendant que le rôle du cluster change.

Une fois la configuration appliquée, les modifications écrites sur source-cluster sont répliquées sur target-cluster.

Étape 7 : Vérifier la réplication des données

Pour vérifier que la réplication fonctionne :

1. Connectez-vous à source-cluster.
2. Créez une collection.
3. Insérez des données dans la collection.
4. Chargez la collection et exécutez une requête ou une recherche sur source-cluster.
5. Connectez-vous à target-cluster.
6. Exécutez la même requête ou recherche sur target-cluster sans charger manuellement la collection sur le cluster en attente.
7. Confirmez que les données attendues sont visibles sur les deux clusters.

Le cluster cible est un cluster en attente dans cette topologie. N'exécutez pas d'opérations DDL ou DCL manuelles, telles que load_collection, sur le cluster en attente. Ces opérations doivent être effectuées sur le cluster source et répliquées sur le cluster cible.

Le code de vérification exact dépend de votre schéma de collecte. Pour un workflow de collecte Milvus de base, voir la documentation de démarrage rapide Milvus.

CDC Lag

Le décalage CDC est la fenêtre de données entre les clusters primaire et de secours. Vous devez le surveiller en permanence après la configuration de la réplication.

Le décalage CDC peut augmenter dans les cas suivants

• Le taux d'écriture primaire est élevé.
• La latence du réseau ou la perte de paquets augmente entre les clusters.
• Le cluster en attente est surchargé.
• Les nœuds CDC sont sous-provisionnés.
• Des opérations DDL ou d'importation importantes sont en cours.

Utilisez le décalage du CDC pour guider les décisions opérationnelles :

• Si le décalage est faible, le basculement devrait s'effectuer plus rapidement.
• Si le délai est élevé, le basculement risque de perdre davantage de données.

Vous pouvez estimer le délai CDC à l'aide de la requête PromQL suivante :

clamp_min(
  max by (channel_name) (
    milvus_wal_last_confirmed_time_tick
  )
  -
  min by (channel_name) (
    milvus_cdc_last_replicated_time_tick
  ),
  0
)

Le résultat est exprimé en secondes. Pour chaque canal source, la requête compare le dernier timetick WAL confirmé avec le dernier timetick répliqué par CDC. Si une source primaire réplique sur plusieurs clusters en attente, l'expression min by (channel_name) signale la progression la plus lente de la réplication pour ce canal.

Si Prometheus scrape plusieurs clusters Milvus, ajoutez des filtres d'étiquettes correspondant à votre déploiement, tels que namespace ou app_kubernetes_io_instance, afin d'éviter de mélanger des mesures provenant de différents clusters.

FAQ

Dois-je appeler update_replicate_configuration sur les deux clusters ?

Oui. Appliquez la même topologie à tous les clusters participants. Si un cluster n'est pas primaire au moment de l'appel, il attend que la topologie soit appliquée par le CDC.

Comment dois-je choisir cluster_id?

Utilisez un identifiant stable et unique pour chaque cluster. L'ID est également utilisé dans les noms des canaux de transfert et les références de la topologie de réplication.

Puis-je modifier les pchannels une fois la réplication configurée ?

Vous pouvez mettre à jour la topologie, mais la liste des pchannels doit correspondre à la configuration du cluster. Considérez les modifications de pchannel comme une opération avancée et vérifiez soigneusement la réplication par la suite.