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à.
Differenze di compatibilità e comportamento delle versioni principali
Importante
La pagina seguente è strutturata per indicare tutte le differenze di incompatibilità tra le versioni e informare l'utente di eventuali considerazioni da fare durante l'aggiornamento alle versioni più recenti. Questo elenco include tutti i problemi di incompatibilità delle versioni che potrebbero verificarsi durante l'aggiornamento.
È possibile eseguire l'aggiornamento direttamente dalla versione corrente di Redis OSS all'ultima versione Redis OSS disponibile, senza la necessità di aggiornamenti sequenziali. Ad esempio, è possibile eseguire l'aggiornamento direttamente dalla versione 3.0 di Redis OSS alla versione 7.0.
Le versioni Redis OSS sono identificate con una versione semantica che comprende i componenti MAJOR, MINOR e PATCH. Ad esempio, in Redis OSS 4.0.10, la versione principale è 4, la versione secondaria 0 e la versione patch è 10. Questi valori generalmente vengono incrementati in base alle convenzioni seguenti:
-
Le versioni MAJOR sono per modifiche incompatibili con l’API
-
Le versioni MINOR sono per nuove funzionalità aggiunte per compatibilità a ritroso
-
Le versioni PATCH sono per correzioni di bug compatibili a ritroso e modifiche non funzionali
È preferibile rimanere sempre sull'ultima versione della patch in una determinata versione MAJOR.MINOR, per sfruttare gli ultimi miglioramenti in termini di prestazioni e stabilità. A partire da Redis OSS 6.0, ElastiCache (Redis OSS) offrirà un'unica versione per ogni versione secondaria di Redis OSS, anziché offrire più versioni di patch. ElastiCache (Redis OSS) gestirà automaticamente la versione patch dei cluster di cache in esecuzione, garantendo prestazioni migliorate e maggiore sicurezza.
È preferibile, inoltre, eseguire periodicamente l'aggiornamento all'ultima versione principale, siccome la maggior parte dei miglioramenti principali non viene ripristinata alle versioni precedenti. Poiché ElastiCache estende la disponibilità a una nuova AWS regione, ElastiCache (Redis OSS) supporta le due versioni MAJOR.MINOR più recenti in quel momento per la nuova regione. Ad esempio, se viene avviata una nuova AWS regione e le ultime versioni di MAJOR.MINOR ElastiCache (Redis OSS) sono 7.0 e 6.2, ElastiCache (Redis OSS) supporterà le versioni 7.0 e 6.2 nella nuova regione. AWS Man mano che verranno rilasciate le nuove versioni MAJOR.MINOR di ElastiCache (Redis OSS), continuerà ad aggiungere il supporto per le versioni appena rilasciate (Redis OSS). ElastiCache ElastiCache Per ulteriori informazioni sulla scelta delle aree per ElastiCache, consulta Scelta delle regioni e delle zone di disponibilità.
Quando esegui un aggiornamento che include versioni principali o secondarie, prendi in considerazione il seguente elenco, che include il comportamento e le modifiche retrocompatibili rilasciate con Redis OSS nel tempo.
Comportamento di Redis OSS 7.0 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di Redis
-
SCRIPT LOAD
eSCRIPT FLUSH
non sono più propagati alle repliche. Se hai bisogno di una certa durabilità per gli script, ti consigliamo di prendere in considerazione l'utilizzo delle funzioni RedisOSS. -
I canali Pubsub sono ora bloccati per impostazione predefinita per i nuovi utenti ACL.
-
Il comando
STRALGO
è stato sostituito con il comandoLCS
. -
Il formato per
ACL GETUSER
è stato modificato in modo che tutti i campi contengano il modello di stringa di accesso standard. Se l'automazione era dovuta all'utilizzo diACL GETUSER
, occorre verificare che siano gestiti entrambi i formati. -
Le categorie ACL per
SELECT
,WAIT
,ROLE
,LASTSAVE
,READONLY
,READWRITE
eASKING
sono cambiate. -
Il comando
INFO
mostra ora le statistiche per sottocomando anziché nei comandi del container del livello superiore. -
I valori restituiti dai comandi
LPOP
,RPOP
,ZPOPMIN
eZPOPMAX
sono cambiati in determinati casi limite. Se si utilizzano questi comandi, occorre controllare le note di rilascio e valutare se hanno un impatto. -
I comandi
SORT
eSORT_RO
richiedono ora l'accesso all'intero keyspace per poter utilizzare gli argomentiGET
eBY
.
Comportamento di Redis OSS 6.2 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di Redis
-
I flag ACL dei comandi
TIME
,ECHO
,ROLE
eLASTSAVE
sono stati modificati. Ciò può causare il rifiuto di comandi precedentemente autorizzati e viceversa.Nota
Nessuno di questi comandi modifica o fornisce accesso ai dati.
-
Quando si esegue l'aggiornamento da Redis OSS 6.0, l'ordine delle coppie chiave/valore restituite da una risposta della mappa a uno script lua viene modificato. Se i tuoi script utilizzano
redis.setresp()
o restituiscono una mappa (novità in Redis OSS 6.0), considera le implicazioni che lo script potrebbe non funzionare durante gli aggiornamenti.
Comportamento di Redis OSS 6.0 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di Redis
-
Il numero massimo di database consentiti è stato ridotto da 1,2 milioni a 10.000. Il valore predefinito è 16 e sconsigliamo di utilizzare valori molto più grandi di questo poiché abbiamo riscontrato problemi di prestazioni e memoria.
-
Imposta il
AutoMinorVersionUpgrade
parametro su yes e ElastiCache (Redis OSS) gestirà l'aggiornamento della versione secondaria tramite aggiornamenti self-service. Questa operazione verrà gestita tramite canali standard di notifica dei clienti tramite una campagna di aggiornamento self-service. Per ulteriori informazioni, consulta Aggiornamenti self-service in. ElastiCache
Comportamento di Redis OSS 5.0 e modifiche incompatibili con le versioni precedenti
Per un elenco completo delle modifiche, consulta le note di rilascio di Redis OSS 5.0
-
Gli script vengono replicati dagli effetti invece di rieseguire lo script sulla replica. Ciò generalmente migliora le prestazioni, ma può aumentare la quantità di dati replicati tra primari e repliche. Esiste un'opzione per ripristinare il comportamento precedente, disponibile solo in ElastiCache (Redis OSS) 5.0.
-
Se si esegue l'aggiornamento da Redis OSS 4.0, alcuni comandi negli script LUA restituiranno gli argomenti in un ordine diverso rispetto alle versioni precedenti. In Redis OSS 4.0, Redis OSS ordina alcune risposte in modo lessografico per rendere le risposte deterministiche, questo ordinamento non viene applicato quando gli script vengono replicati mediante effetti.
-
In Redis OSS 5.0.3 e versioni successive, ElastiCache (Redis OSS) trasferirà parte del lavoro di I/O su core in background su tipi di istanze con più di 4 vCPU. Ciò potrebbe modificare le caratteristiche prestazionali di Redis OSS e modificare i valori di alcune metriche. Per ulteriori informazioni, consulta Quali parametri è opportuno monitorare? per appurare se è necessario modificare le metriche.
Comportamento di Redis OSS 4.0 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di Redis OSS 4.0
-
Il registro lento ora registra altri due argomenti, il nome e l'indirizzo del client. Questa modifica dovrebbe essere compatibile con le versioni precedenti a meno che non si faccia esplicitamente affidamento su ogni voce del registro lento contenente 3 valori.
-
Il comando
CLUSTER NODES
ora restituisce un formato lievemente diverso, non compatibile a ritroso. È preferibile che i client non utilizzino questo comando per conoscere i nodi presenti in un cluster, utilizzando inveceCLUSTER SLOTS
.
EOL precedenti
Comportamento di Redis OSS 3.2 e modifiche incompatibili con le versioni precedenti
Per un elenco completo delle modifiche, consulta le note di rilascio di Redis OSS 3.2
-
Non esistono modifiche di compatibilità da richiamare per questa versione.
Per ulteriori informazioni, consulta Pianificazione di fine vita delle versioni Redis OSS.
Comportamento di Redis OSS 2.8 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di Redis OSS 2.8
-
A partire da Redis OSS 2.8.22, Redis OSS AOF non è più supportato in (Redis OSS). ElastiCache È preferibile utilizzare MemoryDB quando i dati devono essere conservati in modo duraturo.
-
A partire da Redis OSS 2.8.22, ElastiCache (Redis OSS) non supporta più il collegamento di repliche ai file primari ospitati all'interno. ElastiCache Durante l'aggiornamento, le repliche esterne verranno scollegate e non potranno ricollegarsi. Si consiglia di utilizzare la memorizzazione nella cache lato client, resa disponibile in Redis OSS 6.0 come alternativa alle repliche esterne.
-
I comandi
TTL
ePTTL
ora restituiscono -2 se la chiave non esiste e -1 se esiste ma non ha una scadenza associata. Redis OSS 2.6 e versioni precedenti restituivano -1 per entrambe le condizioni. -
SORT
conALPHA
ora ordina in base alle impostazioni locali di confronto se non viene utilizzata alcuna opzioneSTORE
.
Per ulteriori informazioni, consulta Pianificazione di fine vita delle versioni Redis OSS.