Auf dieser Seite wird beschrieben, wie Memorystore for Redis Wartungen an Instanzen durchführt. Außerdem enthält es Informationen und Konfigurationsempfehlungen, die Ihre Clientanwendungen kennen müssen, um das Wartungsdesign ohne Ausfallzeit von Memorystore for Valkey zu nutzen. Diese Empfehlungen gelten sowohl für hochverfügbare Instanzen als auch für Instanzen ohne Replikate. Für alle Produktionsanwendungsfälle empfehlen wir jedoch dringend die Hochverfügbarkeitskonfiguration.
Memorystore for Valkey aktualisiert Instanzen regelmäßig, damit der Dienst zuverlässig, leistungsfähig, sicher und auf dem neuesten Stand ist. Diese Updates werden als Wartung bezeichnet. Die Wartung wird vollständig vom Dienst verwaltet und soll keine Ausfallzeiten verursachen.
Wartung fällt in der Regel in die folgenden Kategorien:
- Memorystore-Funktionen Für die Einführung einiger Funktionen ist ein Wartungsupdate für Memorystore erforderlich.
- Betriebssystem-Patches Wir halten kontinuierlich Ausschau nach neuen Sicherheitslücken im Betriebssystem. Bei der Erkennung patchen wir das Betriebssystem, um Sie vor neuen Risiken zu schützen.
- Datenbank-Patches Die Wartung kann ein Valkey-Update umfassen, um die Sicherheit, Leistung und Zuverlässigkeit einer Instanz zu verbessern. Das geht über das hinaus, was OSS Valkey bietet.
Clientanwendung konfigurieren
So konfigurieren Sie Ihre Clientanwendung für eine optimale Leistung und Verfügbarkeit während der Wartung:
- Verwenden und konfigurieren Sie den Drittanbieter-Client gemäß den Best Practices für Valkey-Clients, damit geplante Wartungsarbeiten keine Auswirkungen auf die Clientanwendung haben. Mit unseren empfohlenen Clientkonfigurationen können Sie Verbindungsrücksetzungen durch regelmäßige Aktualisierungen der Inline-Topologie und Hintergrundverbindungsrotationen vermeiden.
- Testen Sie Ihre Clientanwendung mit einer Reihe von Updatevorgängen (z. B. Skalierung nach oben oder unten oder Änderungen der Anzahl der Replikate), während Sie eine repräsentative Arbeitslast auf primären und Replikknoten ausführen und die Auswirkungen auf die Clients überwachen. Bei diesen Updates wird die Logik für die Aktualisierung der Inline-Topologie auf Clients, die Auswirkungen einer vollständigen Synchronisierung, die Erkennung neuer Knoten und die Möglichkeit zum Entfernen vorhandener Knoten getestet. Durch Tests lässt sich feststellen, ob der Drittanbieter-Client richtig konfiguriert ist, um negative Auswirkungen auf Ihre Anwendung zu vermeiden.
Planmäßige Wartung
Memorystore for Valkey nutzt eine schrittweise Bereitstellung und die Lebenszyklusstrategie „Erstellen vor Löschen“, um Ausfallzeiten durch die geplante Wartung von Memorystore auf Ihre Valkey-Instanzen zu vermeiden. Memorystore for Valkey ermöglicht Wartungen ohne Ausfallzeiten, indem die Anfrageweiterleitungsfunktionen des OSS Valkey-Instanzprotokolls mit den folgenden Memorystore-Mechanismen verwendet werden:
- Ein koordiniertes Failover ohne Datenverlust.
- Ein reibungsloses Entfernen von Knoten, damit Clients die Knotentopologie-Änderungen ohne Auswirkungen auf die Verfügbarkeit nachholen können.
- Die Private Service Connect-Endpunkte der Instanz, die von der Wartung nicht betroffen sind. Weitere Informationen zu diesen Endpunkten finden Sie unter Instanzendpunkte.
Das in den folgenden Abschnitten beschriebene Dienstverhalten gilt nur für geplante Wartungen. Weitere Informationen zu den Auswirkungen unvorhergesehener Ereignisse wie Hardwareausfällen finden Sie unter Clientverhalten bei einem ungeplanten Failover.
Standardwartungsfenster
Standardmäßig aktualisiert Memorystore Ihre Instanz in den folgenden Zeitfenstern entsprechend der Zeitzone Ihrer Instanz:
- Wochentagsfenster (Montag bis Freitag): 22:00 bis 6:00 Uhr
- Wochenendfenster: Freitag, 22:00 Uhr bis Montag, 6:00 Uhr
Strategie für die schrittweise Bereitstellung
Memorystore for Valkey führt Bereitstellungen mit einem zunehmenden Umfang und in einem Tempo durch, das eine frühzeitige Fehlererkennung ermöglicht, um Auswirkungen zu minimieren und die Stabilität zu gewährleisten. Die Auslieferungszeiten (die Zeit, in der das Update angewendet und überwacht wird, bevor es als erfolgreich betrachtet und fortgesetzt wird) werden in der Memorystore-Flotte von Instanzen auf Dienstebene integriert. Außerdem werden die Aushärtezeiten in Instanzen über Zonen in einer Region (mehrere Fehlerdomänen) hinweg integriert, um die Auswirkungen gegebenenfalls zu reduzieren.
Bei einer Instanz, die für Hochverfügbarkeit konfiguriert ist, aktualisiert Memorystore for Redis jeweils nur eine Fehlerdomain oder Zone, damit ein Instanz-Shard, einschließlich primärer und Replikate, während des Updates immer hochverfügbar ist. Außerdem werden bei Memorystore for Valkey immer nur wenige Knoten gleichzeitig aktualisiert. Bei Updates wird ein Lebenszyklusmechanismus vom Typ „Erstellen vor Löschen“ verwendet, um die Stabilität einer Instanz zu maximieren. Diese Strategie bietet die größten Vorteile beim Aktualisieren einer Instanz mit vielen Shards. Durch die Aktualisierung nur eines kleinen Teils des gesamten Nutzer-Schlüsselbereichs wird die Datenverfügbarkeit maximiert.
Lebenszyklusstrategie „Erstellen vor Löschen“
Eine Valkey-Instanz hat mehrere Shards. Jeder Shard hat einen primären Knoten und null oder mehrere Replikatknoten. Memorystore verwendet das folgende Verfahren, um einen vorhandenen primären oder Replikat-Valkey-Knoten in einem Shard zu aktualisieren:
- Memorystore for Valkey fügt dem Shard ein neues Replikat mit dem neuesten Softwareupdate hinzu. Memorystore erstellt einen neuen Knoten, anstatt einen vorhandenen Knoten zu aktualisieren, damit die bereitgestellte Kapazität bei einem unerwarteten Bootstrap-Fehler erhalten bleibt.
- Wenn ein Knoten innerhalb des zu aktualisierenden Shards ein primärer Knoten ist, wird er zuerst in ein Replikat umgewandelt, bevor er durch ein koordiniertes Failover entfernt wird.
- Memorystore entfernt das Replikat, das die ältere Software verwendet.
- Dieser Vorgang wird für jeden Knoten in der Instanz wiederholt.
Mit der Strategie „Erstellen vor Löschen“ wird die bereitgestellte Kapazität der Instanz beibehalten, im Gegensatz zu einer typischen schrittweisen Bereitstellung, bei der die Aktualisierung vor Ort erfolgt, was jedoch zu einer Verfügbarkeitsunterbrechung (und manchmal zu Datenverlusten) für die Clientanwendung führt. Bei Shards ohne Replikate stellt Memorystore for Redis zuerst ein neues Replikat bereit, koordiniert den Failover und ersetzt zuletzt den vorhandenen primären Knoten des Shards.
Schritt 1: Replikat hinzufügen
Der erste Schritt des Mechanismus „Erstellen vor Löschen“ besteht darin, einen Replikatknoten mit der neuesten Software hinzuzufügen und die Daten mithilfe des OSS-Valkey-Mechanismus für die vollständige Synchronisierung vom primären Knoten in den Replikatknoten zu kopieren. Dazu wird ein untergeordneter Prozess geforkt und die laufwerklose Replikation für das Bootstrapping des Replikats verwendet.
Sie können die horizontal skalierende Architektur der Instanz am besten nutzen, indem Sie eine größere Anzahl von Shards bereitstellen, um die Größe des Schlüsselbereichs innerhalb eines Knotens zu verringern. Ein kleinerer Datensatz pro Knoten trägt dazu bei, die Auswirkungen der Fork-Latenz bei einer vollständigen Synchronisierung zu reduzieren. Außerdem wird das Kopieren von Daten zwischen den Knoten beschleunigt.
Schritt 2: Koordiniertes primäres Failover ausführen
Wenn der zu aktualisierende Valkey-Knoten ein primärer Knoten ist, führt Memorystore ein koordiniertes Failover auf den neu hinzugefügten Replikatknoten aus. Anschließend entfernt Memorystore den Knoten. Während des koordinierten Failovers arbeiten der Client und die Valkey-Knoten zusammen und verwenden die folgenden Strategien, um Ausfallzeiten für die Anwendung zu vermeiden:
- Eingehende Clientanfragen werden am primären Knoten vorübergehend blockiert. So kann das vorhandene Replikat zu 100% mit dem primären Knoten synchronisiert werden.
- Das Replikat führt den Auswahlvorgang durch, um die primäre Rolle zu übernehmen.
- Der bisherige primäre Knoten, jetzt ein Replikatknoten, hebt die Blockierung der vorhandenen Anfragen auf und leitet sie mithilfe des OSS Valkey-Instanzprotokolls an den neuen primären Knoten weiter. Alle neuen Anfragen, die an den vorherigen Replikatknoten gesendet werden, werden weiterhin an den neuen primären Knoten weitergeleitet.
- Ihr Valkey-kompatibler Client aktualisiert seine In-Memory-Topologie. Er lernt die Adresse des neuen primären Endpunkts und Umleitungen sind nicht mehr erforderlich.
Koordinierte Failover dauern in der Regel nur wenige Millisekunden. Allerdings können In-Flight-Daten, die noch an die Replikate gesendet werden müssen, und die Gesamtgröße der Instanz die Failover-Latenz erhöhen. Die Instanzgröße kann sich auf die Konvergenz zwischen primären Knoten auswirken, was sich auf die Entscheidung zur Wahl des neuen primären Knotens auswirkt.
Schritt 3: Replikat entfernen
Der letzte Schritt des Mechanismus „Erstellen vor Löschen“ besteht darin, den Replikknoten in der älteren Software zu entfernen. Ein plötzliches Entfernen von Knoten hätte Auswirkungen auf Clientanwendungen, da Clients die Endpunktinformationen und die Instanztopologie im Cache speichern. Bei Memorystore for Valkey wird das Entfernen eines Valkey-Repliks so ausgeführt, dass Clientanwendungen ihre Topologie aktualisieren können, bevor ein Knoten hart heruntergefahren wird. Die Topologie ist so angepasst, dass Clients das neue Replikat kennenlernen, aber auch dasjenige vergessen, das entfernt werden soll.
Der Replikknoten, auf dem die ältere Software ausgeführt wird, wird für einen bestimmten Zeitraum beibehalten, in der Regel einige Minuten, während der er die eingehenden Leseanfragen an den primären Knoten seines Shards weiterleitet. So kann der Drittanbieter-Client die Knotentopologie aktualisieren und die neuen Replikationsendpunkte abrufen. Wenn der Client nach Ablauf der Zeitspanne versucht, einen entfernten Knoten zu erreichen, schlägt der Versuch fehl. Dadurch wird auf dem Client, der eine Verbindung herstellt, eine Aktualisierung der Knotentopologie ausgelöst, damit er über die Replikationsänderung informiert wird. Bei neuen Aktualisierungen der Knotentopologie wird der zu entfernende Replikknoten nicht angezeigt.
Wartungseinstellungen
Mit Memorystore for Valkey können Sie Wartungszeitpläne an die Anforderungen Ihrer Anwendung anpassen und Unterbrechungen minimieren. Wenn Sie einen Wartungszeitplan anpassen möchten, konfigurieren Sie ein Wartungsfenster für Ihre Instanz.
Sie legen Wartungsfenster für jede Memorystore for Valkey-Instanz fest und haben dabei die folgenden Konfigurationsoptionen:
- Wochentag: der Tag, an dem die Wartung durchgeführt wird
- Beginnstunde: die Stunde, zu der die Wartung beginnt
Das Wartungsfenster dauert eine Stunde. In einigen Fällen kann die Wartung über das von Ihnen ausgewählte Wartungsfenster hinausgehen.
Nachdem Sie ein Wartungsfenster für eine Instanz konfiguriert haben, plant Memorystore for Valkey die automatische Wartung in Zukunft gemäß den Einstellungen, die Sie für Wartungsfenster festgelegt haben.
Standardwartungsfenster
Wenn Sie kein Wartungsfenster festlegen, aktualisiert Memorystore for Redis Ihre Instanz in einem der folgenden Zeitfenster entsprechend der Zeitzone Ihrer Instanz:
- Wochentagsfenster (Montag bis Freitag): 22:00 bis 6:00 Uhr
- Wochenendfenster: Freitag, 22:00 Uhr bis Montag, 6:00 Uhr
Beispiel für die Wartung
Als Entwickler, der einen Einkaufswagendienst bei einem Einzelhändler verwaltet, sind Sie für eine Produktionsumgebung mit einer Memorystore for Redis-Instanz verantwortlich. Um eine optimale Leistung während der Wartung zu gewährleisten, sollten Sie sie so planen, dass die Instanz möglichst wenig Traffic hat. Das geschieht in der Regel sonntags um Mitternacht.
Legen Sie in diesem Fall das Wartungsfenster der Produktionsinstanz auf den folgenden Tag und die folgende Uhrzeit fest:
- Wochentag: Sonntag
- Startzeit (Stunde): 01:00 Uhr
Benachrichtigungen über anstehende Wartungen
Damit Sie über Wartungsereignisse in Ihrer Instanz informiert bleiben, können Sie mindestens eine Woche vor der geplanten Wartung E-Mail-Benachrichtigungen einrichten. Diese Benachrichtigungen haben den Betreff "Upcoming
maintenance for your Cloud Memorystore instance [your-instance-name]".
Memorystore for Valkey sendet auch eine Benachrichtigung, wenn die Wartung für Ihre Instanz beginnt. Der Betreff der E-Mail lautet "Maintenance
is undergoing for your Cloud Memorystore instance [your-instance-name]".
Nach Abschluss der Wartung von Memorystore for Redis wird eine Benachrichtigung gesendet. Der Betreff der E-Mail lautet "Completed Maintenance
for your Cloud Memorystore instance [your-instance-name]".
Wenn Memorystore for Valkey die Wartung verschiebt, erhalten Sie eine E-Mail, in der Sie über die abgesagte Wartung informiert werden. Der Betreff dieser E-Mail lautet "Canceled maintenance for your Cloud Memorystore instance [your-instance-name]".
Wenn Sie Wartungsbenachrichtigungen erhalten möchten, müssen Sie sie aktivieren. So registrierst du dich für Benachrichtigungen zu Wartungsarbeiten:
Wenn Sie Wartungsbenachrichtigungen von Memorystore for Valkey erhalten möchten, führen Sie diese Schritte mindestens eine Woche vor dem geplanten Wartungsupdate für Ihre Instanz aus. Andernfalls hat Memorystore for Valkey nicht genügend Zeit, Sie über die bevorstehende Wartung zu informieren.
Memorystore for Valkey sendet Benachrichtigungen an die E-Mail-Adresse, die mit Ihrem Google-Konto verknüpft ist. Sie können keinen benutzerdefinierten E-Mail-Alias konfigurieren, z. B. einen Team-E-Mail-Alias. Außerdem wird das Senden von Benachrichtigungen an eine andere E-Mail-Adresse nicht unterstützt.
Wenn Sie Wartungsbenachrichtigungen abonnieren, erhalten Sie Benachrichtigungen für alle Memorystore for Redis-Instanzen, für die in einem Google Cloud-Projekt Wartungsarbeiten geplant sind. Sie erhalten für jede Instanz eine separate Benachrichtigung.
Weitere Informationen zum Suchen nach geplanten Wartungen finden Sie unter Geplante Wartungen finden.
Wartung verschieben
In diesem Abschnitt finden Sie Richtlinien zum Verschieben von Wartungen. Wenn z. B. ein neuer Dienst während des aktuellen Wartungsfensters gestartet werden soll, sollten Sie das Wartungsfenster auf einige Tage nach der Einführung verschieben.
Sie können die Wartung innerhalb von 14 Tagen nach dem ursprünglich geplanten Zeitpunkt verschieben. Wählen Sie beim Neuplanen der Wartung eine der folgenden Optionen aus:
- Jetzt aktualisieren: Anstatt auf das geplante Wartungsfenster zu warten, können Sie die Updates sofort auf Ihre Instanz anwenden.
- Benutzerdefinierter Tag und Uhrzeit: Wählen Sie einen beliebigen Zeitpunkt innerhalb von zwei Wochen nach dem ursprünglich geplanten Wartungszeitpunkt aus.
Wenn Sie die Wartung verschieben, gelten die folgenden Einschränkungen:
- Wenn bis zum Beginn der aktuell geplanten Wartung weniger als eine Stunde verbleibt, können Sie die Wartung nicht verschieben.
- Nachdem Sie die Wartung verschoben haben, erhalten Sie von Memorystore for Redis eine E-Mail-Benachrichtigung, in der die Stornierung der vorherigen Wartung bestätigt wird. Außerdem erhalten Sie eine neue Wartungsbenachrichtigung mit dem aktualisierten Zeitplan.
Weitere Informationen zum Verschieben von Wartungen finden Sie unter Wartung verschieben.
FAQ
In diesem Abschnitt finden Sie häufig gestellte Fragen zur Wartung von Memorystore for Valkey.
Woher weiß ich, wann für meine Instanz eine Wartung geplant ist?
Wenn Sie wissen möchten, wann Wartungsarbeiten für Ihre Instanz geplant sind, empfehlen wir Ihnen, Benachrichtigungen zu abonnieren und ein Wartungsfenster zu konfigurieren. Sie können auch Ihre Instanz manuell prüfen, um zu sehen, ob der Parameter maintenanceSchedule in der Antwort enthalten ist.
Wann werden Sie von Memorystore for Valkey über bevorstehende Wartungen benachrichtigt?
Wenn Sie Wartungsbenachrichtigungen abonnieren und ein Wartungsfenster festlegen, werden Sie von Memorystore for Valkey mindestens eine Woche vor einem Wartungsereignis per E-Mail benachrichtigt.
Wie lange kann ich eine Wartung verschieben?
Nachdem Sie die Wartung für Ihre Instanz geplant haben, können Sie das Update entweder sofort starten oder um bis zu zwei Wochen nach dem ursprünglich geplanten Wartungsdatum und der ursprünglich geplanten Wartungszeit verschieben.
Wenn Sie die Wartung beispielsweise für den 11. Oktober um 23:15 Uhr planen, können Sie sie maximal auf den 25. Oktober um 23:15 Uhr verschieben. Wenn Sie nichts unternehmen, wird die Wartung zum geplanten Datum und zur geplanten Uhrzeit ausgeführt.
Weitere Informationen finden Sie unter Wartungen verschieben.
Welche Best Practices führen zu einem reibungslosen Wartungsupdate?
Um einen reibungslosen Ablauf des Wartungsupdates zu gewährleisten, empfehlen wir Folgendes:
- Folgen Sie der Anleitung zum Konfigurieren Ihrer Clientanwendung.
- Legen Sie das Wartungsfenster auf einen Tag und eine Uhrzeit fest, zu der Ihre Instanz nur wenig Traffic verarbeitet (z. B. sonntags um Mitternacht).
- Aktivieren Sie Wartungsbenachrichtigungen. Daher werden Sie von Memorystore for Redis mindestens sieben Tage vor dem geplanten Wartungsupdate für Ihre Instanz per E-Mail benachrichtigt.
- Wenn Sie keine Stunde mit geringer oder keiner Auswirkung auf die Anwendungsnutzung haben, verwenden Sie die Standardeinstellung des Dienstes für die schrittweisen Einführungen. Diese Standardeinstellung enthält Best Practices für Wartungsupdates. Weitere Informationen finden Sie unter Transparente Wartung.
Wann können Sie eine Wartung sofort anwenden?
Sie können ein Wartungsupdate sofort auf eine Testinstanz anwenden, um zu sehen, wie sich das Update auf Ihre Anwendung auswirkt. Sie können die Auswirkungen dieses Updates beobachten. Wenn Probleme mit dem Update auftreten, können Sie die Wartung Ihrer Produktionsinstanzen verschieben, bis Sie die Probleme behoben haben.
Wenn der aktuelle Tag und die aktuelle Uhrzeit für Ihre Instanz geeignet sind und Sie in Zukunft eine hohe Auslastung Ihrer Instanz erwarten, können Sie das Wartungsupdate sofort ausführen.
Werden Wartungsupdates immer innerhalb des Wartungsfensters abgeschlossen?
Memorystore for Valkey startet ein Wartungsupdate innerhalb des von Ihnen angegebenen Wartungsfensters. Bei Memorystore for Valkey wird das Update normalerweise innerhalb des Zeitfensters abgeschlossen, aber das ist nicht immer der Fall.
Kann ich Wartungen deaktivieren oder zuerst Wartungen für bestimmte Instanzen planen?
Sie können Wartungen nicht deaktivieren oder die Reihenfolge der Wartung für Ihre Instanzen steuern. Nachdem Sie die erste Wartungsbenachrichtigung erhalten haben, können Sie die Wartung jedoch um bis zu zwei Wochen verschieben.
Nächste Schritte
- Sehen Sie sich die Berechtigungen an, die zum Verwalten von Wartungsfenstern für Ihre Instanz erforderlich sind.