RDB-Snapshots

Auf dieser Seite finden Sie eine Übersicht über RDB-Snapshots für Memorystore for Redis. Auf dieser Seite wird davon ausgegangen, dass Sie mit Open-Source-Redis-RDB-Snapshots und der Memorystore-Import-/Exportfunktion 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 Cache-Daten tolerieren oder den Cache sehr einfach aus einem persistenten Speicher neu füllen. Es gibt jedoch einige Anwendungsfälle, in denen Ausfallzeiten einer Memorystore-Instanz oder ein vollständiger Verlust von Instanzdaten zu langen Ausfallzeiten der Anwendung führen können.

Wir empfehlen, die Standardstufe als primären Mechanismus für Hochverfügbarkeit zu verwenden. Wenn Sie außerdem RDB-Snapshots für Instanzen der Standardstufe aktivieren, erhalten Sie zusätzlichen Schutz vor Fehlern, die zu Cache-Bereinigungen führen können. Die Standardstufe bietet eine hoch verfügbare Instanz mit mehreren Replikaten und ermöglicht eine schnelle Wiederherstellung mithilfe des automatischen Failovers, wenn der primäre Knoten ausfällt.

In einigen Szenarien möchten Sie möglicherweise auch sicherstellen, dass Daten im Falle eines schwerwiegenden Ausfalls von Instanzen der Standardstufe aus Snapshot-Sicherungen wiederhergestellt werden können. In diesen Szenarien können automatisierte 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 letzten RDB-Snapshot.

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

Übersicht über RDB-Snapshots

Die Funktion für RDB-Snapshots hat das folgende Verhalten:

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

  • Sie wählen die Häufigkeit und den Zeitplan für routinemäßige Snapshots aus. Das minimale Snapshot-Intervall beträgt 1h, das maximale 24h.

  • Bei jedem Neustart einer Basis-Stufe-Instanz aufgrund eines Fehlers, bei einem Skalierungsvorgang, oder bei einem Upgrade der OSS-Redis-Version Ihrer Instanz werden Daten aus dem letzten Snapshot wiederhergestellt.

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

  • Es fallen keine zusätzlichen Kosten für die Instanzabrechnung an.

Zusätzliches Verhalten

  • Snapshots werden für die Instanzwiederherstellung verwendet und sind nicht für manuelle Wiederherstellungen verfügbar. Zu jedem Zeitpunkt ist nur der letzte erfolgreiche Snapshot für die Wiederherstellung verfügbar. Neben RDB-Snapshots können Sie auch die Funktionen „Exportieren“ und „Importieren“ verwenden, um Ihre Daten manuell zu sichern und wiederherzustellen.

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

Einschränkungen

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

  • Wenn Ihre Instanz viele Schlüssel (ca. 200 Millionen oder mehr) hat, können RDB-Snapshots und -Wiederherstellungen langsam sein. Bei diesem Schlüsselvolumen kann der Redis-Server selbst zum Engpass werden, was 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 eine Startzeit angeben. Zusammen definieren diese den täglichen Zeitplan der Snapshots. Sie können Intervalle von 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 um 4:00 Uhr an dem Tag, an dem sie aktiviert werden, und werden danach stündlich erstellt.

Wenn keine Startzeit angegeben ist, wird der erste Snapshot so bald wie möglich erstellt und das Intervall wird eingehalten. Wenn beispielsweise keine Startzeit angegeben ist und das Intervall 1 Stunde beträgt, kann der Snapshot 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 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 eine Best-Effort-Methode. 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 ein Snapshot bereits zu einem Zeitpunkt ausgeführt wird, der mit dem täglichen Zeitplan übereinstimmt, wird dieser Snapshot abgeschlossen und die nächste Snapshot-Zeit wird ausschließlich anhand des Intervalls seit dem Start 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. Dies kann erforderlich sein, um Leistungseinbußen bei kritischen Ereignissen zu vermeiden oder Snapshots vorübergehend zu deaktivieren, um Leistungsprobleme zu beheben.

Wenn Sie die Erstellung von Snapshots für einen kurzen Zeitraum vorübergehend beenden möchten, können Sie die Startzeit auf ein zukünftiges Datum festlegen. Sobald Sie die Startzeit auf ein zukünftiges Datum festgelegt haben, wird der nächste Snapshot erst an diesem Datum gestartet. 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

Bei Redis-Instanzen der Basisstufe wird immer dann eine Wiederherstellung ausgelöst, wenn die Instanz neu gestartet wird. Häufige Vorgänge, die Neustarts auslösen, sind das Skalieren und das Aktualisieren der Version Ihrer Instanz. RDB-Snapshots bewahren Instanzdaten der Basisstufe bei diesen Vorgängen, die Neustarts, geplante Wartungsarbeiten und unvorhergesehene Systemausfälle verursachen.

Bei Redis-Instanzen der Standardstufe wird als primärer Wiederherstellungsmechanismus ein Failover zu einem Replikat durchgefü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, wird versucht, Sicherungen im angegebenen Intervall zu erstellen. 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 die letzte verfügbare Sicherung beliebig veraltet sein.

Der schlimmste Fall eines Datenverlusts bei einer Wiederherstellung aus einem Snapshot ist die Summe des angegebenen Intervalls seit dem Start des letzten guten Snapshots und der Zeit, die zum Speichern des nächsten Snapshots im Speicher benötigt wird. Verwenden Sie bei einem Wiederherstellungsfall den Messwert last_success_age, um den Zeitraum für den Datenverlust zu sehen.

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

Wiederherstellungszeit

Die Instanz ist nicht verfügbar, während sie aus einem Snapshot wiederhergestellt wird. Die Wiederherstellungszeit hängt von der Größe des Snapshots ab. Die voraussichtliche Wiederherstellungszeit können Sie in der Google Cloud Console mit Cloud Monitoring anhand des RDB recovery remaining time Messwerts ermitteln.

Langsamen Wiederherstellungsprozess vermeiden

Manchmal kann die Wiederherstellung aus einem Snapshot länger als erwartet dauern. Möglicherweise müssen Sie Maßnahmen ergreifen, um die Verbindung Ihrer Anwendung zu Redis so schnell wie möglich wiederherzustellen.

In diesem Fall können Sie eine neue Redis-Instanz erstellen und den Anwendungsdatenverkehr darauf umleiten. Anschließend können Sie die wiederhergestellten Daten auf die neue Instanz übertragen, sobald die ursprüngliche Instanz wiederhergestellt ist.

Snapshot-Fehler und Wiederherstellungsfehler

Snapshot-Fehler

Jeder fehlgeschlagene Snapshot wird an Cloud Monitoring, und der Snapshot wird sofort wiederholt. Bei aufeinanderfolgenden Snapshot-Fehlern erhöht sich die Menge der Daten, die im Falle einer Wiederherstellung verloren gehen, da die wiederhergestellten Daten immer veralteter werden. Informationen zum Erkennen und Beheben von Snapshot-Fehlern finden Sie unter Snapshots überwachen.

Wiederherstellungsfehler

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

Best Practices

Um Ihre Instanz optimal mit RDB-Snapshots zu sichern, sollten Sie die folgenden Best Practices beachten:

Speicherverwaltung

Bei RDB-Snapshots wird ein Prozess-Fork und ein „Copy-on-Write“-Mechanismus verwendet, um einen Snapshot der Instanz zu erstellen. Abhängig vom Muster der Schreibvorgänge in die Instanz wächst der verwendete Speicher der Instanz, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Im schlimmsten Fall kann der Speicherbedarf doppelt so groß sein wie die Daten in der Instanz.

Damit die Instanz genügend Speicher hat, um den Snapshot zu erstellen, 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 die Speicherverwaltung. Dieser Speicher-Overhead und die Überwachung von Snapshots helfen Ihnen, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden.

Veraltete Snapshots

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

Wenn Sie der Meinung sind, dass Ihr Snapshot zu veraltet ist oder Ihre Instanz andere wichtige Änderungen erfahren hat, die schwer mit dem Snapshot abzugleichen sind, können Sie RDB-Snapshots deaktivieren und dann wieder aktivieren. Dadurch werden vorhandene Snapshots gelöscht, sodass Sie keine Wiederherstellung aus einem veralteten Snapshot durchführen müssen.

Um nach veralteten Snapshots zu suchen, legen Sie eine Benachrichtigung für die Messwerte des RDB-Snapshots last_status und des RDB-Snapshots last_success_age fest.

Lange Wiederherstellung aus einem Snapshot

Wir empfehlen, eine Benachrichtigung festzulegen für den redis.googleapis.com/server/uptime Messwert, 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 Datenverkehr darauf umleiten. Sobald die ursprüngliche Redis-Instanz wiederhergestellt ist, können Sie die wiederhergestellten Daten auf die neue Instanz übertragen.

Auswirkungen von RDB-Snapshots auf die Leistung

Abhängig von Ihrem Arbeitslastmuster können sich RDB-Snapshots auf die Leistung der Instanz auswirken und die Latenz für Ihre Anwendungen erhöhen.

Abhängig von der Menge des potenziellen Datenverlusts, den Ihre Anwendung tolerieren kann, können Sie die Auswirkungen von RDB-Snapshots auf die Leistung minimieren, indem Sie sie so planen, dass sie in Zeiten mit geringem Instanzdatenverkehr ausgeführt werden.

Verwenden Sie die Startzeit und das Intervall, um die Snapshots für die erforderlichen Zeiten zu planen. Wenn die Last beispielsweise zwischen 1:00 Uhr und 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 Last hat und häufige Snapshots erforderlich sind, sollten Sie die Auswirkungen auf die Leistung sorgfältig prüfen 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 festzulegen. Fehlgeschlagene Snapshots können auf eine überlastete Instanz hinweisen, bei der es möglicherweise weiterhin Schwierigkeiten gibt, sie aus dem Snapshot wiederherzustellen.

Eine Liste der Messwerte, die für das Monitoring von Snapshots verfügbar sind, finden Sie unter Messwerte für RDB-Snapshots. Wenn Sie über einen fehlgeschlagenen Snapshot benachrichtigt werden möchten, legen Sie eine Benachrichtigung für den Messwert last_status des RDB-Snapshots fest. Sie können auch in der Google Cloud Console nach Fehlern suchen.

Auswirkungen auf die Leistung überwachen

Sie können die Auswirkungen eines Snapshots auf die Leistung Ihrer Memorystore-Instanz überwachen, indem Sie sich die in Cloud Monitoring verfügbaren Messwerte wie CPU-Auslastung und Arbeitsspeichernutzung ansehen. Wenn Sie eine geringere Leistung feststellen, können Sie anhand des Messwerts in_progress des RDB-Snapshots ermitteln, ob ein Snapshot ausgeführt wurde, als Leistungsprobleme erkannt wurden.

Nächste Schritte