CDC-Replikation einrichten

In dieser Anleitung wird gezeigt, wie zwei eigenständige Milvus-Cluster mit Milvus Operator bereitgestellt und die CDC-Replikation von einem Quellcluster zu einem Zielcluster konfiguriert wird.

Die Beispiele verwenden:

• source-cluster als Primärcluster.
• target-cluster als den Standby-Cluster.
• milvus als Namespace für Milvus-Cluster.
• milvus-operator als Namespace für Milvus Operator.

Bevor Sie beginnen, lesen Sie Milvus CDC, um das Primary-Standby-Modell und die Failover-Optionen zu verstehen.

Voraussetzungen

• Milvus v2.6.16 oder höher.
• Milvus Operator v1.3.4 oder höher.
• Ein Kubernetes-Cluster ist verfügbar.
• Die Quell- und Zielcluster können sich über das Netzwerk miteinander verbinden.
• Sie verfügen über Admin-Zugangsdaten für beide Milvus-Cluster.
• Sie kennen die Anzahl der physischen Kanäle für jeden Cluster.

Schritt 1: Upgrade von Milvus Operator

Fügen Sie das Milvus Operator Helm-Repository hinzu:

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

Aktualisieren Sie das Repository:

helm repo update zilliztech-milvus-operator

Installieren oder aktualisieren Sie Milvus Operator:

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

Überprüfen Sie, ob der Operator-Pod läuft:

kubectl get pods -n milvus-operator

Beispielhafte Ausgabe:

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

Schritt 2: Bereitstellen des Quellclusters

Erstellen Sie eine Datei mit dem Namen 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

Wenden Sie die Konfiguration an:

kubectl create namespace milvus
kubectl apply -f milvus_source_cluster.yaml

Überprüfen Sie, ob die Quellcluster-Pods ausgeführt werden:

kubectl get pods -n milvus

Beispielhafte Ausgabe:

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

Vergewissern Sie sich, dass sich der CDC-Pod, z. B. source-cluster-milvus-cdc-..., im Zustand Running befindet.

Schritt 3: Bereitstellen des Zielclusters

Erstellen Sie eine Datei mit dem Namen 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

Die CDC-Komponente ist auch auf dem Zielcluster aktiviert. Sie ist inaktiv, solange das Ziel als Standby fungiert, wird aber benötigt, wenn das Ziel später nach dem Switchover zum Primary wird.

Wenden Sie die Konfiguration an:

kubectl apply -f milvus_target_cluster.yaml

Überprüfen Sie, ob die Pods des Ziel-Clusters laufen:

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

Beispielhafte Ausgabe:

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

Schritt 4: Vorbereiten der Cluster-Informationen

Ermitteln Sie die Milvus-Dienstadressen für beide Cluster:

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

Beispielhafte Ausgabe:

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

Bereiten Sie zwei Arten von Adressen vor:

• Clusteradressen werden in die Replikationskonfiguration geschrieben und von den CDC-Komponenten verwendet. Diese Adressen müssen von den CDC-Pods aus erreichbar sein.
• Client-Adressen werden nur von Ihrem Python-Client beim Aufruf von Milvus-APIs verwendet. Wenn Sie den Python-Client außerhalb des Kubernetes-Clusters ausführen, stellen Sie die Milvus-Dienste über Ihre normale Zugriffsmethode bereit, z. B. über einen Load Balancer, Ingress oder Port-Forward.

Bereiten Sie die Verbindungsinformationen und pchannel-Listen für beide Cluster vor:

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

Ersetzen Sie die Adressen durch die tatsächlichen Adressen der Milvus-Dienste in Ihrer Umgebung. Setzen Sie source_cluster_addr oder target_cluster_addr nicht auf eine lokale Port-Forward-Adresse, es sei denn, die CDC-Pods können diese Adresse ebenfalls erreichen. Die pchannel-Liste muss mit Ihrem Milvus-Einsatz übereinstimmen. Kopieren Sie die Beispielwerte nicht, ohne Ihre Clusterkonfiguration zu überprüfen.

Schritt 5: Erstellen der Replikationskonfiguration

Erstellen Sie eine Replikationskonfiguration von source-cluster auf 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,
        }
    ],
}

Schritt 6: Anwenden der Replikationskonfiguration

Wenden Sie die gleiche Konfiguration auf beide Cluster an:

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

Verwenden Sie für die Produktionsautomatisierung separate kurzlebige Clients für diese Control-Plane-Operation. Dadurch wird vermieden, dass der gleiche gRPC-Kanal mit Anwendungs-DML-Verkehr geteilt wird, während sich die Clusterrolle ändert.

Nachdem die Konfiguration angewendet wurde, werden die auf source-cluster geschriebenen Änderungen auf target-cluster repliziert.

Schritt 7: Überprüfen der Datenreplikation

So überprüfen Sie, ob die Replikation funktioniert:

1. Stellen Sie eine Verbindung zu source-cluster her.
2. Erstellen Sie eine Sammlung.
3. Fügen Sie Daten in die Sammlung ein.
4. Laden Sie die Sammlung und führen Sie eine Abfrage oder Suche auf source-cluster durch.
5. Stellen Sie eine Verbindung zu target-cluster her.
6. Führen Sie dieselbe Abfrage oder Suche auf target-cluster aus, ohne die Sammlung manuell auf den Standby-Cluster zu laden.
7. Bestätigen Sie, dass die erwarteten Daten auf beiden Clustern sichtbar sind.

Der Zielcluster ist in dieser Topologie ein Standby-Cluster. Führen Sie keine manuellen DDL- oder DCL-Vorgänge, wie z. B. load_collection, auf dem Standby-Cluster aus. Diese Operationen sollten auf dem Quellcluster durchgeführt und auf den Zielcluster repliziert werden.

Der genaue Verifizierungscode hängt von Ihrem Sammelschema ab. Einen grundlegenden Arbeitsablauf für Milvus-Sammlungen finden Sie in der Milvus-Schnellstartdokumentation.

CDC-Verzögerung

CDC Lag ist das Datenfenster zwischen dem primären und dem Standby-Cluster. Sie sollten es kontinuierlich überwachen, nachdem die Replikation konfiguriert wurde.

Der CDC-Lag kann sich vergrößern, wenn:

• Die primäre Schreibrate ist hoch.
• Die Netzwerklatenz oder der Paketverlust zwischen den Clustern steigt.
• Der Standby-Cluster ist überlastet.
• CDC-Knoten sind unterdimensioniert.
• Große DDL- oder Import-Operationen ausgeführt werden.

Verwenden Sie die CDC-Verzögerung, um betriebliche Entscheidungen zu treffen:

• Wenn die Verzögerung gering ist, sollte die Umschaltung schneller erfolgen.
• Wenn die Verzögerung hoch ist, können beim Failover mehr Daten verloren gehen.

Sie können die CDC-Verzögerung mit der folgenden PromQL-Abfrage schätzen:

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

Das Ergebnis ist in Sekunden angegeben. Für jeden Quellkanal vergleicht die Abfrage den letzten bestätigten WAL-Zeitstempel mit dem letzten von CDC replizierten Zeitstempel. Wenn ein primärer Cluster zu mehreren Standby-Clustern repliziert, gibt der Ausdruck min by (channel_name) den langsamsten Replikationsfortschritt für diesen Kanal an.

Wenn Prometheus mehrere Milvus-Cluster durchsucht, fügen Sie Bezeichnungsfilter hinzu, die zu Ihrer Bereitstellung passen, z. B. namespace oder app_kubernetes_io_instance, um zu vermeiden, dass Metriken von verschiedenen Clustern vermischt werden.

FAQ

Muss ich update_replicate_configuration auf beiden Clustern aufrufen?

Ja. Wenden Sie dieselbe Topologie auf alle beteiligten Cluster an. Wenn ein Cluster zum Zeitpunkt des Aufrufs nicht primär ist, wartet er, bis die Topologie über CDC angewendet wird.

Wie sollte ich cluster_id auswählen?

Verwenden Sie eine stabile, eindeutige ID für jeden Cluster. Die ID wird auch in pchannel-Namen und Replikationstopologiereferenzen verwendet.

Kann ich pchannels ändern, nachdem die Replikation konfiguriert wurde?

Sie können die Topologie aktualisieren, aber die pchannel-Liste muss mit dem Cluster-Layout übereinstimmen. Behandeln Sie pchannel-Änderungen als erweiterten Vorgang und überprüfen Sie die Replikation anschließend sorgfältig.