Umschaltung

Switchover ändert die Richtung zwischen Primär und Standby ohne Datenverlust. Verwenden Sie dies, wenn der aktuelle primäre Cluster noch erreichbar ist oder wenn Sie den Datenverkehr zu Wartungszwecken umleiten müssen.

In diesem Leitfaden wird von der aktuellen Topologie ausgegangen:

cluster-a (primary)  ->  cluster-b (standby)

Nach dem Switchover sieht die Topologie folgendermaßen aus:

cluster-b (primary)  ->  cluster-a (standby)

Wann Sie Switchover verwenden sollten

Verwenden Sie Switchover, wenn:

• Sie Wartungsarbeiten am aktuellen Primärserver durchführen.
• Der Primärserver ist teilweise beeinträchtigt, kann aber noch auf Anfragen reagieren.
• Sie benötigen RPO = 0 und können keinen Datenverlust akzeptieren.

Verwenden Sie die Umschaltung nicht, wenn der primäre Server nicht mehr verfügbar ist. Verwenden Sie in diesem Fall Failover.

Bevor Sie beginnen

Überprüfen Sie Folgendes, bevor Sie beginnen:

• Beide Cluster sind erreichbar.
• Die CDC-Replikation ist in Ordnung.
• Die CDC-Verzögerung ist niedrig genug für die angestrebte Wiederherstellungszeit.
• Die Schreibvorgänge der Anwendung können während des Rollenwechsels angehalten oder erneut versucht werden.
• Sie haben die neue Topologiekonfiguration vorbereitet.

Die Umschaltung garantiert keinen Datenverlust, aber die Betriebszeit hängt davon ab, wie viele Daten noch repliziert werden müssen.

Erstellen Sie die neue Topologie

Erstellen Sie eine vollständige Ersetzungskonfiguration, bei der cluster-b die Quelle und cluster-a das Ziel wird.

# If you followed Set Up CDC Replication, cluster A is the original source cluster,
# and cluster B is the original target cluster.
cluster_a_id = source_cluster_id
cluster_a_addr = source_cluster_addr
cluster_a_client_addr = source_client_addr
cluster_a_token = source_cluster_token
cluster_a_pchannels = source_cluster_pchannels

cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels

switchover_config = {
    "clusters": [
        {
            "cluster_id": cluster_a_id,
            "connection_param": {
                "uri": cluster_a_addr,
                "token": cluster_a_token,
            },
            "pchannels": cluster_a_pchannels,
        },
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": cluster_b_id,
            "target_cluster_id": cluster_a_id,
        }
    ],
}

Anwenden der neuen Topologie

Wenden Sie die gleiche Konfiguration auf beide Cluster an. Senden Sie die Anforderung zuerst an den aktuellen primären und dann an den Standby-Cluster. Wenn Sie später zurückwechseln, kehren Sie die Reihenfolge um, da cluster-b der aktuelle Primärserver ist.

from pymilvus import MilvusClient

client_a = MilvusClient(uri=cluster_a_client_addr, token=cluster_a_token)
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_a.update_replicate_configuration(**switchover_config)
    client_b.update_replicate_configuration(**switchover_config)
finally:
    client_a.close()
    client_b.close()

Der alte Primärserver wird zum Standby-Server degradiert und lehnt neue Schreibvorgänge ab. Der alte Standby-Server wartet auf die verbleibenden replizierten Daten, stuft sich selbst zum primären Server herauf und nimmt dann Schreibvorgänge an.

Wenn die Anforderung aufgrund eines vorübergehenden Netzwerk- oder Dienstfehlers fehlschlägt, versuchen Sie es erneut mit derselben Konfiguration.

Umleitung des Anwendungsverkehrs

Nachdem cluster-b primär geworden ist:

1. Leiten Sie den Schreibverkehr auf cluster-b um.
2. Bestätigen Sie, dass Lese- und Schreibvorgänge auf cluster-b erfolgreich sind.
3. Vergewissern Sie sich, dass cluster-a keine Schreibzugriffe von Anwendungen mehr empfängt.
4. Überwachen Sie weiterhin die Replikation von cluster-b zurück zu cluster-a.

Überprüfen Sie das Ergebnis

Vergewissern Sie sich, dass cluster-b als neuer Primärserver fungiert und die Daten konsistent bleiben. Zu den üblichen Überprüfungen gehören:

• Vergleichen Sie die Zeilenzahlen für wichtige Collections.
• Abfrage bekannter Primärschlüssel aus beiden Clustern.
• Führen Sie eine repräsentative Suche auf dem neuen primären und dem alten Standby-Server durch.
• Führen Sie einen kleinen Schreibvorgang auf cluster-b aus und bestätigen Sie, dass er auf cluster-a repliziert wird.

Zurückwechseln

Um später zurückzuschalten, wenden Sie die ursprüngliche Topologie erneut an:

cluster-a -> cluster-b

Verwenden Sie denselben Umschaltvorgang. Vergewissern Sie sich vor dem Zurückschalten, dass der aktuelle Primärserver erreichbar und die Replikation in Ordnung ist.

HÄUFIG GESTELLTE FRAGEN

Gehen beim Switchover Daten verloren?

Nein. Beim Switchover wird gewartet, bis die verbleibenden Daten repliziert sind, bevor der Standby-Server zum Primärserver wird.

Muss ich die Schreibvorgänge der Anwendung stoppen?

Während des Rollenwechsels sollten Sie Schreibvorgänge unterbrechen oder die Wiederholung von Schreibvorgängen ermöglichen. Schreibvorgänge, die an den alten Primärserver gesendet werden, nachdem er degradiert wurde, werden zurückgewiesen.

Warum dauert die Umstellung länger als erwartet?

Der häufigste Grund ist die CDC-Verzögerung. Der neue Primärserver muss die verbleibenden Daten erhalten, bevor er sicher mit RPO = 0 übernehmen kann.

Kann ich eine fehlgeschlagene Umschaltanforderung wiederholen?

Ja. Wiederholen Sie den Vorgang mit derselben Zieltopologie.

Was passiert mit dem alten Primärserver?

Der alte Primärserver wird zum Standby-Server. Sie sollte keine Schreibzugriffe von Anwendungen mehr erhalten.