Gestione delle versioni per ElastiCache

Gestisci il modo in cui desideri aggiornare le ElastiCache cache e i cluster progettati autonomamente aggiornati per i motori Valkey, Memcached e Redis OSS.

Gestione delle versioni per ElastiCache Serverless Cache

Gestisci se e quando la cache ElastiCache Serverless viene aggiornata ed esegui gli aggiornamenti di versione secondo le tue condizioni e tempistiche.

ElastiCache Serverless applica automaticamente la versione più recente del software secondario e delle patch alla cache, senza alcun impatto o tempi di inattività sull'applicazione. Non è richiesta nessuna azione da parte tua.

Quando è disponibile una nuova versione principale, ElastiCache Serverless ti invierà una notifica nella console e un evento in. EventBridge Puoi scegliere di aggiornare la cache all'ultima versione principale utilizzando la console, la CLI o l'API e selezionando la versione più recente del motore. Analogamente agli aggiornamenti minori e alle patch, gli aggiornamenti delle versioni principali vengono eseguiti senza tempi di inattività dell'applicazione.

Gestione delle versioni per cluster progettati autonomamente ElastiCache

Quando si lavora con ElastiCache cluster progettati autonomamente, è possibile controllare quando il software che alimenta il cluster di cache viene aggiornato alle nuove versioni supportate da. ElastiCache È possibile controllare quando aggiornare la cache alle versioni principali, secondarie e patch più recenti disponibili. L'utente può eseguire l'aggiornamento a una versione del motore sul cluster o gruppo di replica modificando quest'ultimo e specificando la nuova versione da utilizzare.

È possibile controllare se e quando il software conforme al protocollo che alimenta il cluster di cache viene aggiornato alle nuove versioni supportate da. ElastiCache Questo livello di controllo ti consente di mantenere la compatibilità con versioni specifiche, testare le nuove versioni con l'applicazione prima di distribuirle in produzione e aggiornare le versioni alle tue condizioni e secondo le tue scadenze.

Poiché presentano rischi relativi alla compatibilità, gli aggiornamenti delle versioni non vengono eseguiti automaticamente, ma devono essere avviati manualmente.

Cluster Valkey e Redis OSS

Nota

• Se un cluster Valkey o Redis OSS viene replicato in una o più regioni, la versione del motore viene aggiornata per le regioni secondarie e quindi per la regione principale.

• ElastiCache per Redis OSS le versioni sono identificate con una versione semantica che comprende un componente principale e uno secondario. Ad esempio, in Redis OSS 6.2, la versione principale è 6 e la versione secondaria 2. Quando si utilizzano cluster progettati autonomamente, ElastiCache for Redis OSS espone anche il componente patch, ad esempio Redis OSS 6.2.1, e la versione della patch è 1.

  Le versioni principali riguardano modifiche incompatibili con le API e le versioni secondarie riguardano nuove funzionalità aggiunte in modo retrocompatibile. Le versioni patch riguardano correzioni di bug retrocompatibili e modifiche non funzionali.

Con Valkey e Redis OSS, è possibile avviare gli aggiornamenti della versione del motore nel cluster o nel gruppo di replica modificandolo e specificando una nuova versione del motore. Per ulteriori informazioni, consulta Modifica di un gruppo di replica.

Memcached

Con Memcached, per eseguire l'aggiornamento a una versione più recente è necessario modificare il cluster di cache e specificare la nuova versione del motore che si desidera utilizzare. L'aggiornamento a una versione più recente di Memcached è un processo distruttivo: si perdono i dati e si inizia con una cache a freddo. Per ulteriori informazioni, consulta Modifica di un cluster ElastiCache .

Quando viene eseguito l'aggiornamento da una versione precedente alla versione 1.4.33 o una successiva di Memcached, è importante tenere presente i requisiti riportati di seguito. CreateCacheCluster e ModifyCacheCluster non riescono nelle condizioni seguenti:

• Se slab_chunk_max > max_item_size.

• Se max_item_size modulo slab_chunk_max != 0.

• Se max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).

  Il valore (max_cache_memory - memcached_connections_overhead) rappresenta la memoria del nodo utilizzabile per i dati. Per ulteriori informazioni, consulta Sovraccarico delle connessioni Memcached.

Considerazioni sull'aggiornamento quando si usano cluster progettati autonomamente

Nota

Le seguenti considerazioni si applicano solo quando si aggiornano cluster progettati autonomamente. Non si applicano a Serverless. ElastiCache

Considerazioni su Valkey e Redis OSS

Quando aggiorni un cluster Valkey o Redis OSS progettato autonomamente, considera quanto segue.

• La gestione della versione del motore è progettata in modo da avere il maggior controllo possibile sulle modalità di applicazione delle patch. Tuttavia, ElastiCache si riserva il diritto di applicare una patch al cluster per conto dell'utente nell'improbabile eventualità che si verifichi una vulnerabilità critica di sicurezza nel sistema o nel software di cache.

• A partire dalla ElastiCache versione 7.2 per Valkey e dalla ElastiCache versione 6.0 per Redis OSS, ElastiCache offrirà un'unica versione per ogni versione minore, anziché offrire più versioni di patch.

• A partire dalla versione 5.0.6 del motore Redis OSS, puoi aggiornare la versione del cluster con tempi di inattività minimi. Il cluster è disponibile per la lettura durante l'intero aggiornamento ed è disponibile per la scrittura durante la maggior parte della sua durata, eccetto durante l'operazione di failover che dura alcuni secondi.

• Puoi anche aggiornare i ElastiCache cluster con versioni precedenti alla 5.0.6. Il processo utilizzato è lo stesso, ma potrebbe richiedere tempi di failover più lunghi durante la propagazione DNS (da 30 secondi a un minuto).

• A partire da Redis OSS 7, ElastiCache supporta il passaggio tra Valkey o Redis OSS (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata).

• Il processo di aggiornamento del motore Amazon ElastiCache for Redis OSS è progettato per fare il massimo sforzo per conservare i dati esistenti e richiede una replica Redis OSS di successo.

• Quando si aggiorna il motore, ElastiCache interromperà le connessioni client esistenti. Per ridurre al minimo i tempi di inattività durante gli aggiornamenti del motore, consigliamo di implementare le migliori pratiche per i client Redis OSS con tentativi di errore e backoff esponenziale, nonché le migliori pratiche per ridurre al minimo i tempi di inattività durante la manutenzione.

• Non è possibile eseguire l'aggiornamento direttamente da Valkey o Redis OSS (modalità cluster disabilitata) a Valkey o Redis OSS (modalità cluster abilitata) quando si aggiorna il motore. La procedura seguente mostra come eseguire l'aggiornamento da Valkey o Redis OSS (modalità cluster disabilitata) a Valkey o Redis OSS (modalità cluster abilitata).

  Per eseguire l'aggiornamento da una versione del motore Valkey o Redis OSS (modalità cluster disabilitata) a una versione del motore Valkey o Redis OSS (modalità cluster abilitata)

  1. Effettua un backup del cluster o del gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta Esecuzione di backup manuali.

  2. Usa il backup per creare e seminare un cluster Valkey o Redis OSS (modalità cluster abilitata) con uno shard (gruppo di nodi). Specificare la nuova versione del motore e abilitare la modalità cluster durante la creazione del cluster o gruppo di replica. Per ulteriori informazioni, consulta Tutorial: seminare un nuovo cluster progettato autonomamente con un backup creato esternamente.

  3. Elimina il vecchio cluster o gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta Eliminazione di un cluster in ElastiCache o Eliminazione di un gruppo di replica.

  4. Ridimensiona il nuovo cluster o gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) in base al numero di shard (gruppi di nodi) di cui hai bisogno. Per ulteriori informazioni, consulta Scalabilità dei cluster in Valkey o Redis OSS (modalità cluster abilitata)

• Quando si aggiornano le versioni principali del motore, ad esempio da 5.0.6 a 6.0, è necessario scegliere anche un nuovo gruppo di parametri compatibile con la nuova versione del motore.

• Per i cluster Redis OSS singoli e i cluster con Multi-AZ disattivato, si consiglia di rendere disponibile una quantità di memoria sufficiente per Redis OSS come descritto in. Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS In condizioni simili, il nodo primario non sarà a disposizione delle richieste di servizi durante la procedura di aggiornamento.

• Per i cluster Redis OSS con Multi-AZ abilitato, consigliamo inoltre di pianificare gli aggiornamenti del motore durante i periodi di basso traffico di scrittura in entrata. Durante l'aggiornamento a Redis OSS 5.0.6 o versioni successive, il cluster primario continua a essere disponibile per le richieste di assistenza durante il processo di aggiornamento.

  I cluster e gruppi di replica con più partizioni vengono elaborati e dotati di patch come di seguito:

  • Tutti le partizioni vengono elaborati in parallelo. Ognle partizioni ammette un'unica operazione di aggiornamento alla volta.

  • In ognle partizioni, tutte le repliche vengono elaborate prima del primario. Se una partizione annovera poche repliche, il suo nodo primario potrebbe giungere alla conclusione dell'elaborazione prima delle repliche negli altrle partizioni.

  • I nodi primari dei varle partizioni vengono elaborati in serie. Viene aggiornato un solo nodo primario alla volta.

• Se sul cluster o gruppo di replica in uso sono abilitate le crittografie, non è possibile eseguire l'aggiornamento a una versione del motore che non le supporti come ad esempio, da 3.2.6 a 3.2.10.

Considerazioni su Memcached

Quando si aggiorna un cluster Memcached progettato autonomamente, si consideri quanto segue.

• La gestione della versione del motore è progettata in modo da avere il maggior controllo possibile sulle modalità di applicazione delle patch. Tuttavia, ElastiCache si riserva il diritto di applicare una patch al cluster per conto dell'utente nell'improbabile eventualità che si verifichi una vulnerabilità critica di sicurezza nel sistema o nel software di cache.

• Poiché il motore Memcached non prevede la persistenza, l'aggiornamento a una particolare versione è sempre un processo radicale, che cancella tutti i dati della cache nel cluster.