Principales différences de comportement et de compatibilité entre les versions avec Redis OSS

MAJORles versions concernent les modifications API incompatibles

MINORles versions sont destinées aux nouvelles fonctionnalités ajoutées de manière rétrocompatible

PATCHles versions sont destinées à des corrections de bogues rétrocompatibles et à des modifications non fonctionnelles

SCRIPT LOAD et SCRIPT FLUSH ne sont plus propagés vers des réplicas. Si vous avez besoin d'une certaine durabilité pour les scripts, nous vous recommandons d'utiliser les OSSfonctions Redis.

Les chaînes Pubsub sont désormais bloquées par défaut pour les nouveaux ACL utilisateurs.

La commande STRALGO a été remplacée par la commande LCS.

Le format de ACL GETUSER a été modifié de sorte que tous les champs affichent le modèle de chaîne d'accès standard. Si vous avez utilisé l'automatisation pour ACL GETUSER, vous devez vérifier qu'il gère l'un des deux formats.

Les ACL catégories pourSELECT,WAIT, ROLELASTSAVE,READONLY,READWRITE, et ASKING ont changé.

La commande INFO affiche désormais les statistiques des commandes par sous-commande plutôt que dans les commandes de conteneur de niveau supérieur.

Les valeurs de retour des commandes LPOP, RPOP, ZPOPMIN et ZPOPMAX ont changé dans certains cas limites. Si vous utilisez ces commandes, vous devez consulter les notes de mise à jour et évaluer si vous êtes concerné.

Les commandes SORT et SORT_RO nécessitent désormais un accès à l'intégralité de l'espace de clés pour pouvoir utiliser les arguments GET et BY.

Les ACL drapeaux des LASTSAVE commandesTIME, ECHOROLE, et ont été modifiés. Cela peut entraîner le rejet de commandes qui étaient précédemment acceptées et vice versa.

Lors de la mise à niveau depuis Redis OSS 6.0, l'ordre des paires clé/valeur renvoyées par une réponse cartographique à un script lua est modifié. Si vos scripts utilisent redis.setresp() ou renvoient une carte (nouvelle version de Redis OSS 6.0), considérez les implications que le script peut entraîner lors des mises à niveau.

Le nombre maximum de bases de données autorisées a été diminué de 1,2 million à 10 mille. La valeur par défaut est 16, et nous vous déconseillons d'utiliser des valeurs beaucoup plus grandes car nous avons constaté des problèmes de performances et de mémoire.

Définissez AutoMinorVersionUpgrade le paramètre sur yes, et ElastiCache (RedisOSS) gérera la mise à niveau de la version mineure via des mises à jour en libre-service. Cela sera géré par les canaux standard de notification client via une campagne de mise à jour en libre-service. Pour plus d'informations, consultez la section Mises à jour en libre-service dans ElastiCache.

Les scripts sont répliqués par effets au lieu de réexécuter le script sur le réplica. Cela améliore généralement les performances, mais peut augmenter la quantité de données répliquées entre les principaux et les réplicas. Il existe une option permettant de revenir au comportement précédent qui n'est disponible que dans ElastiCache (RedisOSS) 5.0.

Si vous effectuez une mise à niveau depuis Redis OSS 4.0, certaines commandes LUA des scripts renverront les arguments dans un ordre différent de celui des versions précédentes. Dans Redis OSS 4.0, Redis OSS ordonnait certaines réponses de manière lexographique afin de les rendre déterministes. Cet ordre n'est pas appliqué lorsque les scripts sont répliqués par des effets.

Dans Redis OSS 5.0.3 et versions ultérieures, ElastiCache (RedisOSS) déchargera une partie du travail d'E/S sur les cœurs d'arrière-plan sur les types d'instances contenant plus de 4. VCPUs Cela peut modifier les caractéristiques de performance de Redis OSS et modifier les valeurs de certaines métriques. Pour plus d'informations, consultez Quelles métriques dois-je surveiller ? pour savoir si vous devez modifier les métriques que vous surveillez.

Le journal lent enregistre désormais deux arguments supplémentaires, le nom et l'adresse du client. Cette modification devrait être rétrocompatible, sauf si vous comptez explicitement sur le fait que chaque entrée du journal lent contient 3 valeurs.

La commande CLUSTER NODES renvoie désormais un format légèrement différent, qui n'est pas rétrocompatible. Nous recommandons aux clients de ne pas utiliser cette commande pour connaître les nœuds présents dans un cluster, et d'utiliser plutôt CLUSTER SLOTS.

Il n'y a pas de modifications de compatibilité à signaler pour cette version.

À partir de Redis OSS 2.8.22, Redis n'OSSAOFest plus pris en charge dans ElastiCache (Redis). OSS Nous recommandons d'utiliser MemoryDB lorsque les données doivent être conservées de manière durable.

À partir de Redis OSS 2.8.22, ElastiCache (RedisOSS) ne prend plus en charge l'attachement de répliques aux serveurs principaux hébergés dans Redis. ElastiCache Pendant la mise à niveau, les réplicas externes seront déconnectés et il sera impossible de les reconnecter. Nous recommandons d'utiliser la mise en cache côté client, disponible dans Redis OSS 6.0, comme alternative aux répliques externes.

Les commandes TTL et PTTL renvoient désormais -2 si la clé n'existe pas et -1 si elle existe, mais n'a pas d'expiration associée. Redis OSS 2.6 et les versions précédentes renvoyaient -1 pour les deux conditions.

SORT avec ALPHA trie désormais en fonction des paramètres régionaux de classement locaux si aucune option STORE n'est utilisée.