RDB-Snapshots

Diese Seite bietet einen Überblick über RDB-Snapshots für Memorystore for Redis. Auf dieser Seite wird davon ausgegangen, dass Sie mit RDB-Snapshots in 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 Cache-Daten tolerieren oder den Cache sehr einfach aus einem persistenten Speicher neu befü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-Leerräumen führen können. Die Standardstufe bietet eine hoch verfügbare Instanz mit mehreren Replikaten und ermöglicht eine schnelle Wiederherstellung durch automatisches Failover, wenn die primäre Instanz ausfällt.

In einigen Fällen möchten Sie möglicherweise auch sicherstellen, dass Daten im Falle eines schwerwiegenden Ausfalls von Standard Tier-Instanzen 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, 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 Datenveralterung toleriert werden kann. Sie können RDB-Snapshots auch verwenden, um die Sicherung und Wiederherstellung von Instanzen der Basis-Stufe zu automatisieren.

RDB-Snapshots – Übersicht

Für die Funktion „RDB-Snapshots“ gilt Folgendes:

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

  • Sie können die Häufigkeit und den Zeitplan für Routine-Snapshots festlegen. Das Mindestintervall für Snapshots beträgt 1h und das maximale Intervall 24h.

  • Bei Instanzen der Basis-Stufe werden Daten aus dem letzten Snapshot wiederhergestellt, 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 erfolgt.

  • Standardmäßig werden Daten bei Instanzen der Standardstufe 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 der primäre Knoten als auch das Replikat neu gestartet werden.

  • Es fallen keine zusätzlichen Kosten für die Abrechnung Ihrer Instanz an.

Zusätzliches Verhalten

  • Snapshots werden für die Instanzwiederherstellung verwendet und sind nicht für manuelle Wiederherstellungen verfügbar. Es ist immer nur der letzte erfolgreiche Snapshot für die Wiederherstellung verfügbar. Zusätzlich zu RDB-Snapshots können Sie Export und Import 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-Auslastung auf dem primären Knoten zu minimieren. Snapshots werden nie vom primären Knoten aufgenommen.

Einschränkungen

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

  • Wenn Ihre Instanz viele Schlüssel (etwa 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, der Snapshots und Wiederherstellungen verlangsamt.

RDB-Snapshots planen

Wenn Sie RDB-Snapshots beim Erstellen einer Instanz aktivieren, müssen Sie ein Snapshot-Intervall angeben. Sie haben auch die Möglichkeit, eine Startzeit anzugeben. Zusammen definieren sie den täglichen Zeitplan der Snapshots. Die Intervalle, die Sie festlegen können, sind 1h, 6h, 12h und 24h. 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 gestartet und danach stündlich fortgesetzt.

Wenn keine Startzeit angegeben ist, wird der erste Snapshot so bald wie möglich aufgenommen und das Intervall wird eingehalten. Wenn Sie beispielsweise keine Startzeit und ein Intervall von 1 Stunde angeben, 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 eingehalten, sofern die Snapshots immer erfolgreich erstellt werden und nicht länger als das angegebene Sicherungsintervall dauern.

Das Auslösen des Snapshots auf Grundlage des täglichen Zeitplans erfolgt jedoch nach dem Best-Effort-Prinzip. 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.

    • Damit der Snapshot nicht kontinuierlich ausgeführt wird und die Instanz überlastet, empfiehlt es sich, ein Intervall festzulegen, das lang genug ist, damit der Snapshot abgeschlossen werden kann.

  • Wenn ein Snapshot 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 auf Grundlage des Intervalls seit dem Start des letzten erfolgreichen Snapshots berechnet.

Vorhandenes Programm 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 während wichtiger Ereignisse zu vermeiden oder Snapshots vorübergehend zu deaktivieren, um Leistungsprobleme zu beheben.

Wenn Sie vorübergehend für einen kurzen Zeitraum keine Snapshots erstellen möchten, können Sie die Startzeit 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 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 Basis-Stufe wird bei jedem Neustart der Instanz eine Wiederherstellung ausgelöst. Häufige Vorgänge, die Neustarts auslösen, sind das Skalieren und das Aktualisieren der Version Ihrer Instanz. RDB-Snapshots bewahren Daten von Instanzen der Basis-Stufe während dieser Vorgänge, die Neustarts, geplante Wartung und unvorhergesehene Systemausfälle verursachen.

Bei Redis-Instanzen der Standardstufe wird im Fehlerfall ein Failover zu einem Replikat als primärer Wiederherstellungsmechanismus durchgeführt, anstatt aus einem Snapshot geladen zu werden. 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. Best Practices zum Konfigurieren und Überwachen von Instanzen, wenn RDB-Snapshots aktiviert sind

Wenn der Snapshot in mehreren aufeinanderfolgenden Intervallen fehlschlägt, kann das letzte verfügbare Backup beliebig alt sein.

Der schlimmste Fall für Datenverlust bei der Wiederherstellung aus einem Snapshot ist die Summe aus dem angegebenen Intervall seit dem Start des letzten guten Snapshots und der Zeit, die zum Speichern des nächsten Snapshots im Speicher benötigt wird. Verwenden Sie im Falle eines Wiederherstellungsereignisses 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.

Regenerationszeit

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 geschätzte Wiederherstellungszeit können Sie mit dem Messwert RDB recovery remaining time in der Google Cloud Console über Cloud Monitoring abrufen.

Langsames Wiederherstellen 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 Anwendungs-Traffic darauf umleiten. Anschließend können Sie die wiederhergestellten Daten in die neue Instanz übertragen, sobald die ursprüngliche Instanz wiederhergestellt ist.

Snapshot-Fehler und Fehler bei der Wiederherstellung

Snapshot-Fehler

Alle fehlgeschlagenen Snapshots werden an Cloud Monitoring gemeldet und der Snapshot wird sofort noch einmal versucht. Bei aufeinanderfolgenden Snapshot-Fehlern steigt die Menge der Daten, die im Falle einer Wiederherstellung verloren gehen, da die wiederhergestellten Daten immer älter werden. Informationen zum Erkennen und Beheben von Snapshot-Fehlern finden Sie unter Snapshots überwachen.

Fehler bei der Wiederherstellung

Fehler bei der Wiederherstellung sind selten, können aber auftreten. Wenn die Wiederherstellung fehlschlägt, wird die Instanz ohne Daten wiederhergestellt.

Best Practices

Wenn Sie Ihre Instanz mit RDB-Snapshots sichern möchten, sollten Sie die folgenden Best Practices beachten:

Speicherverwaltung

Für RDB-Snapshots wird ein Prozess-Fork und ein Copy-on-Write-Mechanismus verwendet, um einen Snapshot der Instanz zu erstellen. Je nach Muster der Schreibvorgänge für 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 Arbeitsspeicher für den Snapshot hat, sollten Sie maxmemory-gb auf 80% der Instanzkapazität festlegen. So werden 20% für den Overhead reserviert. Weitere Informationen finden Sie unter Best Practices für Arbeitsspeicherverwaltung. Dieser Speicher-Overhead hilft Ihnen zusätzlich zu Monitoring-Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden.

Veraltete Snapshots

Wenn Sie Ihre Instanz aus einem alten Snapshot wiederherstellen, kann dies zu Leistungsproblemen für Ihre Anwendung führen, da sie versucht, eine erhebliche Anzahl alter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abzugleichen.

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

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

Lange Wiederherstellungszeit aus einem Snapshot

Wir empfehlen, eine Benachrichtigung für die 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 darauf umleiten. 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 viel potenziellen Datenverlust Ihre Anwendung tolerieren kann, können Sie die Auswirkungen von RDB-Snapshots auf die Leistung minimieren, indem Sie sie für Zeiträume mit geringem Instanz-Traffic planen.

Legen Sie mit der Startzeit und dem Intervall die Zeiten für die Snapshots fest. Wenn die Last beispielsweise von 1:00 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 Last hat und häufig Snapshots benötigt, 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 im Blick zu behalten und Benachrichtigungen für fehlgeschlagene Snapshots einzurichten. Fehlerhafte Snapshots können auf eine überlastete Instanz hinweisen, die möglicherweise weiterhin Schwierigkeiten hat, sich vom Snapshot zu erholen.

Eine Liste der Messwerte, die für das Monitoring von Snapshots verfügbar sind, finden Sie unter RDB-Snapshot-Messwerte. Wenn Sie eine Benachrichtigung über einen fehlgeschlagenen Snapshot erhalten möchten, richten Sie eine Benachrichtigung für die Messwert last_status für RDB-Snapshots ein. Sie können auch die Google Cloud -Konsole verwenden, um nach Fehlern zu suchen.

Auswirkungen auf die Leistung beobachten

Sie können die Auswirkungen eines Snapshots auf die Leistung Ihrer Memorystore-Instanz mithilfe der über Cloud Monitoring verfügbaren Messwerte wie CPU-Auslastung und Arbeitsspeicherauslastung überwachen. Wenn Sie eine verminderte Leistung feststellen, können Sie anhand des Messwerts für RDB-Snapshots in_progress ermitteln, ob ein Snapshot ausgeführt wurde, als Leistungsprobleme erkannt wurden.

Nächste Schritte