Informationen zu RDB-Snapshots

Diese Seite bietet einen Überblick über RDB-Snapshots für Memorystore for Redis. Auf dieser Seite wird davon ausgegangen, dass Sie mit den Open-Source-RDB-Snapshots von Redis und der Import-/Exportfunktion von Memorystore vertraut sind.

Informationen zum Aktivieren, Deaktivieren und Überwachen von RDB-Snapshots finden Sie unter RDB-Snapshots verwalten.

Memorystore for Redis wird hauptsächlich als speicherinterner Cache verwendet. Wenn Sie Memorystore als Cache verwenden, kann Ihre Anwendung entweder den Verlust von Cache-Daten tolerieren oder den Cache problemlos aus einem nichtflüchtigen Speicher neu füllen. In einigen Anwendungsfällen können Ausfallzeiten für eine Memorystore-Instanz oder ein vollständiger Verlust von Instanzdaten jedoch lange Anwendungsausfälle verursachen.

Wir empfehlen, die Standardstufe als primären Mechanismus für Hochverfügbarkeit zu verwenden. Darüber hinaus bietet das Aktivieren von RDB-Snapshots auf Instanzen der Standardstufe zusätzlichen Schutz vor Fehlern, die zu Cache-Leeren führen können. Die Standardstufe bietet eine hochverfügbare Instanz mit mehreren Replikaten und ermöglicht eine schnelle Wiederherstellung durch automatisches Failover, wenn die primäre Instanz ausfällt.

In einigen Szenarien möchten Sie möglicherweise auch dafür sorgen, dass Daten bei einem katastrophalen Ausfall von Instanzen der Standardstufe aus Snapshot-Sicherungen wiederhergestellt werden können. In diesen Szenarien können automatische Sicherungen und die Möglichkeit, Daten aus RDB-Snapshots wiederherzustellen, zusätzlichen Schutz vor Datenverlust bieten. Wenn RDB-Snapshots aktiviert sind, erfolgt bei Bedarf eine Wiederherstellung aus dem neuesten RDB-Snapshot.

RDB-Snapshots eignen sich für Anwendungsfälle, die nach der Wiederherstellung ein gewisses Maß an Datenveralterung tolerieren können. Mit RDB-Snapshots können Sie außerdem die Sicherung und Wiederherstellung von Instanzen der Basisstufe automatisieren.

RDB-Snapshots – Übersicht

Das RDB-Snapshot-Feature verhält sich folgendermaßen:

  • Speichert vollständige Snapshots zu einem bestimmten Zeitpunkt in benutzerdefinierten Intervallen im nichtflüchtigen Speicher.

  • Sie wählen die Häufigkeit und den Zeitplan für Snapshots des Ablaufs aus. Das minimale Snapshot-Intervall ist 1h und das Maximum ist 24h.

  • Instanzen der Basis-Stufe stellen Daten aus dem neuesten Snapshot jedes Mal wieder her, wenn eine Instanz aufgrund eines Fehlers neu gestartet wird, ein Skalierungsvorgang durchgeführt wird oder ein Upgrade für die OSS Redis-Version Ihrer Instanz durchgeführt wird.

  • Standardmäßig stellen Instanzen der Standardstufe Daten aus dem Replikat wieder her, nicht aus einem Snapshot. Instanzen der Standardstufe stellen jedoch Daten aus einem Snapshot wieder her, wenn kein Replikat verfügbar ist und sowohl die primäre Instanz als auch das Replikat neu gestartet werden.

  • Ihrer Instanzabrechnung werden keine zusätzlichen Kosten hinzugefügt.

Zusätzliche Funktionsweise

  • Snapshots werden zur Instanzwiederherstellung verwendet und sind nicht für manuelle Wiederherstellungen verfügbar. Es kann immer nur der letzte erfolgreiche Snapshot wiederhergestellt werden. Zusätzlich zu RDB-Snapshots können Sie Ihre Daten mit Export and Import (Exportieren und importieren) manuell sichern und wiederherstellen.

  • Auf einer Instanz der Standardstufe wird der Snapshot auf dem Replikat erstellt, um die Arbeitsspeicher- und CPU-Nutzung auf der primären Instanz zu minimieren. Snapshots werden niemals vom primären Knoten erstellt.

Einschränkungen

  • Verfügbar auf Memorystore for Redis-Instanzen mit Redis-Version 5.0 oder höher.

  • Wenn Ihre Instanz viele Schlüssel hat (etwa 200 Millionen oder mehr), können RDB-Snapshots und -Wiederherstellungen langsam sein. Bei diesem Schlüsselvolumen kann der Redis-Server selbst der Engpass sein, der Snapshots und Wiederherstellungen verlangsamt.

RDB-Snapshots planen

Beim Aktivieren von RDB-Snapshots während der Instanzerstellung müssen Sie ein Snapshot-Intervall angeben. Sie können auch eine Startzeit angeben. Zusammen definieren diese den täglichen Zeitplan der Snapshots. Sie können die Intervalle 1h, 6h, 12h und 24h festlegen. Wenn Sie beispielsweise die Startzeit auf 4:00 Uhr und das Intervall auf 1 Stunde festlegen, beginnen die Snapshots an dem Tag, an dem sie aktiviert werden, um 4:00 Uhr und werden danach jede Stunde fortgesetzt.

Wenn keine Startzeit angegeben ist, wird der erste Snapshot schnellstmöglich erstellt und das Intervall wird berücksichtigt. Mit einer nicht angegebenen Startzeit und einem Intervall von 1 Stunde kann der Snapshot beispielsweise um 6:13 Uhr starten und um 7:13 Uhr, 8:13 Uhr usw. fortgesetzt werden.

Wenn eine Startzeit angegeben ist, wird der tägliche Zeitplan konsistent eingehalten, wenn die Snapshots immer erfolgreich sind und nicht länger als das angegebene Sicherungsintervall dauern.

Das Auslösen des Snapshots basierend auf dem täglichen Zeitplan ist jedoch Best-Effort. Der Zeitplan kann aus verschiedenen Gründen vom ursprünglich festgelegten Zeitplan abweichen:

  • Wenn ein Snapshot fehlschlägt oder das angegebene Snapshot-Intervall länger dauert, beginnt der nächste Snapshot sofort nach Abschluss des aktuellen Snapshots.

    • Damit der Snapshot nicht kontinuierlich ausgeführt wird und die Instanz überlastet wird, sollten Sie ein Intervall festlegen, das lang genug ist, um den Snapshot abzuschließen.

  • Wenn bereits ein Snapshot ausgeführt wird, der dem täglichen Zeitplan entspricht, wird dieser Snapshot abgeschlossen und die nächste Snapshot-Zeit wird nur im Intervall vom Beginn des letzten erfolgreichen Snapshots berechnet.

Vorhandenes Programm wird angepasst

Unter Umständen möchten Sie das Erstellen von RDB-Snapshots für einen bestimmten Zeitraum vorübergehend pausieren. So können Sie dafür sorgen, dass die Leistung während kritischer Ereignisse nicht beeinträchtigt wird, oder Snapshots vorübergehend deaktivieren, um Leistungsprobleme zu beheben.

Wenn Sie die Erstellung von Snapshots vorübergehend für einen kurzen Zeitraum beenden möchten, können Sie die Startzeit auf ein Datum in der Zukunft festlegen. Wenn Sie die Startzeit auf ein Datum in der Zukunft festlegen, startet der nächste Snapshot erst ab diesem Datum. In diesem Fall wird der letzte Snapshot mindestens 7 Tage lang aufbewahrt und im Falle einer Wiederherstellung verwendet.

Weitere Informationen zum Anpassen von Snapshot-Zeitplänen finden Sie unter Snapshot-Zeitplan anpassen.

Wiederherstellungsverhalten

Redis-Instanzen der Basisstufe lösen jedes Mal eine Wiederherstellung aus, wenn die Instanz neu gestartet wird. Gängige Vorgänge, die Neustarts auslösen, sind das Skalieren und das Aktualisieren der Version einer Instanz. RDB-Snapshots bewahren die Instanzdaten der Basis-Stufe während dieser Vorgänge auf, die Neustarts, geplante Wartungsarbeiten und unvorhergesehene Systemausfälle verursachen.

Redis-Instanzen der Standardstufe führen ein Failover zu einem Replikat als primären Wiederherstellungsmechanismus aus, anstatt sie aus einem Snapshot zu laden. Eine Instanz der Standardstufe wird aus dem Snapshot wiederhergestellt, wenn die Wiederherstellung aus einem Replikat fehlschlägt.

Datenkonsistenz bei der Wiederherstellung

Wenn diese Option aktiviert ist, sorgen RDB-Snapshots bestmöglich dafür, dass Sicherungen im angegebenen Intervall durchgeführt werden. Dies kann jedoch nicht garantiert werden. Snapshots können aus verschiedenen Gründen fehlschlagen. In den Best Practices erfahren Sie, wie Sie Instanzen konfigurieren und überwachen, wenn RDB-Snapshots aktiviert sind.

Wenn der Snapshot nacheinander in mehreren Intervallen fehlschlägt, kann die letzte verfügbare Sicherung beliebig veraltet sein.

Der schlimmste Datenverlust bei einer Wiederherstellung aus einem Snapshot ist die Summe des angegebenen Intervalls seit Beginn des letzten fehlerfreien Snapshots und der Zeit zum Speichern des nächsten Snapshots. Verwenden Sie bei einem Wiederherstellungsvorfall den Messwert last_success_age, um den Zeitraum für den Datenverlust aufzurufen.

Wir empfehlen, Benachrichtigungen einzurichten, um Fehler bei geplanten Snapshots zu erkennen und Korrekturmaßnahmen zu ergreifen. Weitere Informationen zum Festlegen von Benachrichtigungen finden Sie unter Monitoring-Snapshots.

Erholungszeit

Die Instanz ist nicht verfügbar, während die Instanz aus einem Snapshot wiederhergestellt wird. Die Wiederherstellungsdauer hängt von der Größe des Snapshots ab. Prüfen Sie in der Google Cloud Console mit Cloud Monitoring den Messwert RDB recovery remaining time, um die vorhergesagte Wiederherstellungszeit zu verstehen.

Langsame Wiederherstellung mindern

Manchmal kann die Wiederherstellung nach einem Snapshot länger als erwartet dauern. Unter Umständen müssen Sie Maßnahmen ergreifen, damit Ihre Anwendung so schnell wie möglich wieder mit Redis verbunden wird.

In diesem Fall können Sie eine neue Redis-Instanz erstellen und den Anwendungstraffic an diese weiterleiten. Anschließend können Sie die wiederhergestellten Daten in die neue Instanz übertragen, sobald die ursprüngliche Instanz wiederhergestellt ist.

Snapshot- und Wiederherstellungsfehler

Snapshot-Fehler

Jeder fehlgeschlagene Snapshot wird an Cloud Monitoring gemeldet und sofort noch einmal versucht. Aufeinanderfolgende Snapshot-Fehler erhöhen die Menge der Daten, die im Falle einer Wiederherstellung verloren gehen, da wiederhergestellte Daten zunehmend veraltet sind. Informationen zum Erkennen und Beheben von Snapshot-Fehlern finden Sie unter Monitoring-Snapshots.

Fehler bei der Wiederherstellung

Wiederherstellungsfehler sind selten, können aber auftreten. Wenn ein Wiederherstellungsfehler auftritt, wird die Instanz ohne Daten wiederhergestellt.

Best Practices

Damit Sie beim Sichern Ihrer Instanz mit RDB-Snapshots die besten Ergebnisse erzielen, sollten Sie die unten beschriebenen Best Practices befolgen:

Speicherverwaltung

RDB-Snapshots verwenden einen Prozessabspalt und einen Copy-on-Write-Mechanismus, um einen Snapshot der Instanz zu erstellen. Abhängig vom Muster der Schreibvorgänge für die Instanz wächst der genutzte Arbeitsspeicher der Instanz, wenn Seiten kopiert werden, die von den Schreibvorgängen betroffen sind. Im schlimmsten Fall kann der Speicherbedarf doppelt so groß sein wie die Daten in der Instanz.

Damit die Instanz über genügend Arbeitsspeicher zum Abschließen des Snapshots verfügt, sollten Sie maxmemory-gb auf 80% der Instanzkapazität festlegen, sodass 20% für Overhead reserviert sind. Weitere Informationen finden Sie unter Best Practices für die Arbeitsspeicherverwaltung. Mit diesem Arbeitsspeicheraufwand können Sie Ihre Arbeitslast zusammen mit Monitoring-Snapshots so verwalten, dass Snapshots erfolgreich erstellt werden.

Veraltete Snapshots

Das Wiederherstellen einer Instanz aus einem veralteten Snapshot kann zu Leistungsproblemen für die Anwendung führen, da versucht wird, eine erhebliche Menge an veralteten Schlüsseln oder andere Änderungen an der Datenbank wie z. B. eine Schemaänderung abzugleichen.

Wenn Sie der Meinung sind, dass Ihr Snapshot zu veraltet ist oder andere wichtige Änderungen an Ihrer Instanz vorgenommen wurden, die sich mit dem Snapshot nur schwer abgleichen lassen, können Sie RDB-Snapshots deaktivieren und dann wieder aktivieren. Dadurch werden vorhandene Snapshots gelöscht, sodass Sie eine Wiederherstellung nach einem veralteten Snapshot vermeiden können.

Legen Sie für das Monitoring von veralteten Snapshots eine Benachrichtigung für die metrics des RDB-Snapshots last_status und last_success_age des RDB-Snapshots fest.

Längere Wiederherstellung nach einem Snapshot

Wir empfehlen, eine Benachrichtigung für den Messwert redis.googleapis.com/server/uptime einzurichten, damit Sie informiert werden, wenn Ihre Instanz nicht mehr verfügbar ist.

Wenn Ihre Instanz nicht verfügbar ist und die Wiederherstellung nach einem Snapshot zu lange dauert, können Sie eine neue Redis-Instanz erstellen und Traffic an diese weiterleiten. Sobald die ursprüngliche Redis-Instanz wiederhergestellt wurde, können Sie die wiederhergestellten Daten in die neue Instanz übertragen.

Auswirkungen von RDB-Snapshots auf die Leistung

Abhängig vom Arbeitslastmuster können RDB-Snapshots die Leistung der Instanz beeinträchtigen und die Latenz für Ihre Anwendungen erhöhen.

Je nach dem Ausmaß des potenziellen Datenverlusts, den Ihre Anwendung tolerieren kann, können Sie die Auswirkungen von RDB-Snapshots minimieren, indem Sie sie für Zeiten mit geringem Instanztraffic planen.

Verwenden Sie die Startzeit und das Startintervall, um die Snapshots für die erforderlichen Zeiten zu planen. Wenn Ihre Auslastung beispielsweise von 1:00 Uhr bis 4:00 Uhr sehr niedrig ist, können Sie die Startzeit auf 3:00 Uhr und das Intervall auf 24 Stunden festlegen.

Wenn Ihr System eine konstante Last hat und häufige Snapshots benötigt, sollten Sie die Auswirkungen auf die Leistung sorgfältig bewerten und die Vorteile der Verwendung von RDB-Snapshots für die Arbeitslast abwägen.

Monitoring-Snapshots

Es ist wichtig, Snapshots zu überwachen und Benachrichtigungen für fehlgeschlagene Snapshots festzulegen. Fehlgeschlagene Snapshots können auf eine überlastete Instanz hinweisen, die weiterhin Schwierigkeiten bei der Wiederherstellung aus dem Snapshot haben kann.

Eine Liste der verfügbaren Messwerte für Monitoring-Snapshots finden Sie unter RDB-Snapshot-Messwerte. Wenn Sie über einen fehlgeschlagenen Snapshot informiert werden möchten, richten Sie eine Benachrichtigung für den RDB-Snapshot-Messwert last_status ein. Sie können auch die Google Cloud Console verwenden, um nach Fehlern zu suchen.

Auswirkungen auf die Leistung überwachen

Sie können die Auswirkungen eines Snapshots auf die Memorystore-Instanz der Leistung beobachten. Dazu rufen Sie die über Cloud Monitoring verfügbaren Messwerte wie CPU- und Arbeitsspeichernutzung auf. Bei einer verringerten Leistung können Sie mit dem Messwert des RDB-Snapshots in_progress feststellen, ob ein Snapshot erstellt wurde, als Leistungsprobleme erkannt wurden.

Nächste Schritte