Principali differenze di comportamento e compatibilità delle versioni con Redis OSS - Amazon ElastiCache
Comportamento di Redis OSS 7.0 e modifiche incompatibili con le versioni precedentiComportamento di Redis OSS 6.2 e modifiche incompatibili con le versioni precedentiComportamento di Redis OSS 6.0 e modifiche non compatibili con le versioni precedentiComportamento di Redis OSS 5.0 e modifiche non compatibili con le versioni precedentiComportamento di Redis OSS 4.0 e modifiche incompatibili con le versioni precedentiPassato EOL

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à.

Principali differenze di comportamento e compatibilità delle versioni con Redis OSS

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 Redis corrente all'ultima OSS versione Redis disponibile, senza la necessità di aggiornamenti OSS sequenziali. Ad esempio, puoi eseguire l'aggiornamento direttamente dalla versione 3.0 di Redis alla OSS versione 7.0.

OSSLe versioni Redis sono identificate con una versione semantica che comprende un MAJOR componente, e. MINOR 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:

  • MAJORle versioni riguardano modifiche incompatibili API

  • MINORle versioni riguardano nuove funzionalità aggiunte in modo retrocompatibile

  • PATCHle versioni riguardano correzioni di bug compatibili con le versioni precedenti e modifiche non funzionali

Consigliamo di rimanere sempre aggiornati all'ultima versione della patch entro un determinato periodo. MAJOR MINORversione per avere gli ultimi miglioramenti in termini di prestazioni e stabilità. A partire da Redis OSS 6.0, ElastiCache (RedisOSS) offrirà un'unica versione per ogni versione OSS minore di Redis, anziché offrire più versioni di patch. ElastiCache (RedisOSS) 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 (RedisOSS) supporta le due più recenti. MAJOR MINORversioni in quel momento per la nuova regione. Ad esempio, se viene lanciata una nuova AWS regione e la versione più recenteMAJOR. MINOR ElastiCache Le versioni (RedisOSS) sono 7.0 e 6.2, ElastiCache (RedisOSS) supporterà le versioni 7.0 e 6.2 nella nuova regione. AWS Come più recente. MAJOR MINORle versioni di ElastiCache (RedisOSS) sono state rilasciate, ElastiCache continueranno ad aggiungere il supporto per le versioni appena rilasciate ElastiCache (RedisOSS). Per ulteriori informazioni sulla scelta delle aree per cui ElastiCache, vedi 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 incompatibili con le versioni precedenti

Per un elenco completo delle modifiche, consulta le note di rilascio di Redis 7.0 OSS.

  • SCRIPT LOAD e SCRIPT 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 Redis. OSS

  • I canali Pubsub sono ora bloccati per impostazione predefinita per i nuovi utenti. ACL

  • Il comando STRALGO è stato sostituito con il comando LCS.

  • 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 di ACL GETUSER, occorre verificare che siano gestiti entrambi i formati.

  • Le ACL categorie perSELECT,,WAIT,ROLE, LASTSAVE READONLYREADWRITE, e ASKING sono state modificate.

  • 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 e ZPOPMAX 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 e SORT_RO richiedono ora l'accesso all'intero keyspace per poter utilizzare gli argomenti GET e BY.

Comportamento di Redis OSS 6.2 e modifiche incompatibili con le versioni precedenti

Per un elenco completo delle modifiche, consulta le note di rilascio di Redis 6.2 OSS.

  • I ACL flag dei LASTSAVE comandiTIME, ECHOROLE, e 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.

  • Durante 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 non compatibili con le versioni precedenti

Per un elenco completo delle modifiche, consulta le note di rilascio di Redis 6.0 OSS.

  • 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 (RedisOSS) 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 non compatibili con le versioni precedenti

Per un elenco completo delle modifiche, consulta le note di rilascio di Redis 5.0 OSS.

  • 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 (RedisOSS) 5.0.

  • Se state eseguendo l'aggiornamento da Redis OSS 4.0, alcuni comandi negli LUA script restituiranno gli argomenti in un ordine diverso rispetto alle versioni precedenti. In Redis OSS 4.0, Redis OSS ordinava 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 (RedisOSS) trasferirà parte del lavoro di I/O sui core in background su tipi di istanze con più di 4. VCPUs 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 incompatibili con le versioni precedenti

Per un elenco completo delle modifiche, consulta le note di rilascio di Redis 4.0 OSS.

  • 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 invece CLUSTER SLOTS.

Passato EOL

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 3.2 OSS.

  • 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 2.8 OSS.

  • A partire da Redis OSS 2.8.22, Redis non è più supportato in (OSSAOFRedis). ElastiCache OSS È preferibile utilizzare MemoryDB quando i dati devono essere conservati in modo duraturo.

  • A partire da Redis OSS 2.8.22, ElastiCache (RedisOSS) 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. Consigliamo di utilizzare la memorizzazione nella cache lato client, disponibile in Redis 6.0 come alternativa alle repliche esterne. OSS

  • I comandi TTL e PTTL 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 con ALPHA ora ordina in base alle impostazioni locali di confronto se non viene utilizzata alcuna opzione STORE.

Per ulteriori informazioni, consulta Pianificazione di fine vita delle versioni Redis OSS.