Diese Seite enthält einen Überblick über den manuellen Failover für Memorystore for Redis. Informationen zum Ausführen eines Failovers finden Sie unter Manueller Failover einleiten.
Was ist ein manueller Failover?
Eine Memorystore for Redis-Instanz der Standardstufe verwendet einen Replikatknoten, um den primären Knoten zu sichern. Ein normaler Failover tritt auf, wenn der primäre Knoten fehlerhaft wird und das Replikat als neuer Master festgelegt wird. Der Unterschied zwischen einem manuellen Failover und einem normalen Failover ist, dass Sie den manuellen Failover selbst einleiten. Weitere Informationen zur Replikationsfunktion von Memorystore for Redis finden Sie unter Hochverfügbarkeit.
Warum wird ein manueller Failover eingeleitet?
Durch das Einleiten eines manuellen Failovers können Sie testen, wie Ihre Anwendung auf einen Failover reagiert. Dieses Wissen kann für einen reibungslosen Failover sorgen, wenn später ein unerwarteter Failover auftritt.
Optionaler Datenschutzmodus
Dies sind die beiden verfügbaren Datenschutzmodi:
limited-data-loss-Modus (Standard).force-data-loss-Mode.
Verwenden Sie einen der folgenden Befehle, um den Datenschutzmodus festzulegen:
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss
oder
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss
Wie funktionieren Datenschutzmodi?
Durch den Modus limited-data-loss wird der Datenverlust auf ein Minimum reduziert. Vor der Einleitung des Failovers wird überprüft, ob der Unterschied bei den Daten zwischen dem primären und dem Replikat unter 30 MB liegt. Der Offset auf dem primären Knoten wird für jedes Byte an Daten erhöht, das mit den Replikaten synchronisiert werden muss. Im Modus limited-data-loss wird das Failover abgebrochen, wenn der größte Offset-Delta zwischen dem primären und jedem Replikat 30 MB oder mehr beträgt. Wenn Sie mehr Datenverlust tolerieren können und den Failover aggressiv ausführen möchten, können Sie den Datenschutzmodus auf force-data-loss festlegen.
Im Modus force-data-loss wird eine Kette von Failover-Strategien verwendet, um das Failover aggressiv auszuführen. Der Offset-Delta zwischen dem primären Knoten und den Replikaten wird vor dem Failover nicht geprüft. Es kann also sein, dass mehr als 30 MB an Datenänderungen verloren gehen.
Replikationsmetrik für ausstehende Bytes
Der Messwert Replikation ausstehende Byte gibt an, wie viele Byte das Replikat noch kopieren muss, bevor die primäre Sicherung vollständig gesichert ist. Während eines Failovers kann es zu einer Zunahme der ausstehenden Bytes kommen, da die primäre Instanz auf das Replikat repliziert wird. Wenn der Failover durch einen Hardwarefehler ausgelöst wird, kann es sein, dass die Anzahl der Bytes, die auf die Replikation warten, leer ist, da der Offsetwert erst abgerufen werden konnte, nachdem die neue Replikatinstanz nach dem Hostfehler repariert wurde.
Sie können in der Google Cloud -Konsole auf der Seite mit den Instanzendetails auf diesen Messwert zugreifen. Sie rufen die Seite mit den Instanzendetails auf, indem Sie auf die Instanzen-ID auf der Seite mit der Instanzenliste Ihres Projekts klicken.
Alternativ können Sie auch den Metrics Explorer für Ihr Projekt aufrufen und den Messwert redis.googlapis.com/replication/offset_diff suchen.
Wann wird ein manueller Failover ausgeführt?
Manuelle Failovers mit dem standardmäßigen limited-data-loss-Schutzmodus sind nur dann erfolgreich, wenn der Messwert Byte für Replikation ausstehend kleiner als 30 MB ist. Wenn Sie ein manuelles Failover mit mehr als 30 MB Byte für Replikation ausstehend ausführen möchten, verwenden Sie den Schutzmodus force-data-loss.
Wenn Sie so viele Daten wie möglich erhalten möchten, müssen Sie die Anwendung vorübergehend anhalten, um nicht in die Redis-Instanz zu schreiben. Warten Sie für die Ausführung des manuellen Failover, bis die Replikationsmetrik für ausstehende Bytes so niedrig ist, wie Sie für angemessen halten.
Mögliche Probleme, die einen manuellen Failover verhindern
Das Ausführen eines manuellen Failovers auf einer Basisstufeninstanz funktioniert nicht, da Basisstufeninstanzen keine Replikate haben, auf die die primäre Instanz ein Failover ausführen kann.
Wenn Ihre Redis-Instanz fehlerhaft ist, schlägt ein manueller Failover mit begrenztem Datenverlust fehl, da er zur Minimierung von Datenverlusten verhindert wird.
Wenn Sie ein Lua-Script ausführen, das unbegrenzt ausgeführt wird, müssen Sie
force-data-lossverwenden, um ein Failover zu initiieren. In diesem Fall kann ein Failover mit begrenztem Datenverlust nicht abgeschlossen werden.Wenn für Ihre Instanz Vorgänge ausstehen, die nicht vollständig sind, z. B. Skalieren oder Aktualisieren, wird der manuelle Failover verhindert. Der manuelle Failover ist erst möglich, wenn Ihre Instanz den Status
READYhat.
Client-Anwendungsverbindung
Wenn ein primärer Knoten das Failover-Replikat durchläuft, werden alle bestehenden Verbindungen zu Memorystore for Redis unterbrochen. Bei einer erneuten Verbindung wird Ihre Anwendung jedoch automatisch mit demselben Verbindungsstring oder derselben IP-Adresse an den neuen primären Knoten weitergeleitet.
Einen manuellen Failover überprüfen
Sie können den Erfolg eines manuellen Failovers mit derGoogle Cloud -Konsole oder gcloud überprüfen.
Google Cloud -Konsolenbestätigung
Bevor Sie ein manuelles Failover starten, rufen Sie die Memorystore for Redis-Seite mit der Instanzliste auf und klicken Sie auf den Namen Ihrer Instanz.
Sehen Sie dann auf dem Tab Konfiguration neben Primärer Standort nach, in welcher Zone sich Ihr primärer Knoten befindet. Notieren Sie sich die Zone. Überprüfen Sie diese Seite erneut, wenn Sie Ihren manuellen Failover abgeschlossen haben, und bestätigen Sie, dass der primäre Knoten die Zone gewechselt hat.
Überprüfung mit Cloud Monitoring
So rufen Sie mit dem Metrics Explorer die Messwerte für eine überwachte Ressource auf:
-
Rufen Sie in der Google Cloud Console die Seite leaderboard Metrics Explorer auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie in der Symbolleiste der Google Cloud Console Ihr Google Cloud -Projekt aus. Wählen Sie für App Hub-Konfigurationen das App Hub-Hostprojekt oder das Verwaltungsprojekt des für Apps aktivierten Ordners aus.
- Maximieren Sie im Element Messwert das Menü Messwert auswählen, geben Sie
Node rolein die Filterleiste ein und wählen Sie dann über die Untermenüs einen bestimmten Ressourcentyp und Messwert aus:- Wählen Sie im Menü Aktive Ressourcen die Option Cloud Memorystore Redis aus.
- Wählen Sie im Menü Aktive Messwertkategorien die Option Replikation aus.
- Wählen Sie im Menü Aktive Messwerte die Option Knotenrolle aus.
- Klicken Sie auf Übernehmen.
Verwenden Sie das Element Filter, um Filter hinzuzufügen, mit denen Zeitreihen aus den Abfrageergebnissen entfernt werden.
Verwenden Sie zum Kombinieren von Zeitreihen die Menüs im Element Aggregation. Wenn Sie beispielsweise die CPU-Auslastung für Ihre VMs basierend auf ihrer Zone anzeigen möchten, legen Sie das erste Menü auf Mittelwert und das zweite Menü auf Zone fest.
Alle Zeitreihen werden angezeigt, wenn das erste Menü des Elements Aggregation auf Nicht aggregiert gesetzt ist. Die Standardeinstellungen für das Element Aggregation werden durch den ausgewählten Messwerttyp bestimmt.
- Gehen Sie für Kontingente und andere Messwerte, die eine Stichprobe pro Tag melden, so vor:
- Legen Sie im Bereich Anzeige den Widget-Typ auf Gestapeltes Balkendiagramm fest.
- Legen Sie als Zeitraum mindestens eine Woche fest.
Im Cloud Monitoring-Diagramm werden die primären und Replikatknoten mit zwei Zeilen dargestellt. Wenn die Zeile eines Knotens im Diagramm den Wert Null anzeigt, handelt es sich um den Replikatknoten. Wenn die Linie eines Knotens im Diagramm den Wert 1 hat, ist dies der primäre Knoten. Das Diagramm stellt einen Failover dar, da angezeigt wird, wie die Zeilen jeweils zwischen Eins und Null bzw. zwischen Null und Eins wechseln.
gcloud-Überprüfung
Bevor Sie einen manuellen Failover einleiten, verwenden Sie den folgenden Befehl, um zu prüfen, in welcher Zone sich Ihr primärer Knoten befindet:
gcloud redis instances describe [INSTANCE_ID] --region=[REGION]
Ihr primärer Knoten befindet sich in der Zone mit der Bezeichnung currentLocationId. Notieren Sie sich die Zone.
Nachdem Sie ein manuelles Failover abgeschlossen haben, können Sie überprüfen, ob Ihr primärer Knoten zu einer neuen Zone gewechselt ist, indem Sie den Befehl gcloud redis instances describe noch einmal ausführen und überprüfen, ob die Zone currentLocationId geändert wurde.
Außerdem informiert Sie das Label locationId über die Zone, in der Sie Ihren primären Knoten ursprünglich bereitgestellt haben. Das Label alternativeLocationId gibt die Zone an, in der das System den Replikatknoten ursprünglich bereitgestellt hat. Bei jedem Failover wechseln der primäre und Replikatwechsel zwischen diesen beiden Zonen. Die mit locationId und alternativeLocationId verknüpften Zonen ändern sich jedoch nicht.