Home
Blog
Vector Datenbank-Hochverfügbarkeit: Aufbau eines Milvus Standby-Clusters mit CDC

Vector Datenbank-Hochverfügbarkeit: Aufbau eines Milvus Standby-Clusters mit CDC

Tutorials

March 26, 2026

Cal Huang

Jede Produktionsdatenbank braucht einen Plan für den Fall, dass etwas schief geht. Relationale Datenbanken verfügen schon seit Jahrzehnten über WAL-Versand, Binlog-Replikation und automatisches Failover. Aber Vektordatenbanken - obwohl sie zur Kerninfrastruktur für KI-Anwendungen geworden sind - holen in dieser Hinsicht noch auf. Die meisten bieten bestenfalls Redundanz auf Knotenebene. Wenn ein kompletter Cluster ausfällt, müssen Sie von Backups wiederherstellen und Vektorindizes von Grund auf neu erstellen - ein Prozess, der Stunden dauern und Tausende von Rechenkosten verursachen kann, da die Neugenerierung von Einbettungen durch Ihre ML-Pipeline nicht billig ist.

Milvus verfolgt einen anderen Ansatz. Es bietet eine mehrschichtige Hochverfügbarkeit: Replikate auf Knotenebene für ein schnelles Failover innerhalb eines Clusters, CDC-basierte Replikation für den Schutz auf Clusterebene und über Regionen hinweg sowie ein Backup für die Wiederherstellung des Sicherheitsnetzes. Dieses mehrschichtige Modell ist bei herkömmlichen Datenbanken Standard - Milvus ist die erste große Vektordatenbank, die es auf Vektor-Workloads anwendet.

Dieser Leitfaden deckt zwei Dinge ab: die Hochverfügbarkeitsstrategien, die für Vektordatenbanken verfügbar sind (damit Sie beurteilen können, was "produktionsreif" tatsächlich bedeutet), und ein praktisches Tutorial für die Einrichtung der Milvus CDC Primär-Standby-Replikation von Grund auf.

Dies ist Teil 1 einer Serie:

Teil 1 (dieser Artikel): Einrichten der Primär-/Standby-Replikation auf neuen Clustern

Teil 2: Hinzufügen von CDC zu einem bestehenden Cluster, der bereits Daten hat, mit Milvus Backup

Teil 3: Verwalten von Failover - Promoten des Standby, wenn der Primary ausfällt

Warum ist Hochverfügbarkeit für Vektordatenbanken wichtiger?

Wenn eine herkömmliche SQL-Datenbank ausfällt, verlieren Sie den Zugriff auf strukturierte Datensätze - die Daten selbst können jedoch in der Regel aus vorgelagerten Quellen reimportiert werden. Wenn eine Vektordatenbank ausfällt, ist die Wiederherstellung wesentlich schwieriger.

Vektordatenbanken speichern Einbettungen - dichte numerische Darstellungen, die von ML-Modellen erzeugt werden. Um sie wiederherzustellen, muss der gesamte Datensatz die Einbettungspipeline erneut durchlaufen: Laden der Rohdokumente, Chunking, Aufrufen eines Einbettungsmodells und Neuindizierung. Bei einem Datensatz mit Hunderten von Millionen von Vektoren kann dies Tage dauern und Tausende von Dollar an GPU-Rechenleistung kosten.

In der Zwischenzeit befinden sich die Systeme, die von der Vektorsuche abhängen, oft in der kritischen Phase:

RAG-Pipelines, die kundenorientierte Chatbots und die Suche antreiben - wenn die Vektordatenbank ausfällt, wird die Abfrage gestoppt und die KI liefert generische oder halluzinierte Antworten.
Empfehlungsmaschinen, die Produkt- oder Inhaltsvorschläge in Echtzeit liefern - Ausfallzeiten bedeuten entgangene Einnahmen.
Betrugserkennungs- und Anomalieüberwachungssysteme, die sich auf die Ähnlichkeitssuche stützen, um verdächtige Aktivitäten zu erkennen - eine Lücke in der Abdeckung schafft ein Fenster der Anfälligkeit.
Autonome Agentensysteme, die Vektorspeicher für den Speicher- und Toolabruf verwenden - Agenten versagen oder drehen sich in einer Schleife ohne ihre Wissensbasis.

Wenn Sie Vektordatenbanken für einen dieser Anwendungsfälle evaluieren, ist Hochverfügbarkeit keine "Nice-to-have"-Funktion, die man später überprüfen kann. Sie sollte eines der ersten Dinge sein, auf die Sie achten.

Wie sieht Hochverfügbarkeit in der Produktion für eine Vektordatenbank aus?

Nicht alle Hochverfügbarkeitsfunktionen sind gleich. Eine Vektordatenbank, die nur Knotenausfälle innerhalb eines einzelnen Clusters bewältigt, ist nicht so "hochverfügbar", wie es ein Produktionssystem erfordert. Echte HA muss drei Schichten abdecken:

Schicht	Wovor sie schützt	Wie es funktioniert	Wiederherstellungszeit	Datenverlust
Knotenebene (Mehrfachreplikate)	Absturz eines einzelnen Knotens, Hardwareausfall, OOM-Kill, AZ-Ausfall	Kopiert die gleichen Datensegmente auf mehrere Knoten; andere Knoten absorbieren die Last	Sofort	Null
Cluster-Ebene (CDC-Replikation)	Ausfall des gesamten Clusters - fehlerhaftes K8s-Rollout, Namespace-Löschung, Speicherbeschädigung	Streaming aller Schreibvorgänge an einen Standby-Cluster über das Write-Ahead-Protokoll; der Standby-Cluster ist immer um Sekunden im Rückstand	Minuten	Sekunden
Sicherheitsnetz (regelmäßiges Backup)	Katastrophale Datenbeschädigung, Ransomware, menschliches Versagen, das sich über die Replikation ausbreitet	Erstellt regelmäßige Snapshots und speichert sie an einem separaten Ort	Stunden	Stunden (seit der letzten Sicherung)

Diese Schichten sind komplementär, nicht alternativ. Bei einer Produktionsbereitstellung sollten sie aufeinander aufbauen:

Multi-Replica zuerst - behandelt die häufigsten Ausfälle (Knotenabstürze, AZ-Ausfälle) ohne Ausfallzeit und Datenverlust.
CDC als Nächstes - schützt vor Ausfällen, die Multireplica nicht bewältigen kann: clusterweite Ausfälle, katastrophale menschliche Fehler. Der Standby-Cluster befindet sich in einer anderen Fehlerdomäne.
Regelmäßige Backups - Ihr Sicherheitsnetz der letzten Instanz. Selbst CDC kann Sie nicht retten, wenn beschädigte Daten auf den Standby-Cluster repliziert werden, bevor Sie es bemerken.

Fragen Sie sich bei der Bewertung von Vektordatenbanken: Welche dieser drei Schichten unterstützt das Produkt tatsächlich? Die meisten Vektordatenbanken bieten heute nur die erste an. Milvus unterstützt alle drei, wobei CDC eine eingebaute Funktion ist - kein Add-on eines Drittanbieters.

Was ist Milvus CDC und wie funktioniert es?

Milvus CDC (Change Data Capture) ist eine integrierte Replikationsfunktion, die das Write-Ahead Log (WAL) des primären Clusters liest und jeden Eintrag an einen separaten Standby-Cluster weiterleitet. Der Standby-Cluster repliziert die Einträge und erhält am Ende dieselben Daten, in der Regel mit einigen Sekunden Verspätung.

Das Muster ist in der Datenbankwelt gut etabliert. MySQL hat Binlog-Replikation. PostgreSQL hat WAL-Versand. MongoDB hat eine oplog-basierte Replikation. Dies sind bewährte Techniken, mit denen relationale und Dokumentendatenbanken seit Jahrzehnten in der Produktion laufen. Milvus bietet den gleichen Ansatz für Vektor-Workloads - es ist die erste große Vektordatenbank, die WAL-basierte Replikation als integrierte Funktion anbietet.

Drei Eigenschaften machen CDC zu einer guten Lösung für die Notfallwiederherstellung:

Sync mit niedriger Latenz. CDC überträgt Vorgänge, wenn sie passieren, nicht in geplanten Stapeln. Der Standby bleibt unter normalen Bedingungen nur Sekunden hinter dem Primärserver zurück.
Geordnete Wiederholung. Die Vorgänge kommen in der gleichen Reihenfolge beim Standby an, in der sie geschrieben wurden. Die Daten bleiben ohne Abgleich konsistent.
Checkpoint-Wiederherstellung. Wenn der CDC-Prozess abstürzt oder das Netzwerk ausfällt, wird er dort fortgesetzt, wo er aufgehört hat. Es werden keine Daten übersprungen oder dupliziert.

Wie funktioniert die CDC-Architektur?

Eine CDC-Bereitstellung besteht aus drei Komponenten:

CDC architecture showing Source Cluster with Streaming Nodes and CDC Nodes consuming the WAL, replicating data to the Target Cluster's Proxy layer, which forwards DDL/DCL/DML operations to Streaming Nodes and appends to WAL CDC-Architektur mit Quellcluster mit Streaming-Knoten und CDC-Knoten, die das WAL verbrauchen und Daten an die Proxy-Schicht des Zielclusters replizieren, die DDL/DCL/DML-Operationen an Streaming-Knoten weiterleitet und an das WAL anhängt

Komponente	Rolle
Primärer Cluster	Die Milvus-Produktionsinstanz. Alle Lese- und Schreibvorgänge laufen hier ab. Jeder Schreibvorgang wird in der WAL aufgezeichnet.
CDC-Knoten	Ein Hintergrundprozess neben dem Primärcluster. Liest WAL-Einträge und leitet sie an den Standby weiter. Läuft unabhängig vom Lese-/Schreibpfad - keine Auswirkungen auf die Abfrage- oder Einfügeleistung.
Standby-Cluster	Eine separate Milvus-Instanz, die weitergeleitete WAL-Einträge wiedergibt. Hält dieselben Daten wie die primäre Instanz, mit einer Verzögerung von Sekunden. Kann Leseabfragen bedienen, akzeptiert aber keine Schreibzugriffe.

Der Ablauf: Schreibzugriffe auf die Primärinstanz → der CDC-Knoten kopiert sie auf die Standby-Instanz → die Standby-Instanz gibt sie wieder. Nichts anderes spricht mit dem Schreibpfad des Standby. Wenn der primäre Knoten ausfällt, verfügt der Standby-Knoten bereits über fast alle Daten und kann befördert werden.

Tutorial: Einrichten eines Milvus CDC Standby-Clusters

Der Rest dieses Artikels ist ein praktischer Durchgang. Am Ende werden Sie zwei Milvus-Cluster mit Echtzeit-Replikation zwischen den Clustern in Betrieb haben.

Voraussetzungen

Vor dem Start:

Milvus v2.6.6 oder höher. CDC erfordert diese Version. Der neueste 2.6.x-Patch wird empfohlen.
Milvus Operator v1.3.4 oder höher. Diese Anleitung verwendet den Operator für das Cluster-Management auf Kubernetes.
Ein laufender Kubernetes-Cluster mit kubectl und helm konfiguriert.
Python mit pymilvus für den Konfigurationsschritt der Replikation.

Zwei Einschränkungen in der aktuellen Version:

Einschränkung	Einzelheiten
Einzelne CDC-Replik	Eine CDC-Replik pro Cluster. Verteilte CDC ist für eine zukünftige Version geplant.
Kein BulkInsert	BulkInsert wird nicht unterstützt, wenn CDC aktiviert ist. Ebenfalls für ein zukünftiges Release geplant.

Schritt 1: Upgrade des Milvus Operators

Aktualisieren Sie den Milvus Operator auf v1.3.4 oder höher:

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
# "zilliztech-milvus-operator" has been added to your repositories
helm repo update zilliztech-milvus-operator
# Hang tight while we grab the latest from your chart repositories…
# …Successfully got an update from the “zilliztech-milvus-operator” chart repository
# Update Complete. ⎈Happy Helming!⎈
helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
# Release “milvus-operator” has been upgraded. Happy Helming!
# NAME: milvus-operator
# LAST DEPLOYED: Wed Dec  3 17:25:28 2025
# NAMESPACE: milvus-operator
# STATUS: deployed
# REVISION: 30
# TEST SUITE: None
# NOTES:
# Milvus Operator Is Starting, use kubectl get -n milvus-operator deploy/milvus-operator to check if its successfully installed
# Full Installation doc can be found in https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md
# Quick start with kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_minimum.yaml
# More samples can be found in https://github.com/zilliztech/milvus-operator/tree/main/config/samples
# CRD Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/CRD
# Administration Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/administration

Vergewissern Sie sich, dass der Operator-Pod ausgeführt wird:

kubectl get pods -n milvus-operator
# NAME                             READY   STATUS    RESTARTS   AGE
# milvus-operator-9fc99f88-h2hwz   1/1     Running   0          54s

Schritt 2: Bereitstellen des primären Clusters

Erstellen Sie eine YAML-Datei für den primären (Quell-)Cluster. Der Abschnitt cdc unter components weist den Operator an, einen CDC-Knoten neben dem Cluster bereitzustellen:

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: source-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
    cdc:
      replicas: 1  # Currently, CDC only supports 1 replica
  dependencies:
    msgStreamType: woodpecker

Die Einstellung msgStreamType: woodpecker verwendet die in Milvus integrierte Woodpecker WAL anstelle einer externen Nachrichtenwarteschlange wie Kafka oder Pulsar. Woodpecker ist ein Cloud-natives Write-Ahead-Log, das in Milvus 2.6 eingeführt wurde und die Notwendigkeit einer externen Messaging-Infrastruktur beseitigt.

Wenden Sie die Konfiguration an:

kubectl create namespace milvus
# namespace/milvus created
kubectl apply -f milvus_source_cluster.yaml
# milvus.milvus.io/source-cluster created

Warten Sie, bis alle Pods den Status "Running" erreicht haben. Bestätigen Sie, dass der CDC-Pod in Betrieb ist:

kubectl get pods -n milvus
# Look for source-cluster-milvus-cdc-xxx in Running state
# NAME                                                READY   STATUS    RESTARTS   AGE
# source-cluster-milvus-cdc-66d64747bd-sckxj          1/1     Running   0          2m42s
# source-cluster-milvus-datanode-85f9f56fd-qgbzq       1/1     Running   0          2m42s
# ...

Schritt 3: Bereitstellen des Standby-Clusters

Der Standby-Cluster (Zielcluster) verwendet dieselbe Milvus-Version, enthält aber keine CDC-Komponente - er empfängt nur replizierte Daten:

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: target-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
  dependencies:
    msgStreamType: woodpecker

Anwenden:

kubectl apply -f milvus_target_cluster.yaml
# milvus.milvus.io/target-cluster created

Überprüfen Sie, ob alle Pods laufen:

kubectl get pods -n milvus
# NAME                                                   READY   STATUS    RESTARTS   AGE
# ...
# target-cluster-milvus-datanode-7ffc8cdb6b-xhzcd        1/1     Running   0          104m
# target-cluster-milvus-mixcoord-8649b87c98-btk7m        1/1     Running   0          104m
# ...

Schritt 4: Konfigurieren Sie die Replikationsbeziehung

Wenn beide Cluster laufen, konfigurieren Sie die Replikationstopologie mit Python und pymilvus.

Definieren Sie die Verbindungsdetails des Clusters und die Namen der physischen Kanäle (pchannel):

source_cluster_addr = "http://10.98.124.90:19530" # example address — replace with your actual Milvus server address
target_cluster_addr = "http://10.109.234.172:19530"
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 = []
target_cluster_pchannels = []
for i in range(pchannel_num):
source_cluster_pchannels.append(f"{source_cluster_id}-rootcoord-dml_{i}")
target_cluster_pchannels.append(f"{target_cluster_id}-rootcoord-dml_{i}")

Erstellen Sie die Replikationskonfiguration:

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

Anwenden auf beide Cluster:

from pymilvus import MilvusClient
source_client = MilvusClient(uri=source_cluster_addr, token=source_cluster_token)
source_client.update_replicate_configuration(**config)
source_client.close()
target_client = MilvusClient(uri=target_cluster_addr, token=target_cluster_token)
target_client.update_replicate_configuration(**config)
target_client.close()

Sobald dies gelungen ist, werden inkrementelle Änderungen auf dem primären Cluster automatisch auf den Standby-Cluster repliziert.

Schritt 5: Überprüfen Sie, ob die Replikation funktioniert

Stellen Sie eine Verbindung zum primären Cluster her, erstellen Sie eine Sammlung, fügen Sie einige Vektoren ein und laden Sie sie.
Führen Sie eine Suche auf dem Primärsystem durch, um zu überprüfen, ob die Daten vorhanden sind.
Stellen Sie eine Verbindung zum Standby-System her und führen Sie die gleiche Suche durch.
Wenn der Standby-Server die gleichen Ergebnisse liefert, funktioniert die Replikation.

Der Milvus Quickstart deckt die Erstellung von Sammlungen, das Einfügen und die Suche ab, falls Sie eine Referenz benötigen.

Ausführen von CDC in der Produktion

Das Einrichten von CDC ist der einfachste Teil. Um die Zuverlässigkeit im Laufe der Zeit aufrechtzuerhalten, müssen Sie auf einige operative Bereiche achten.

Replikationsverzögerung überwachen

Der Standby-Server hinkt dem primären Server immer etwas hinterher - das liegt in der Natur der asynchronen Replikation. Bei normaler Auslastung beträgt die Verzögerung nur wenige Sekunden. Schreibspitzen, Netzwerküberlastung oder Ressourcenknappheit auf dem Standby-System können jedoch dazu führen, dass er größer wird.

Verfolgen Sie die Verzögerung als Metrik und schlagen Sie Alarm. Ein Lag, der wächst, ohne sich zu erholen, bedeutet normalerweise, dass der CDC-Knoten nicht mit dem Schreibdurchsatz mithalten kann. Überprüfen Sie zunächst die Netzwerkbandbreite zwischen den Clustern und überlegen Sie dann, ob der Standby-Knoten mehr Ressourcen benötigt.

Nutzen Sie den Standby für Read Scaling

Der Standby-Knoten ist nicht nur ein kaltes Backup, das untätig bleibt, bis der Katastrophenfall eintritt. Er nimmt Such- und Abfrageanfragen an, während die Replikation aktiv ist - nur Schreibvorgänge werden blockiert. Dies eröffnet praktische Einsatzmöglichkeiten:

Umleitung von Batch-ähnlichen Such- oder Analyse-Workloads auf den Standby-Server
Aufteilung des Leseverkehrs während der Spitzenzeiten, um den Druck auf den Primärserver zu verringern
Ausführen teurer Abfragen (große Top-K, gefilterte Suchen in großen Sammlungen) ohne Beeinträchtigung der Schreiblatenz in der Produktion

Dadurch wird Ihre DR-Infrastruktur zu einem Leistungsvorteil. Der Standby verdient seinen Unterhalt auch dann, wenn nichts kaputt ist.

Richtige Größe des Standbys

Der Standby-Server wiederholt alle Schreibvorgänge des Primärspeichers, sodass er ähnliche Rechen- und Speicherressourcen benötigt. Wenn Sie auch Lesevorgänge an sie weiterleiten, sollten Sie diese zusätzliche Last berücksichtigen. Die Speicheranforderungen sind identisch, da sie dieselben Daten enthält.

Testen Sie Failover, bevor Sie es brauchen

Warten Sie nicht auf einen echten Ausfall, um festzustellen, dass Ihr Failover-Prozess nicht funktioniert. Führen Sie regelmäßig Testläufe durch:

Stoppen Sie die Schreibvorgänge auf dem Primärserver
Warten Sie, bis der Standby-Server aufgeholt hat (Lag → 0)
Hochstufung des Standbys
Überprüfen Sie, ob die Abfragen die erwarteten Ergebnisse liefern.
Umkehrung des Prozesses

Messen Sie, wie lange jeder Schritt dauert, und dokumentieren Sie dies. Ziel ist es, die Ausfallsicherung zu einem Routineverfahren mit bekanntem Zeitplan zu machen - nicht zu einer stressigen Improvisation um 3 Uhr morgens. Teil 3 dieser Serie behandelt den Failover-Prozess im Detail.

Sie wollen CDC nicht selbst verwalten? Zilliz Cloud kümmert sich darum

Das Einrichten und Betreiben der CDC-Replikation von Milvus ist zwar sehr leistungsfähig, bringt aber auch einen gewissen Aufwand mit sich: Sie müssen zwei Cluster verwalten, den Zustand der Replikation überwachen, Failover-Runbooks verwalten und die Infrastruktur über Regionen hinweg pflegen. Für Teams, die eine produktionsgerechte HA ohne den operativen Aufwand wünschen, bietet Zilliz Cloud (managed Milvus) dies sofort nach dem Auspacken.

Global Cluster ist das Hauptmerkmal von Zilliz Cloud. Damit können Sie eine Milvus-Bereitstellung über mehrere Regionen hinweg - Nordamerika, Europa, Asien-Pazifik und mehr - als einen einzigen logischen Cluster betreiben. Unter der Haube kommt dieselbe CDC/WAL-Replikationstechnologie zum Einsatz, die in diesem Artikel beschrieben wurde, allerdings vollständig verwaltet:

Leistungsumfang	Selbstverwaltete CDC (dieser Artikel)	Zilliz Cloud Globaler Cluster
Replikation	Sie konfigurieren und überwachen	Automatisierte, asynchrone CDC-Pipeline
Ausfallsicherung	Manuelles Runbook	Automatisiert - keine Code-Änderungen, keine Aktualisierung der Verbindungszeichenfolge
Selbstheilung	Sie stellen den ausgefallenen Cluster neu bereit	Automatisch: erkennt den veralteten Zustand, setzt ihn zurück und baut ihn als neuen sekundären Cluster neu auf
Regionsübergreifend	Sie stellen beide Cluster bereit und verwalten sie	Integrierte Multi-Region mit lokalem Lesezugriff
RPO	Sekunden (abhängig von Ihrer Überwachung)	Sekunden (ungeplant) / Null (geplante Umschaltung)
RTO	Minuten (hängt von Ihrem Runbook ab)	Minuten (automatisiert)

Über Global Cluster hinaus umfasst der Business Critical-Plan zusätzliche DR-Funktionen:

Point-in-Time Recovery (PITR) - Rollback einer Sammlung zu einem beliebigen Zeitpunkt innerhalb des Aufbewahrungsfensters, nützlich für die Wiederherstellung von versehentlich gelöschten oder beschädigten Daten, die auf den Standby-Server repliziert werden.
Regionsübergreifende Sicherung - automatische, fortlaufende Sicherungsreplikation in eine Zielregion. Die Wiederherstellung auf neuen Clustern dauert nur Minuten.
99,99 % SLA für die Betriebszeit - unterstützt durch eine Multi-AZ-Bereitstellung mit mehreren Replikaten.

Wenn Sie Vektorsuche in der Produktion betreiben und DR eine Anforderung ist, lohnt es sich, Zilliz Cloud neben dem selbstverwalteten Milvus-Ansatz zu evaluieren. Kontaktieren Sie das Zilliz-Team für weitere Informationen.

Was kommt als Nächstes?

In diesem Artikel wurde die HA-Landschaft für Vektordatenbanken behandelt und der Aufbau eines Primär-/Standby-Paares von Grund auf erläutert. Als nächstes folgt:

Teil 2: Hinzufügen von CDC zu einem bestehenden Milvus-Cluster, das bereits Daten enthält, unter Verwendung von Milvus Backup zum Seeden des Standby, bevor die Replikation aktiviert wird
Teil 3: Verwalten des Failover - Promoten des Standby, Umleiten des Datenverkehrs und Wiederherstellen des ursprünglichen primären Systems

Bleiben Sie dran.

Wenn Sie Milvus in der Produktion einsetzen und über Disaster Recovery nachdenken, würden wir Ihnen gerne helfen:

Treten Sie der Milvus-Slack-Community bei, um Fragen zu stellen, Ihre HA-Architektur mit anderen zu teilen und von anderen Teams zu lernen, die Milvus in großem Maßstab betreiben.
Buchen Sie eine kostenlose 20-minütige Milvus-Sprechstunde, um Ihr DR-Setup durchzugehen - egal ob es sich um die CDC-Konfiguration, die Failover-Planung oder die Bereitstellung mehrerer Regionen handelt.
Wenn Sie die Einrichtung der Infrastruktur lieber überspringen und direkt mit der produktionsbereiten Hochverfügbarkeit beginnen möchten, bietet Zilliz Cloud (verwaltetes Milvus) eine regionsübergreifende Hochverfügbarkeit durch die Global Cluster-Funktion - ohne manuelle CDC-Einrichtung.

Ein paar Fragen, die auftauchen, wenn Teams mit der Einrichtung der Hochverfügbarkeit von Vector-Datenbanken beginnen:

F: Verlangsamt CDC den Primärcluster?

Nein. Der CDC-Knoten liest die WAL-Protokolle asynchron und unabhängig vom Lese-/Schreibpfad. Er konkurriert nicht mit Abfragen oder Einfügungen um Ressourcen auf dem primären Cluster. Sie werden keinen Leistungsunterschied feststellen, wenn CDC aktiviert ist.

F: Kann CDC Daten replizieren, die bereits vor der Aktivierung vorhanden waren?

Nein - CDC erfasst nur Änderungen ab dem Zeitpunkt, an dem es aktiviert wurde. Um vorhandene Daten in den Standby zu bringen, verwenden Sie Milvus Backup, um den Standby zuerst zu seeden und dann CDC für die laufende Replikation zu aktivieren. Teil 2 dieser Serie behandelt diesen Arbeitsablauf.

F: Brauche ich CDC noch, wenn ich bereits Multi-Replica aktiviert habe?

Sie schützen vor unterschiedlichen Ausfallmodi. Multi-Replica behält Kopien der gleichen Segmente über Knoten innerhalb eines Clusters hinweg - großartig bei Knotenausfällen, nutzlos, wenn der gesamte Cluster weg ist (schlechte Bereitstellung, AZ-Ausfall, Namespace-Löschung). CDC hält einen separaten Cluster in einer anderen Fehlerdomäne mit nahezu Echtzeitdaten. Für alles, was über eine Entwicklungsumgebung hinausgeht, brauchen Sie beides.

F: Wie lässt sich Milvus CDC mit der Replikation in anderen Vektordatenbanken vergleichen?

Die meisten Vektordatenbanken bieten heute Redundanz auf Knotenebene (gleichbedeutend mit Multireplika), aber keine Replikation auf Clusterebene. Milvus ist derzeit die einzige große Vektordatenbank mit integrierter WAL-basierter CDC-Replikation - demselben bewährten Muster, das relationale Datenbanken wie PostgreSQL und MySQL seit Jahrzehnten verwenden. Wenn eine cluster- oder regionsübergreifende Ausfallsicherung erforderlich ist, ist dies ein wichtiges Unterscheidungsmerkmal, das es zu bewerten gilt.