Milvus CDC

Milvus CDC (Change Data Capture) repliziert Datenänderungen von einem Milvus-Cluster zu einem anderen. Sie können CDC verwenden, um eine Primary-Standby-Disaster-Recovery-Topologie für Milvus aufzubauen.

In einer Primary-Standby-Topologie fungiert ein Cluster als Primary und nimmt Schreibvorgänge entgegen. Ein oder mehrere Standby-Cluster erhalten kontinuierlich Änderungen vom primären Cluster und können den Leseverkehr bedienen. Wenn der primäre Cluster nicht mehr verfügbar ist oder gewartet werden muss, können Sie den Dienstverkehr auf einen Standby-Cluster umleiten.

Architektur

Eine typische Topologie umfasst:

• Primärer Cluster: Der Quellcluster für die Replikation. Er nimmt Lese- und Schreibvorgänge entgegen.
• Standby-Cluster: Ein Zielcluster für die Replikation. Er empfängt Änderungen vom primären Cluster und ist schreibgeschützt, solange er ein Standby-Cluster ist.
• CDC-Knoten: Eine Milvus-Komponente, die WAL-Änderungen vom aktuellen Primärcluster an Standby-Cluster weiterleitet. Setzen Sie CDC auf jedem Cluster ein, der nach einem Switchover oder Failover primär werden kann.
• Replikationstopologie: Die konfigurierte Quelle-zu-Ziel-Beziehung, z. B. Cluster-a -> Cluster-b. Die folgende Abbildung zeigt die Topologie. CDC-Arbeitsablauf

Unterstützte Topologien

Die häufigste CDC-Implementierung besteht aus einem primären und einem Standby-System:

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

Milvus CDC unterstützt auch eine Single-Primary, Multi-Standby Topologie:

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

Milvus CDC unterstützt keine Multi-Primär- oder Aktiv-Aktiv-Einsätze, bei denen zwei oder mehr Cluster gleichzeitig Schreibverkehr annehmen.

Primär- und Standby-Verhalten

Rolle	Liest	Schreibvorgänge	Replikationsverhalten
Primär	Ja	Ja	Sendet Änderungen an Standby-Cluster
Standby	Ja	Nein	Empfängt replizierte Änderungen vom primären Cluster

Ein Standby-Cluster lehnt direkte Schreibanforderungen ab. Dies verhindert Split Brain und hält die Replikationstopologie konsistent.

Geplantes Switchover vs. Failover

Milvus CDC bietet zwei Möglichkeiten, den Dienstverkehr vom aktuellen Primärcluster auf einen Standby-Cluster zu verlagern.

Vorgang	Verwendung bei	Datenverlust	Erwartetes Verhalten
Umschaltung	Die aktuelle Primäranlage ist noch erreichbar, oder Sie führen geplante Wartungsarbeiten durch	RPO = 0	Wartet auf die verbleibenden replizierten Daten vor dem Rollenwechsel
Ausfallsicherung	Der aktuelle Primärserver ist nicht mehr erreichbar und kann nicht schnell wiederhergestellt werden.	Möglich	Promotet den Standby sofort, damit die Schreibvorgänge fortgesetzt werden können

Verwenden Sie Switchover, wenn der aktuelle Primärserver noch reagieren kann. Verwenden Sie Failover nur, wenn die Wiederherstellung der Verfügbarkeit wichtiger ist als das Warten auf den ursprünglichen Primärserver.

CDC-Verzögerung und warum sie wichtig ist

Die CDC-Verzögerung ist die Datenmenge, die in den primären Cluster geschrieben wurde, aber noch nicht auf den Standby-Cluster übertragen wurde.

CDC-Lag wirkt sich auf beide Wiederherstellungsoptionen aus:

• Beim Switchover bedeutet ein geringerer CDC-Lag in der Regel, dass der Vorgang schneller abgeschlossen wird.
• Beim Failover stellt die CDC-Verzögerung das Datenfenster dar, das verloren gehen kann, wenn der ursprüngliche Primärcluster nicht verfügbar ist.

Sie sollten die CDC-Verzögerung kontinuierlich überwachen und sie so gering wie möglich halten. Die Seite CDC-Replikation einrichten enthält ein PromQL-Beispiel zur Abschätzung des CDC-Lags.

Beschränkungen

Milvus CDC hat derzeit die folgenden Einschränkungen:

• Es werden nur Single-Primary-Topologien unterstützt.
• Es unterstützt keine aktiv-aktiven oder multi-primären Schreibvorgänge.
• Standby-Cluster können Leseverkehr bedienen, aber sie lehnen direkte Schreibvorgänge ab, solange sie Standby bleiben.
• Beim Failover können Daten verloren gehen, die auf den alten primären Cluster geschrieben, aber noch nicht auf den Standby-Cluster repliziert wurden.
• Die konfigurierte pchannels muss mit dem tatsächlichen Channel-Layout jedes Clusters übereinstimmen.

FAQ

Kann ein Standby-Cluster Abfragen bedienen?

Ja. Ein Standby-Cluster kann Lesezugriffe durchführen. Er kann keine Schreibvorgänge annehmen, bis er zum primären Cluster wird.

Unterstützt Milvus CDC aktiv-aktiv Schreibvorgänge?

Nein. Milvus CDC ist für eine Single-Primary-Topologie konzipiert. Das gleichzeitige Schreiben auf mehrere Cluster kann zu Split Brain und Datenabweichungen führen.

Gehen beim Umschalten Daten verloren?

Nein. Beim Switchover wird gewartet, bis die verbleibenden Daten repliziert sind, bevor der Standby-Cluster zum primären Cluster wird.

Gehen bei der Ausfallsicherung Daten verloren?

Ja, das kann passieren. Alle Daten, die auf die alte Primärdatenbank geschrieben, aber noch nicht auf die Standby-Datenbank repliziert wurden, können verloren gehen.

Wie viele Daten können beim Failover verloren gehen?

Der potenzielle Datenverlust wird durch die CDC-Verzögerung zu dem Zeitpunkt begrenzt, an dem der Primärserver nicht mehr verfügbar war.