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

Les versions majeures concernent les modifications incompatibles avec l'API

Les versions mineures concernent les nouvelles fonctionnalités ajoutées de manière rétrocompatible

Les versions de correctif sont destinées à corriger des bogues rétrocompatibles et à apporter 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 fonctions Redis OSS.

Les canaux Pubsub sont désormais bloqués par défaut pour les nouveaux utilisateurs de la liste ACL.

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 catégories d'ACL pour SELECT, WAIT, ROLE, LASTSAVE, 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 drapeaux ACL des commandes TIME, ECHO, ROLE et LASTSAVE 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 (nouveauté de Redis OSS 6.0), considérez les implications d'une interruption du script 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 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 la ElastiCache version 5.0 pour Redis OSS.

Si vous effectuez une mise à niveau depuis Redis OSS 4.0, certaines commandes des scripts LUA 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 Redis OSS déchargera une partie du travail d'E/S vers les cœurs d'arrière-plan sur les types d'instances comportant 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 OSS AOF n'est plus pris en charge dans Redis OSS. ElastiCache 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 Redis OSS ne prend plus en charge l'attachement de répliques aux serveurs principaux hébergés dans Redis OSS. 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.