Auf dieser Seite finden Sie eine Übersicht über die Redis-Datenbankpersistenz (RDB) für Memorystore for Redis Cluster.
Die RDB-Persistenz schützt Ihre Daten, indem Snapshots in einem langlebigen Speicher gespeichert werden. Sie können die Häufigkeit dieser Snapshots auswählen, indem Sie ein Snapshot-Intervall zwischen mindestens 1 Stunde und maximal 24 Stunden auswählen.
Knoten mit Replikaten priorisieren die Datenwiederherstellung aus dem Replikat. Wenn jedoch sowohl die primäre Instanz als auch das Replikat gleichzeitig ausfallen, werden die Knoten aus dem neuesten Snapshot wiederhergestellt.
Wenn Sie Ihren Cluster hochskalieren, enthalten Snapshots die neuen Shards erst zum nächsten geplanten Snapshot-Zeitpunkt. Wenn Sie die Persistenz für einen Cluster aktivieren oder deaktivieren, muss der Cluster möglicherweise gewartet werden. Weitere Informationen zum Aktivieren und Deaktivieren der RDB-Persistenz finden Sie unter Persistenz verwalten.
Die RDB-Persistenz verursacht keine zusätzlichen Kosten. Dieses Feature ist ideal für Anwendungsfälle, in denen Sie nach der Wiederherstellung einen geringen Grad an Datenveralterung akzeptieren können. Da Memorystore for Redis Cluster Snapshots für die automatisierte Wiederherstellung verwendet, sind Snapshots nicht für manuelle Wiederherstellungen verfügbar. Außerdem wird in Memorystore for Redis Cluster nur der neueste Snapshot beibehalten.
Memorystore for Redis Cluster unterstützt auch die AOF-Persistenz. Sie müssen sich jedoch entweder für die AOF- oder die RDB-Persistenz entscheiden. Sie können nicht beide Persistenzmodi gleichzeitig aktivieren. Weitere Informationen zur Auswahl zwischen den Persistenzmodi finden Sie unter Persistenz – Übersicht.
Für die bestmögliche Verfügbarkeit empfehlen wir, zusätzlich zur Aktivierung der Persistenz einen hochverfügbaren Cluster zu verwenden. Weitere Informationen finden Sie unter Hochverfügbarkeit und Replikate.
Snapshot-Zeitplanung
Der Snapshot-Zeitplan wird durch die Startzeit und das Intervall des Snapshots bestimmt. Die Snapshot-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 eine Stunde festlegen, beginnen die Snapshots um 4:00 Uhr an dem Tag, an dem Sie die RDB-Persistenz aktivieren, und werden danach jede Stunde fortgesetzt.
Memorystore for Redis Cluster wertet Snapshot-Zeitpläne in der UTC-Zeitzone aus. Wenn in Ihrer Zeitzone die Sommerzeit gilt, werden die lokalen Startzeiten Ihrer Snapshot-Zeitplan-Jobs zu Beginn und am Ende der Sommerzeit um eine Stunde vor- oder zurückgestellt.
Snapshots pausieren
Möglicherweise möchten Sie das Erstellen von RDB-Snapshots vorübergehend pausieren. Sie können Snapshots beispielsweise pausieren, um Leistungseinbußen bei kritischen Ereignissen zu vermeiden oder Leistungsprobleme zu beheben.
Wenn Sie Snapshots pausieren, indem Sie die Startzeit auf die Zukunft festlegen, behält Memorystore for Redis Cluster den letzten Snapshot bei. Wenn ein Knoten ausfällt und keine Daten aus einem Replikat wiederherstellen kann, verwendet der Knoten diesen Snapshot, um die Daten wiederherzustellen. Wenn Sie Snapshots fortsetzen möchten, passen Sie den Snapshot-Zeitplan an den Zeitpunkt an, zu dem der nächste Snapshot erstellt werden soll. Weitere Informationen finden Sie unter RDB-Snapshot-Intervall anpassen.
Verhalten bei der Wiederherstellung
Memorystore for Redis Cluster-Knoten führen ein Failover auf Replikate als primären Wiederherstellungsmechanismus aus, anstatt Daten aus einem Snapshot zu laden. Wenn jedoch ein Knoten ausfällt und keine Daten aus einem Replikat wiederherstellen kann, stellt der Knoten die Daten aus dem Snapshot wieder her.
Datenkonsistenz bei der Wiederherstellung
Wenn Sie die RDB-Persistenz aktivieren, versucht der Cluster, Snapshots im angegebenen Intervall zu erstellen. Da ein RDB-Snapshot eine Sicherung zu einem bestimmten Zeitpunkt ist, muss Ihre Anwendung nach der Wiederherstellung der Daten durch Memorystore for Redis Cluster eine gewisse Veraltung tolerieren können.
Snapshots können aus verschiedenen Gründen fehlschlagen. Wenn ein Snapshot über mehrere Intervalle hinweg fehlschlägt, ist der letzte verfügbare Snapshot möglicherweise veraltet.
Bei der Wiederherstellung von Daten aus einem Snapshot ist die schlimmste Datenveralterung die Summe des angegebenen Intervalls seit dem Start des letzten fehlerfreien Snapshots und der Zeit, die zum Speichern des nächsten Snapshots im Speicher benötigt wird. Wenn ein Wiederherstellungsvorfall auftritt, können Sie mit dem Messwert rdb_save_ages den Zeitraum für die Datenveralterung aufrufen.
Weitere Informationen zu diesem Messwert finden Sie unter Persistenzmesswerte.
Erholungszeit
Wenn ein Knoten ausfällt und Daten aus einem Snapshot wiederhergestellt werden müssen, ist der Knoten während der Wiederherstellung nicht verfügbar. Die Wiederherstellungszeit hängt von der Größe des Snapshots ab.
Snapshot-Fehler
Memorystore for Redis Cluster wiederholt fehlgeschlagene Snapshots sofort mit einem exponentiellen Backoff von 5 bis 300 Sekunden. Wenn eine Wiederherstellung erfolgt, erhöht sich die Datenveralterung durch aufeinanderfolgende Snapshot-Fehler.
Fehler bei der Wiederherstellung
Fehler bei der Wiederherstellung sind selten, können aber vorkommen. Wenn ein Wiederherstellungsfehler auftritt, versucht der Knoten wiederholt, Daten aus dem Snapshot wiederherzustellen, bis die Wiederherstellung erfolgreich ist.
Monitoring-Snapshots
Wir empfehlen, Snapshots zu überwachen und Benachrichtigungen für fehlgeschlagene Snapshots einzurichten. Fehlgeschlagene Snapshots können auf überlastete Knoten hinweisen, die möglicherweise weiterhin Schwierigkeiten bei der Wiederherstellung von Daten haben.
Weitere Informationen zu Best Practices für die RDB-Persistenz finden Sie unter Best Practices für die Persistenz. Eine Liste der Messwerte, die für das Monitoring von Snapshots verfügbar sind, finden Sie unter Persistenzmesswerte.
Auswirkungen auf die Leistung
Sie können die Auswirkungen eines Snapshots auf die Leistung Ihres Clusters mit Cloud Monitoring überwachen, um Messwerte wie die CPU- und Speichernutzung aufzurufen.