Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Snapshot e ripristino
ElastiCache Le cache Amazon che eseguono Redis possono eseguire il backup dei dati creando uno snapshot. Il backup può essere utilizzato per ripristinare una cache o inizializzare i dati in una nuova cache. Il backup è costituito dai metadati della cache, insieme a tutti i dati presenti nella cache. Tutti i backup vengono scritti su Amazon Simple Storage Service (Amazon S3), che fornisce uno storage durevole. In qualsiasi momento, puoi ripristinare i tuoi dati creando una nuova cache Redis e popolandola con i dati di un backup. Con ElastiCache, puoi gestire i backup utilizzando AWS Management Console, the AWS Command Line Interface ()AWS CLI e l'API. ElastiCache
Se pianifichi di eliminare una cache ed è importante preservare i dati, puoi prendere precauzioni aggiuntive. Per farlo, crea innanzitutto un backup manuale, verifica che lo stato sia disponibile, quindi elimina la cache. In questo modo hai la garanzia che, in caso di errore del backup, disporrai comunque dei dati della cache. Puoi provare nuovamente a creare un backup, seguendo le best practice illustrate in precedenza.
Argomenti
- Vincoli del backup
- Impatto sulle prestazioni dei backup di cluster progettati autonomamente
- Pianificazione di backup automatici
- Esecuzione di backup manuali
- Creazione di un backup finale
- Descrizione dei backup
- Copia di backup
- Esportazione di un backup
- Ripristino da un backup in una nuova cache
- Eliminazione di un backup
- Assegnazione di tag di backup
- Inizializzazione di un nuovo cluster progettato autonomamente con un backup creato esternamente
Vincoli del backup
Durante la pianificazione o la creazione di backup occorre considerare i seguenti vincoli:
-
Il backup e il ripristino sono supportati solo per le cache in esecuzione su Redis o Serverless Memcached.
-
Per i cluster , backup e ripristino non sono supportati sui nodi
cache.t1.micro. Tutti gli altri tipi di nodi di cache sono supportati. -
Per cluster Redis, backup e ripristino sono supportati per tutti i tipi di nodi.
-
Durante un periodo contiguo di 24 ore, è possibile creare non più di 24 backup manuali per cache serverless. Per i cluster progettati autonomamente da Redis, è possibile creare non più di 20 backup manuali per nodo del cluster.
-
Redis (modalità cluster abilitata) supporta solo l'esecuzione di backup a livello di cluster (per l'API o la CLI, il livello del gruppo di replica). Redis (modalità cluster abilitata) non supporta i backup a livello di shard (per l'API o la CLI, il livello del gruppo di nodi).
-
Durante il processo di backup, non puoi eseguire altre operazioni API o CLI sulla cache serverless. È possibile eseguire operazioni API o CLI su un cluster progettato autonomamente durante il backup.
-
Se si utilizzano cache con tiering dei dati, non è possibile esportare un backup in Amazon S3.
-
È possibile ripristinare un backup di un cluster utilizzando il tipo di nodo r6gd solo su cluster che utilizzano il tipo di nodo r6gd.
Impatto sulle prestazioni dei backup di cluster progettati autonomamente
I backup sulle cache serverless sono trasparenti per l'applicazione senza alcun impatto sulle prestazioni. Tuttavia, quando si creano backup per cluster progettati autonomamente, può esserci un certo impatto sulle prestazioni a seconda della memoria riservata disponibile. I cluster progettati autonomamente non sono disponibili con Memcached, ma sono disponibili con ElastiCache e Redis. ElastiCache
Di seguito sono elencate le linee guida per migliorare le prestazioni di backup dei cluster progettati autonomamente.
-
Impostare il parametro
reserved-memory-percent: Per mitigare la paginazione eccessiva, ti consigliamo di impostare il parametro reserved-memory-percent. Questo parametro impedisce a Redis di consumare tutta la memoria disponibile del nodo e consente di ridurre la quantità di paginazione. È anche possibile che si verifichino miglioramenti delle prestazioni utilizzando semplicemente un nodo più grande. Per ulteriori informazioni sui parametri reserved-memory e reserved-memory-percent, consulta Gestione della memoria prenotata. -
Creare backup da una replica di lettura : Se si esegue Redis in un gruppo di nodi con più di un nodo, puoi accettare un backup dal nodo primario o da una delle repliche di lettura. A causa delle risorse di sistema richieste durante BGSAVE, ti consigliamo di creare backup da una delle repliche di lettura. Nel corso della creazione del backup dalla replica, il nodo primario non viene alterato dai requisiti della risorsa BGSAVE. Il nodo primario può continuare a servire le richieste senza rallentamenti.
A tale scopo, consulta Creazione di un backup manuale (Console)e nel Nome del cluster nella finestra Crea backup, scegliere una replica anziché il nodo primario di default.
Se elimini un gruppo di replica e richiedi un backup finale, esegue ElastiCache sempre il backup dal nodo principale. Questo consente di acquisire i dati Redis più recenti prima che il gruppo di replica venga eliminato.
