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à.
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 ElastiCache Serverless.
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 tuoi 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)
-
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 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.
