Ausfallsicherung

Durch Failover wird ein Standby-Cluster zu einem eigenständigen primären Cluster, wenn der ursprüngliche primäre Cluster nicht mehr verfügbar ist. Es handelt sich dabei um einen Vorgang, bei dem die Verfügbarkeit im Vordergrund steht, und es können Daten verloren gehen, die vor dem Ausfall nicht repliziert wurden.

In diesem Leitfaden wird davon ausgegangen, dass die ursprüngliche Topologie erhalten bleibt:

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

Nach dem Failover wird cluster-b zu einer eigenständigen Primärlösung:

cluster-b (primary)

Wann wird Failover verwendet?

Verwenden Sie Failover nur, wenn:

• Der ursprüngliche Primärserver kann nicht auf Anfragen reagieren.
• Der Primärserver kann nicht innerhalb einer akzeptablen Zeit wiederhergestellt werden.
• Die Wiederherstellung der Schreibverfügbarkeit ist wichtiger als das Warten auf den alten Primärserver.

Wenn der Primärserver noch erreichbar ist, verwenden Sie stattdessen Switchover. Switchover vermeidet Datenverluste.

Risiko von Datenverlusten

Beim Failover wird nicht auf die ursprüngliche Primärdatei gewartet. Alle Daten, die auf die alte Primärdatei geschrieben, aber noch nicht auf die Standby-Datei repliziert wurden, können verloren gehen.

Der mögliche Datenverlust wird durch die CDC-Verzögerung zu dem Zeitpunkt bestimmt, zu dem die Primärdaten nicht mehr verfügbar waren.

Bevor Sie Failover durchführen, sollten Sie sich über den Kompromiss im Klaren sein:

Ziel	Umstellung	Failover
Wiederherstellung von Schreibzugriffen bei Nichterreichbarkeit des Primärsystems	Nein	Ja
Datenverluste vermeiden	Ja	Nicht garantiert
Erfordert, dass die alte Primärdatei antwortet	Ja	Nein

Bevor Sie beginnen

Bestätigen Sie die folgenden Punkte:

• Die ursprüngliche Primäranlage ist nicht mehr verfügbar.
• Sie haben sich entschieden, nicht auf die Wiederherstellung des Primärsystems zu warten.
• Der Anwendungsverkehr kann auf den Standby umgeleitet werden.
• Die Verkehrsautomatisierung sendet keine Schreibvorgänge zurück an den alten Primärserver, wenn dieser wiederhergestellt wird.
• Sie haben die Standby-Cluster-ID, Adresse, Token und pchannels.

Die wichtigste Sicherheitsanforderung ist die Vermeidung von Split Brain. Nach dem Failover sollte nur der beförderte Standby-Server Schreibzugriffe von Anwendungen akzeptieren.

Erstellen der Failover-Konfiguration

Erstellen Sie eine Konfiguration, die nur den Standby-Cluster und keine Replikationstopologie enthält. Stellen Sie force_promote=True ein.

# If you followed Set Up CDC Replication, cluster B is the original target cluster.
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

failover_config = {
    "clusters": [
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        }
    ],
    "cross_cluster_topology": [],
    "force_promote": True,
}

Heraufstufen des Standby-Clusters

Senden Sie die Anforderung an den Standby-Cluster.

from pymilvus import MilvusClient

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.update_replicate_configuration(**failover_config)
finally:
    client_b.close()

Wenn die Anforderung erfolgreich ist, wird cluster-b zu einem eigenständigen primären Cluster und kann Schreibzugriffe annehmen.

Anwendungsdatenverkehr umleiten

Nach der Heraufstufung:

1. Leiten Sie den Schreibverkehr auf cluster-b um.
2. Entfernen Sie cluster-a von Schreibendpunkten, Lastverteilern, DNS-Einträgen und Automatisierungen.
3. Überprüfen Sie, ob cluster-b Schreibzugriffe zulässt.
4. Halten Sie cluster-a isoliert, bis es außer Betrieb genommen oder explizit neu erstellt wird.

Beispiel einer Schreibüberprüfung:

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.insert(
        collection_name="test_collection",
        data=[{"id": 1, "vector": [0.1] * 128}],
    )
finally:
    client_b.close()

Passen Sie die Felder Sammlungsname und Schema an Ihre Bereitstellung an.

Überprüfen Sie das Ergebnis

Überprüfen Sie den promoted cluster direkt:

• Schreibvorgänge auf cluster-b sind erfolgreich.
• Lesevorgänge liefern die erwarteten Daten.
• Keine Anwendungskomponente schreibt auf cluster-a.

Umgang mit dem alten Primary

Nach dem Failover behandeln Sie cluster-a als veraltet. Senden Sie keine Anwendungsschreibvorgänge an sie, wenn sie wieder erreichbar wird. Er kann Daten enthalten, die nie auf cluster-b repliziert wurden, und cluster-b kann nach dem Failover bereits neue Schreibzugriffe enthalten.

Verbinden Sie cluster-a nicht automatisch wieder mit der alten Topologie. Die Wiederherstellung des alten primären Systems ist eine separate Aufgabe, die sorgfältig geplant werden muss.

Minimierung von Datenverlusten

Sie können das Risiko von Datenverlusten bei einem Failover nicht vollständig ausschließen, aber Sie können es verringern:

• Überwachen Sie CDC Lag kontinuierlich.
• Sorgen Sie dafür, dass die Standby-Cluster so ausgestattet sind, dass sie die primäre Schreibrate bewältigen können.
• Halten Sie die clusterübergreifende Netzwerklatenz und den Paketverlust gering.
• Machen Sie Schreibvorgänge von Anwendungen idempotent.
• Wiederholung von Schreibvorgängen, deren Erfolg nach dem Failover ungewiss ist.
• Bevorzugen Sie ein Switchover, wenn der primäre Cluster noch reagieren kann.

FAQ

Gehen beim Failover immer Daten verloren?

Nein, aber es ist möglich. Wenn alle Schreibvorgänge bereits repliziert waren, bevor der Primärserver ausfiel, gehen keine Daten verloren. Wenn eine CDC-Verzögerung bestand, können die verzögerten Daten verloren gehen.

Wie lange dauert das Failover?

In der Regel dauert es nur wenige Sekunden, je nach Zustand des Clusters und der Verfügbarkeit der Control-Plane auf dem Standby-Server.

Kann ich Failover auch auf dem primären System durchführen?

Nein. Failover ist für einen Standby-Cluster vorgesehen. Wenn der aktuelle Primärserver verfügbar ist, verwenden Sie Switchover.

Kann der alte Primärserver automatisch wieder teilnehmen?

Nein. Nach dem Failover muss die alte Primärdatei als veraltet behandelt und außer Betrieb genommen oder neu erstellt werden, bevor sie wieder an der Replikation teilnehmen kann.

Wie kann ich Split Brain vermeiden?

Stellen Sie sicher, dass nur der beförderte Cluster Schreibzugriffe erhält. Entfernen Sie den alten primären Cluster von allen Schreibpfaden, bevor er sich erholen und Datenverkehr annehmen kann.