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à.
Gestione delle versioni per ElastiCache
Gestisci il modo in cui desideri aggiornare le ElastiCache cache e i cluster progettati autonomamente e aggiornati per i motori Valkey, Redis e Memcached. 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 MINOR e quella del PATCH software alla cache, senza alcun impatto o tempi di inattività sull'applicazione. Non è richiesta nessuna azione da parte tua.
Quando è disponibile una nuova MAJOR versione, ElastiCache Serverless ti invierà una notifica nella console e un evento in. EventBridge Puoi scegliere di aggiornare la cache alla versione principale più recente modificandola utilizzando la Console o API selezionando la versione più recente del motore. CLI
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 e alle versioni più recenti disponibiliMAJOR. MINOR PATCH 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 OSS cluster Valkey o Redis viene replicato in una o più regioni, la versione del motore viene aggiornata per le regioni secondarie e quindi per la regione principale.
ElastiCache Le versioni (RedisOSS) sono identificate con una versione semantica che comprende un componente and. MAJOR MINOR Ad esempio, in Redis OSS 6.2, la versione principale è 6 e la versione secondaria 2. Quando si utilizzano cluster progettati autonomamente, ElastiCache (RedisOSS) espone anche il PATCH componente, ad esempio Redis OSS 6.2.1, e la versione della patch è 1.
MAJORle versioni riguardano modifiche API incompatibili e MINOR le versioni riguardano nuove funzionalità aggiunte in modo retrocompatibile. PATCHle versioni riguardano correzioni di bug compatibili con le versioni precedenti e modifiche non funzionali.
Con Valkey e RedisOSS, è 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 progettato autonomamente, considera quanto segue. OSS
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 da Valkey 7.2 e Redis OSS 6.0, ElastiCache offrirà un'unica versione per ogni versione minore, anziché offrire più versioni di patch.
A partire dalla versione 5.0.6 OSS del motore Redis, 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 tuoi ElastiCache cluster con versioni precedenti alla 5.0.6. Il processo in questione è lo stesso, ma può richiedere tempi di failover più lunghi durante DNS la propagazione (30 s-1 m).
-
A partire da Redis OSS 7, ElastiCache supporta il passaggio tra Valkey o Redis (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata). OSS
-
Il processo di aggiornamento del motore Amazon ElastiCache (RedisOSS) è 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 OSS i client Redis 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 (modalità cluster abilitata) quando si aggiorna il motore. OSS La procedura seguente mostra come eseguire l'aggiornamento da Valkey o Redis OSS (modalità cluster disabilitata) a Valkey o Redis (modalità cluster abilitata). OSS
Per eseguire l'aggiornamento da una versione del motore Valkey o Redis OSS (modalità cluster disabilitata) a una versione del motore Valkey o OSS Redis (modalità cluster abilitata)
-
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.
-
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.
-
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.
-
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 singoli e OSS i cluster con Multi-AZ disabilitato, consigliamo di rendere disponibile a Redis una quantità di memoria sufficiente come descritto in. OSS Assicurarsi di disporre 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 OSS i cluster Redis con Multi-AZ abilitato, consigliamo inoltre di pianificare gli aggiornamenti del motore durante i periodi di basso traffico di scrittura in entrata. Quando si esegue 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.
