Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Snapshot und Wiederherstellung
ElastiCache Amazon-Caches, auf denen Valkey, Redis oder Serverless Memcached ausgeführt werdenOSS, können ihre Daten sichern, indem sie einen Snapshot erstellen. Sie können das Backup verwenden, um einen Cache wiederherzustellen oder Daten in einem neuen Cache durch Seeding zu speichern. Ein Backup besteht aus den Metadaten des Caches zusammen mit allen Daten im Cache. Alle Sicherungen werden in Amazon Simple Storage Service (Amazon S3) geschrieben, der einen dauerhaften Speicher bereitstellt. Sie können Ihre Daten jederzeit wiederherstellen, indem Sie einen neuen Valkey-, Redis- oder Serverless Memcached-Cache erstellen OSS und ihn mit Daten aus einem Backup füllen. Mit ElastiCache können Sie Backups mithilfe von AWS Management Console, () und dem AWS Command Line Interface verwalten.AWS CLI ElastiCache API
Wenn Sie vorhaben, den Cache zu löschen, und es wichtig ist, die Daten beizubehalten, können Sie eine zusätzliche Vorsichtsmaßnahme ergreifen. Erstellen Sie dazu zuerst ein manuelles Backup, überprüfen Sie, dass der Status available lautet und löschen Sie dann den Cache. Dadurch wird sichergestellt, dass die Cache-Daten weiterhin verfügbar sind, falls das Backup fehlschlagen sollte. Sie können nach den oben beschriebenen bewährten Methoden erneut versuchen, eine Sicherung anzufertigen.
Themen
- Sicherungseinschränkungen
- Auswirkungen von Backups selbst entworfener Cluster auf die Leistung
- Planen automatischer Backups
- Erstellen manueller Backups
- Erstellen einer endgültigen Sicherung
- Beschreiben von Sicherungen
- Kopieren eines Backups
- Exportieren einer Sicherung
- Wiederherstellen aus einem Backup in einen neuen Cache
- Löschen einer Sicherung
- Markieren von Sicherungen
- Tutorial: Seeding eines neuen, selbst entworfenen Clusters mit einem extern erstellten Backup
Sicherungseinschränkungen
Berücksichtigen Sie die folgenden Einschränkungen bei der Planung und Erstellung von Sicherungen:
-
Backup und Wiederherstellung werden nur für Caches unterstützt, die auf Valkey, Redis OSS oder Serverless Memcached ausgeführt werden.
-
Bei Valkey- oder Redis-Clustern OSS (Clustermodus deaktiviert) werden Sicherung und Wiederherstellung auf Knoten nicht unterstützt.
cache.t1.microAlle anderen Cache-Knotentypen werden unterstützt. -
Bei Valkey- oder Redis-Clustern OSS (Clustermodus aktiviert) werden Sicherung und Wiederherstellung für alle Knotentypen unterstützt.
-
Während eines zusammenhängenden Zeitraums von 24 Stunden können Sie nicht mehr als 24 manuelle Backups pro serverlosem Cache erstellen. Für OSS selbst entworfene Cluster von Valkey und Redis können Sie nicht mehr als 20 manuelle Backups pro Knoten im Cluster erstellen.
-
Valkey oder Redis OSS (Clustermodus aktiviert) unterstützen nur das Erstellen von Backups auf Clusterebene (für die API oderCLI, die Replikationsgruppenebene). Valkey oder Redis OSS (Clustermodus aktiviert) unterstützen nicht das Erstellen von Backups auf Shard-Ebene (für API oderCLI, auf Knotengruppenebene).
-
Während des Backup-Vorgangs können Sie keine anderen CLI OD-Operationen im API serverlosen Cache ausführen. Sie können während des API Backups CLI OR-Operationen auf einem selbst entworfenen Cluster ausführen.
-
Wenn Sie Valkey- oder OSS Redis-Caches mit Data Tiering verwenden, können Sie kein Backup nach Amazon S3 exportieren.
-
Sie können ein Backup eines Clusters mit dem R6gd-Knotentyp nur für Cluster wiederherstellen, die den R6gd-Knotentyp verwenden.
Auswirkungen von Backups selbst entworfener Cluster auf die Leistung
Backups auf Serverless-Caches sind für die Anwendung transparent, ohne dass sich dies auf die Leistung auswirkt. Bei der Erstellung von Backups für selbst entworfene Cluster kann es jedoch je nach verfügbarem reservierten Speicher zu Leistungseinbußen kommen. Backups für selbst entworfene Cluster sind mit ElastiCache (Memcached) nicht verfügbar, aber mit (Redis). ElastiCache OSS
Nachfolgend sind Richtlinien zur Verbesserung der Backup-Leistung für selbst entworfene Cluster aufgeführt.
-
reserved-memory-percentParameter festlegen — Um übermäßiges Paging zu vermeiden, empfehlen wir Ihnen, den Parameter festzulegen. reserved-memory-percent Dieser Parameter verhindert, dass Valkey und Redis OSS den gesamten verfügbaren Speicher des Knotens verbrauchen, und kann dazu beitragen, den Umfang des Paging zu reduzieren. Die Leistung lässt sich möglicherweise einfach durch Verwenden eines größeren Knotens verbessern. Weitere Hinweise zum reservierten Speicher und zu den Parametern finden Sie unter. reserved-memory-percentVerwaltung des reservierten Speichers für Valkey und Redis OSS -
Backups aus einer Read Replica erstellen — Wenn Sie Valkey oder Redis OSS in einer Knotengruppe mit mehr als einem Knoten ausführen, können Sie ein Backup vom primären Knoten oder einer der Read Replica erstellen. Aufgrund der dabei benötigten Systemressourcen empfehlen wirBGSAVE, Backups von einer der Read Replicas zu erstellen. Während das Backup aus dem Replikat erstellt wird, bleibt der primäre Knoten von BGSAVE den Ressourcenanforderungen unberührt. Der primäre Knoten kann weiterhin Anfragen verarbeiten, ohne langsamer zu werden.
Siehe dazu Erstellen einer manuellen Sicherung (Konsole) und wählen Sie im Fenster Sicherung erstellen im Feld Clustername ein Replikat anstelle des standardmäßigen Primärknotens aus.
Wenn Sie eine Replikationsgruppe löschen und ein letztes Backup anfordern, wird das Backup ElastiCache immer vom Primärknoten erstellt. Dadurch wird sichergestellt, dass Sie die neuesten Valkey- oder OSS Redis-Daten erfassen, bevor die Replikationsgruppe gelöscht wird.
