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 RDB-Snapshots von Open Source 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 In-Memory-Cache verwendet. Wenn Sie Memorystore als Cache verwenden, kann Ihre Anwendung entweder den Verlust von Cachedaten tolerieren oder den Cache ganz einfach aus einem nichtflüchtigen Speicher neu befüllen. Es gibt jedoch einige Anwendungsfälle, in denen eine Ausfallzeit für eine Memorystore-Instanz oder ein vollständiger Verlust von Instanzdaten zu langen Ausfallzeiten der Anwendung führen kann.

Wir empfehlen, die Standardstufe als primären Mechanismus für Hochverfügbarkeit zu verwenden. Außerdem bietet die Aktivierung von RDB-Snapshots auf Instanzen der Standardstufe zusätzlichen Schutz vor Fehlern, die zu Cache-Leerungen führen können. Die Standardstufe bietet eine hoch verfügbare Instanz mit mehreren Replikaten und ermöglicht eine schnelle Wiederherstellung mit automatischem Failover, falls die primäre Instanz ausfällt.

In einigen Fällen kann es auch sinnvoll sein, dafür zu sorgen, dass Daten im Falle eines schwerwiegenden Ausfalls von Instanzen der Standardstufe aus Snapshot-Sicherungen wiederhergestellt werden können. In diesen Fällen können automatisierte Sicherungen und die Möglichkeit, Daten aus RDB-Snapshots wiederherzustellen, zusätzlichen Schutz vor Datenverlust bieten. Wenn RDB-Snapshots aktiviert sind, wird bei Bedarf eine Wiederherstellung aus dem letzten RDB-Snapshot durchgeführt.

RDB-Snapshots eignen sich für Anwendungsfälle, bei denen nach der Wiederherstellung eine gewisse Datenaktualität toleriert werden kann. Sie können auch RDB-Snapshots verwenden, um die Sicherung und Wiederherstellung von Instanzen der Basis-Stufe zu automatisieren.

RDB-Snapshots – Übersicht

Die Funktion für RDB-Snapshots hat folgende Eigenschaften:

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

  • Sie legen die Häufigkeit und den Zeitplan für die geplanten Snapshots fest. Das Mindestintervall für Snapshots beträgt 1h und das maximale 24h.

  • Bei Instanzen der Basis-Stufe werden Daten aus dem letzten Snapshot wiederhergestellt, wenn eine Instanz aufgrund eines Fehlers neu gestartet, skaliert oder auf die OSS Redis-Version Ihrer Instanz aktualisiert wird.

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

  • Die Instanzabrechnung wird dadurch nicht teurer.

Zusätzliches Verhalten

  • Snapshots werden für die Instanzwiederherstellung verwendet und sind nicht für die manuelle Wiederherstellung verfügbar. Es kann immer nur der letzte erfolgreiche Snapshot wiederhergestellt werden. Zusätzlich zu RDB-Snapshots können Sie Ihre Daten auch manuell mit Exportieren und Importieren sichern und wiederherstellen.

  • Bei einer Instanz der Standardstufe wird der Snapshot auf dem Replikat erstellt, um die Speicher- und CPU-Auslastung auf dem Primärknoten zu minimieren. Snapshots werden nie 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 das Nadelöhr sein, das Snapshots und Wiederherstellungen verlangsamt.

RDB-Snapshots planen

Wenn Sie RDB-Snapshots beim Erstellen einer Instanz aktivieren, müssen Sie ein Snapshot-Intervall angeben. Sie können auch einen Startzeitpunkt angeben. Zusammen definieren sie 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, werden die Snapshots am Tag der Aktivierung um 4:00 Uhr erstellt und danach jede Stunde.

Wenn keine Startzeit angegeben ist, wird der erste Snapshot so bald wie möglich erstellt und das Intervall wird eingehalten. Bei einer nicht angegebenen Startzeit und einem Intervall von 1 Stunde kann der Snapshot beispielsweise um 6:13 Uhr beginnen und um 7:13 Uhr, 8:13 Uhr usw. fortgesetzt werden.

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

Das Auslösen des Snapshots gemäß dem täglichen Zeitplan erfolgt jedoch im Best-Effort-Verfahren. Der Zeitplan kann aus verschiedenen Gründen vom ursprünglich festgelegten Zeitplan abweichen:

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

    • Um zu verhindern, dass der Snapshot kontinuierlich ausgeführt wird und die Instanz überlastet, sollten Sie ein Intervall festlegen, das lang genug ist, damit der Snapshot abgeschlossen werden kann.

  • Wenn zu einer Zeit, die mit dem täglichen Zeitplan übereinstimmt, bereits ein Snapshot erstellt wird, wird dieser abgeschlossen und die nächste Snapshot-Zeit wird ausschließlich anhand des Intervalls vom Beginn des letzten erfolgreichen Snapshots berechnet.

Vorhandenen Zeitplan anpassen

Es kann vorkommen, dass Sie die Erstellung von RDB-Snapshots für einen bestimmten Zeitraum vorübergehend pausieren möchten. So können Sie beispielsweise dafür sorgen, dass es bei kritischen Ereignissen keine Leistungseinbußen gibt, oder Snapshots vorübergehend deaktivieren, um Leistungsprobleme zu beheben.

Wenn Sie die Erstellung von Snapshots für einen kurzen Zeitraum vorübergehend beenden möchten, können Sie den Startzeitpunkt auf ein zukünftiges Datum festlegen. Wenn Sie die Startzeit auf ein zukünftiges Datum festlegen, wird der nächste Snapshot erst an diesem Datum erstellt. In diesem Fall wird der letzte Snapshot mindestens sieben Tage lang aufbewahrt und bei einer Wiederherstellung verwendet.

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

Wiederherstellungsverhalten

Bei Redis-Instanzen der Basis-Stufe wird bei jedem Neustart der Instanz eine Wiederherstellung ausgelöst. Gängige Vorgänge, die einen Neustart auslösen, sind die Skalierung und das Upgrade der Version der Instanz. Mit RDB-Snapshots werden die Daten von Instanzen der Basis-Stufe bei diesen Vorgängen, die zu Neustarts, geplanten Wartungsarbeiten und unvorhergesehenen Systemausfällen führen, gesichert.

Bei Redis-Instanzen der Standardstufe wird als primärer Wiederherstellungsmechanismus ein Failover auf ein Replikat ausgeführt, anstatt Daten 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 RDB-Snapshots aktiviert sind, werden Sicherungen nach Möglichkeit im angegebenen Intervall ausgeführt. Dies kann jedoch nicht garantiert werden. Snapshots können aus verschiedenen Gründen fehlschlagen. Informationen zum Konfigurieren und Überwachen von Instanzen, wenn RDB-Snapshots aktiviert sind, finden Sie in den Best Practices.

Wenn der Snapshot in mehreren Intervallen hintereinander fehlschlägt, kann das letzte verfügbare Back-up beliebig veraltet sein.

Der maximale Datenverlust bei der Wiederherstellung aus einem Snapshot ist die Summe aus dem angegebenen Intervall seit Beginn des letzten fehlerfreien Snapshots und der Zeit, die zum Speichern des nächsten Snapshots im Speicher benötigt wird. Im Falle eines Wiederherstellungsfalls können Sie mit dem Messwert last_success_age den Zeitraum für den Datenverlust abrufen.

Wir empfehlen Ihnen, Benachrichtigungen einzurichten, um Fehler bei geplanten Snapshots zu erkennen und entsprechende Maßnahmen zu ergreifen. Weitere Informationen zum Festlegen von Benachrichtigungen finden Sie unter Snapshots überwachen.

Erholungszeit

Die Instanz ist nicht verfügbar, während sie von einem Snapshot wiederhergestellt wird. Die Wiederherstellungszeit hängt von der Größe des Snapshots ab. Die voraussichtliche Wiederherstellungszeit finden Sie in der Google Cloud Console unter Cloud Monitoring im Messwert RDB recovery remaining time.

Langsame Wiederherstellung vermeiden

Manchmal dauert die Wiederherstellung aus einem Snapshot länger als erwartet. Möglicherweise 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 Anwendungsverkehr darauf weiterleiten. Sobald die ursprüngliche Instanz wiederhergestellt ist, können Sie die wiederhergestellten Daten in die neue Instanz übertragen.

Snapshot- und Wiederherstellungsfehler

Snapshot-Fehler

Alle fehlgeschlagenen Snapshots werden an Cloud Monitoring gemeldet und der Vorgang wird sofort wiederholt. Bei aufeinanderfolgenden Snapshot-Fehlern steigt die Menge der verlorenen Daten bei einer Wiederherstellung, da die wiederhergestellten Daten immer älter werden. Informationen zum Erkennen und Beheben von Snapshot-Fehlern finden Sie unter Snapshots überwachen.

Wiederherstellung fehlgeschlagen

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

Best Practices

Für optimale Ergebnisse bei der Sicherung Ihrer Instanz mit RDB-Snapshots sollten Sie die unten beschriebenen Best Practices beachten:

Speicherverwaltung

Für RDB-Snapshots werden ein Prozess-Fork und der „Copy-on-Write“-Mechanismus verwendet, um einen Snapshot der Instanz zu erstellen. Je nach Schreibmuster für die Instanz steigt der verwendete Speicher der Instanz, wenn die von den Schreibvorgängen betroffenen Seiten kopiert werden. Im schlimmsten Fall kann der Speicherbedarf doppelt so groß sein wie die Größe der Daten in der Instanz.

Damit die Instanz genügend Arbeitsspeicher für den Snapshot hat, sollten Sie maxmemory-gb auf 80% der Instanzkapazität festlegen, sodass 20% für den Overhead reserviert sind. Weitere Informationen finden Sie unter Best Practices für Arbeitsspeicherverwaltung. Dieser Arbeitsspeicheraufwand hilft Ihnen zusätzlich zum Überwachen von Snapshots, Ihre Arbeitslast zu verwalten, damit Snapshots erfolgreich erstellt werden.

veraltete Snapshots

Wenn Sie Ihre Instanz aus einem veralteten Snapshot wiederherstellen, kann dies zu Leistungsproblemen bei Ihrer Anwendung führen, da eine große Anzahl veralteter Schlüssel oder andere Änderungen an Ihrer Datenbank wie eine Schemaänderung abgeglichen werden müssen.

Wenn Sie der Meinung sind, dass Ihr Snapshot zu alt ist oder Ihre Instanz andere wichtige Änderungen erfahren hat, die sich nur schwer mit dem Snapshot in Einklang bringen lassen, können Sie RDB-Snapshots deaktivieren und dann wieder aktivieren. Dadurch werden vorhandene Snapshots gelöscht, sodass Sie die Wiederherstellung aus einem veralteten Snapshot vermeiden können.

Wenn Sie veraltete Snapshots überwachen möchten, richten Sie eine Benachrichtigung für die Messwerte „RDB-Snapshot last_status“ und „RDB-Snapshot last_success_age“ ein.

Langsame Wiederherstellung aus einem Snapshot

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

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

Auswirkungen von RDB-Snapshots auf die Leistung

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

Je nachdem, wie viele potenzielle Datenverluste Ihre Anwendung tolerieren kann, können Sie die Leistungsauswirkungen von RDB-Snapshots minimieren, indem Sie sie so planen, dass sie in Zeiten mit geringem Instanz-Traffic ausgeführt werden.

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

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

Snapshots überwachen

Es ist wichtig, Snapshots zu überwachen und Benachrichtigungen für fehlgeschlagene Snapshots einzurichten. Fehlgeschlagene Snapshots können auf eine überlastete Instanz hinweisen, bei der es weiterhin Probleme bei der Wiederherstellung aus dem Snapshot geben kann.

Eine Liste der Messwerte, die zum Überwachen von Snapshots verfügbar sind, finden Sie unter RDB-Snapshot-Messwerte. Wenn Sie benachrichtigt werden möchten, wenn ein Snapshot fehlgeschlagen ist, richten Sie eine Benachrichtigung für den Messwert „RDB-Snapshot“ last_status ein. Sie können auch die Google Cloud Console verwenden, um nach Fehlern zu suchen.

Auswirkungen auf die Leistung im Blick behalten

Sie können die Leistungsauswirkung eines Snapshots auf Ihre Memorystore-Instanz im Blick behalten, indem Sie sich die Messwerte ansehen, die über Cloud Monitoring verfügbar sind, z. B. CPU-Auslastung und Arbeitsspeichernutzung. Wenn Sie eine geringere Leistung feststellen, können Sie mit dem Messwert „RDB-Snapshot“ in_progress feststellen, ob ein Snapshot erstellt wurde, als die Leistungsprobleme erkannt wurden.

Nächste Schritte