Principales différences de comportement et de compatibilité entre les versions

Important

La page suivante est structurée de manière à indiquer toutes les différences d'incompatibilité entre les versions et à vous informer des éléments à prendre en compte lors de la mise à niveau vers des versions plus récentes. Cette liste inclut tous les problèmes d'incompatibilité de versions que vous pourriez rencontrer lors de la mise à niveau.

Vous pouvez effectuer une mise à niveau directement de votre version actuelle de Redis OSS vers la dernière version de Redis OSS disponible, sans avoir besoin de mises à niveau séquentielles. Par exemple, vous pouvez passer directement de la version 3.0 de Redis OSS à la version 7.0.

Les versions de Redis OSS sont identifiées par une version sémantique qui comprend un composant MAJOR, MINOR et PATCH. Par exemple, dans Redis OSS 4.0.10, la version principale est 4, la version mineure 0 et la version du correctif est 10. Ces valeurs sont généralement incrémentées en fonction des conventions suivantes :

• Les versions MAJOR concernent les modifications incompatibles avec l'API

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

• Les versions PATCH sont destinées aux corrections de bogues rétrocompatibles et aux modifications non fonctionnelles

Nous recommandons de toujours utiliser la dernière version du correctif dans une version MAJOR.MINOR donnée afin de bénéficier des dernières améliorations en matière de performances et de stabilité. À partir de Redis OSS 6.0, ElastiCache (Redis OSS) proposera une version unique pour chaque version mineure de Redis OSS, plutôt que de proposer plusieurs versions de correctif. ElastiCache (Redis OSS) gérera automatiquement la version du correctif de vos clusters de cache en cours d'exécution, garantissant ainsi de meilleures performances et une sécurité renforcée.

Nous recommandons également de procéder périodiquement à une mise à niveau vers la dernière version majeure, car la plupart des améliorations majeures ne sont pas rétroportées vers des versions plus anciennes. À mesure que la disponibilité ElastiCache s'étend à une nouvelle AWS région, ElastiCache (Redis OSS) prend en charge les deux versions les plus récentes de MAJOR.MINOR à l'époque pour la nouvelle région. Par exemple, si une nouvelle AWS région est lancée et que les dernières versions de MAJOR.MINOR ElastiCache (Redis OSS) sont 7.0 et 6.2, ElastiCache (Redis OSS) prendra en charge les versions 7.0 et 6.2 dans la nouvelle région. AWS Au fur et à mesure que les nouvelles versions MAJOR.MINOR de ElastiCache (Redis OSS) ElastiCache seront publiées, la prise en charge des nouvelles versions ElastiCache (Redis OSS) continuera d'être ajoutée. Pour en savoir plus sur le choix des régions pour ElastiCache, consultez la section Choix des régions et des zones de disponibilité.

Lorsque vous effectuez une mise à niveau qui couvre des versions majeures ou mineures, veuillez prendre en compte la liste suivante qui inclut les modifications comportementales et rétroincompatibles publiées avec Redis OSS au fil du temps.

Comportement de Redis OSS 7.0 et modifications rétroincompatibles

Pour une liste complète des modifications, consultez les notes de mise à jour de Redis OSS 7.0.

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

Comportement de Redis OSS 6.2 et modifications rétroincompatibles

Pour une liste complète des modifications, consultez les notes de mise à jour de Redis OSS 6.2.

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

  Note

  Aucune de ces commandes ne modifie ou ne donne accès aux données.

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

Comportement de Redis OSS 6.0 et modifications rétroincompatibles

Pour une liste complète des modifications, consultez les notes de mise à jour de Redis OSS 6.0.

• 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 (Redis OSS) 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.

Comportement de Redis OSS 5.0 et modifications rétroincompatibles

Pour une liste complète des modifications, consultez les notes de mise à jour de Redis OSS 5.0.

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

• 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 processeurs virtuels. 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.

Comportement de Redis OSS 4.0 et modifications rétroincompatibles

Pour une liste complète des modifications, consultez les notes de mise à jour de Redis OSS 4.0.

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

EOL passée

Comportement de Redis OSS 3.2 et modifications rétroincompatibles

Pour une liste complète des modifications, consultez les notes de mise à jour de Redis OSS 3.2.

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

Pour plus d’informations, consultez Calendrier de fin de vie des versions Redis OSS.

Comportement de Redis OSS 2.8 et modifications rétroincompatibles

Pour une liste complète des modifications, consultez les notes de mise à jour de Redis OSS 2.8.

• À partir de Redis OSS 2.8.22, Redis OSS AOF n'est 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 (Redis OSS) ne prend plus en charge l'attachement de répliques aux serveurs principaux hébergés dans celui-ci. 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.

Pour plus d'informations, voir Calendrier de fin de vie des versions Redis OSS.