Moteurs et versions pris en charge

• Nouvelles WITHSCORE options ZRANK et nouvelles ZREVRANK commandes

• CLIENTNON- TOUCH pour que les clients exécutent des commandes sans affecterLRU/LFUdes touches.

• Nouvelle commande CLUSTER MYSHARDID qui renvoie l'ID de partition du nœud pour regrouper logiquement les nœuds en mode cluster en fonction de la réplication.

• Optimisations des performances et de la mémoire pour différents types de données.

• Lors d'un appel PUBLISH avec un RESP3 client également abonné à la même chaîne, l'ordre est modifié et la réponse est envoyée avant la publication du message.

• Le suivi côté client pour les scripts suit désormais les clés lues par le script, au lieu des clés déclarées par l'appelant deEVAL/FCALL.

• L'échantillonnage pendant le temps de gel a lieu lors de l'exécution des commandes et dans les scripts.

• Lorsqu'une commande bloquée est débloquée, les contrôles tels que ACLOOM, et d'autres sont réévalués.

• ACLle texte du message d'erreur et les codes d'erreur sont unifiés.

• Une commande de diffusion bloquée qui est lancée lorsque la clé n'existe plus contient un code d'erreur différent (- NOGROUP ou - WRONGTYPE au lieu de -UNBLOCKED).

• Les statistiques des commandes sont mises à jour pour les commandes bloquées uniquement lorsque la commande est réellement exécutée.

• Le stockage interne des ACL utilisateurs ne supprime plus les règles de commande et de catégorie redondantes. Cela peut modifier la façon dont ces règles sont affichées dans le cadre de ACLSAVE, ACL GETUSER et ACLLIST.

• Toutes les connexions client créées pour une utilisation TLS basée sur la réplication, SNI si possible.

• XINFOSTREAM: Le champ de réponse en temps réel indique désormais la dernière tentative d'interaction au lieu de la dernière interaction réussie. Le nouveau champ de réponse en temps actif indique désormais la dernière interaction réussie.

• XREADGROUPet X [AUTO] CLAIM créent le consommateur, qu'il ait pu ou non effectuer une certaine lecture/réclamation. [TBD- c'est quoi le « ça » ici ?]

• ACLl'utilisateur nouvellement créé par défaut définit l'indicateur sanitize-payload dans/. ACL LIST GETUSER

• La HELLO commande n'affecte pas l'état du client si elle n'aboutit pas.

• NANles réponses sont normalisées selon un seul type nan, similaire au comportement actuel de inf.

• ElastiCache (Valkey) version 7.2.6

• ElastiCache (RedisOSS) version 7.1 (améliorée)

• Fonctions : ElastiCache (RedisOSS) 7 ajoute la prise en charge des OSS fonctions Redis et fournit une expérience gérée permettant aux développeurs d'exécuter des LUAscripts avec la logique d'application stockée sur le ElastiCache cluster, sans que les clients n'aient à renvoyer les scripts au serveur à chaque connexion.

• ACLaméliorations : Valkey et Redis OSS 7 ajoutent le support pour la prochaine version de Access Control Lists ()ACLs. Les clients peuvent désormais spécifier plusieurs ensembles d'autorisations sur des clés ou des espaces de touches spécifiques dans Valkey et Redis. OSS

• Pub/Sub fragmenté : ElastiCache avec Valkey et Redis OSS 7, il est possible d'exécuter la fonctionnalité Pub/Sub de manière fragmentée lors de l'exécution en mode cluster activé (). ElastiCache CME Les fonctionnalités Pub/Sub permettent aux éditeurs d'envoyer des messages à n'importe quel nombre d'abonnés sur une chaîne. Les canaux sont liés à une partition du ElastiCache cluster, ce qui élimine le besoin de propager les informations des canaux entre les partitions, ce qui améliore l'évolutivité.

• Multiplexage d'E/S amélioré : ElastiCache Valkey et Redis OSS 7 introduisent un multiplexage d'E/S amélioré, qui permet d'augmenter le débit et de réduire la latence pour les charges de travail à haut débit associées à de nombreuses connexions client simultanées à un cluster. ElastiCache Par exemple, lorsque vous utilisez un cluster de nœuds r6g.xlarge et que vous exécutez 5 200 clients simultanés, vous pouvez obtenir jusqu'à 72 % d'augmentation du débit (opérations de lecture et d'écriture par seconde) et une diminution de 71 % de la latence P99, par rapport à la version 6 de Redis. ElastiCache OSS

• Garantie de stabilité du moteur dans des conditions particulières

• Amélioration de la gestion des erreurs Hyperloglog

• Amélioration des commandes de liaison pour une réplication fiable

• Suivi continu de la diffusion des messages via la commande XCLAIM

• Amélioration de la gestion du champ LFU dans les objets

• Amélioration de la gestion des transactions en cas d'utilisation de ZPOP

• Possibilité de renommer des commandes : paramètre appelé rename-commands qui vous permet de renommer des OSS commandes Redis potentiellement dangereuses ou coûteuses susceptibles d'entraîner une perte de données accidentelle, telle que ou. FLUSHALL FLUSHDB Ceci est similaire à la configuration de la commande de changement de nom dans Redis open source. OSS Cependant, ElastiCache a amélioré l'expérience en fournissant un flux de travail entièrement géré. Les modifications des noms de commande sont appliquées immédiatement et propagées automatiquement sur tous les nœuds du cluster qui contiennent la liste de commandes. Vous n'avez pas besoin d'intervenir, par exemple en redémarrant les nœuds.

  Les exemples suivants montrent comment modifier les groupes de paramètres existants. Ils incluent le paramètre rename-commands, qui est une liste de commandes séparées par des espaces que vous souhaitez renommer.

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall'" --region region
  

  Dans cet exemple, le paramètre rename-commands est utilisé pour renommer la commande flushall en restrictedflushall.

  Pour renommer plusieurs commandes, utilisez ce qui suit :

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall flushdb restrictedflushdb''" --region region
  

  Pour annuler une modification, réexécutez la commande renommée et excluez les valeurs renommées de la liste ParameterValue que vous souhaitez conserver, comme illustré ci-après :

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall'" --region region
  

  Dans ce cas, la commande flushall est renommée restrictedflushall et toutes les autres commandes renommées reprennent leur nom de commande initial.

  Note

  Lorsque vous renommez des commandes, vous devez respecter les limitations suivantes :

  • Toutes les commandes renommées doivent être alphanumériques.

  • La longueur maximale de nouveaux noms de commande est de 20 caractères alphanumériques.

  • Lorsque vous renommez des commandes, assurez-vous que vous mettez à jour le groupe de paramètres associé à votre cluster.

  • Pour empêcher une utilisation entière de la commande, utilisez le mot clé blocked, comme illustré ci-après :

    aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
    --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall blocked'" --region region
    

  Pour plus d'informations sur les modifications de paramètre et une liste des commandes qui sont éligibles pour renommer, consultez Modifications des paramètres de Redis OSS 5.0.3.

• Redis OSS Streams : Cela modélise une structure de données de journal qui permet aux producteurs d'ajouter de nouveaux éléments en temps réel. Il permet également aux consommateurs d'utiliser des messages, de façon bloquante ou non. Les flux permettent aussi aux groupes de consommateurs, qui représentent un groupe de clients, d'utiliser en collaboration différentes parties du même flux de messages, comme avec Apache Kafka. Pour plus d'informations, consultez Streams.

• Prise en charge d'une famille de commandes de flux, telles que XADD, XRANGE et XREAD. Pour plus d'informations, consultez la section Commandes Streams.

• Plusieurs paramètres nouveaux et renommés. Pour de plus amples informations, veuillez consulter Modifications des paramètres de Redis OSS 5.0.0.

• Une nouvelle OSS métrique Redis,StreamBasedCmds.

• Temps de capture légèrement plus rapide pour les OSS nœuds Redis.

• Garantie de stabilité du moteur dans des conditions particulières

• Amélioration de la gestion des erreurs Hyperloglog

• Amélioration des commandes de liaison pour une réplication fiable

• Suivi continu de la diffusion des messages via la commande XCLAIM

• Amélioration de la gestion du champ LFU dans les objets

• Amélioration de la gestion des transactions en cas d'utilisation de ZPOP

• Redis OSS Streams : Cela modélise une structure de données de journal qui permet aux producteurs d'ajouter de nouveaux éléments en temps réel. Il permet également aux consommateurs d'utiliser des messages, de façon bloquante ou non. Les flux permettent aussi aux groupes de consommateurs, qui représentent un groupe de clients, d'utiliser en collaboration différentes parties du même flux de messages, comme avec Apache Kafka. Pour plus d'informations, consultez Streams.

• Prise en charge d'une famille de commandes de flux, telles que XADD, XRANGE et XREAD. Pour plus d'informations, consultez la section Commandes Streams.

• Plusieurs paramètres nouveaux et renommés. Pour de plus amples informations, veuillez consulter Modifications des paramètres de Redis OSS 5.0.0.

• Une nouvelle OSS métrique Redis,StreamBasedCmds.

• Temps de capture légèrement plus rapide pour les OSS nœuds Redis.

• Redimensionnement du cluster en ligne et chiffrement dans une seule version ElastiCache (RedisOSS). Pour plus d’informations, consultez les ressources suivantes :

  • Mise à l'échelle des clusters dans Valkey ou Redis OSS (mode cluster activé)

  • Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)

  • Sécurité des données sur Amazon ElastiCache

• Plusieurs nouveaux paramètres. Pour de plus amples informations, veuillez consulter Modifications des paramètres de Redis OSS 4.0.10.

• Prise en charge des familles de commandes de mémoire, comme MEMORY. Pour plus d'informations, voir Commandes (recherche activéeMEMO).

• Prise en charge de la défragmentation de mémoire en ligne, tout en permettant une utilisation plus efficace de la mémoire et plus de mémoire disponible pour vos données.

• Support pour les purges et les suppressions asynchrones. ElastiCache (RedisOSS) prend en charge des commandes telles queUNLINK, FLUSHDB et FLUSHALL pour s'exécuter dans un thread différent du thread principal. Cette étape aide à améliorer les performances et les temps de réponse pour vos applications en libérant de la mémoire de manière asynchrone.

• Une nouvelle OSS métrique Redis,ActiveDefragHits. Pour plus d'informations, consultez Metrics for Redis OSS.

• Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)

• Redimensionnement de cluster en ligne

• ElastiCache chiffrement en transit () TLS

• Chiffrement au repos dans ElastiCache

• Validation de conformité pour Amazon ElastiCache

Remarques :

• Partitionnement : possibilité de fractionner vos données sur 2 à 500 groupes de nœuds (partitions) avec prise en charge de la réplication pour chaque groupe de nœuds.

• Indexation géospatiale — Redis OSS 3.2.4 introduit la prise en charge de l'indexation géospatiale via six commandes. GEO Pour plus d'informations, consultez la documentation de la commande Redis OSS GEO * Commandes : GEO sur la page Commandes Valkey (filtrée). GEO

• Migration de réplica

• Rééquilibrage du cluster

• Débogueur LUA

• cluster meet

• cluster replicate

• cluster flushslots

• cluster addslots

• cluster delslots

• cluster setslot

• cluster saveconfig

• cluster forget

• cluster failover

• cluster bumpepoch

• cluster set-config-epoch

• cluster reset

• Prise en charge des synchronisations et sauvegardes sans fonction fork, ce qui vous permet d'attribuer moins de mémoire pour les sauvegardes et plus de mémoire pour votre application. Pour de plus amples informations, veuillez consulter Implémentation de la sauvegarde et de la synchronisation. Le processus sans fonction fork peut avoir un impact sur la latence et le débit. Dans le cas d'un débit d'écriture élevé, lorsqu'un réplica relance une synchronisation, il peut être inaccessible pendant toute la durée de la synchronisation.

• En cas de basculement, les groupes de réplication récupèrent désormais plus rapidement, car les réplicas effectuent des synchronisations partielles avec le réplica principal plutôt que des synchronisations complètes, dans la mesure du possible. En outre, les réplicas principaux et les réplicas en lecture n'utilisent plus le disque pendant les synchronisations, permettant ainsi d'optimiser la vitesse.

• Support pour deux nouvelles CloudWatch métriques.

  • ReplicationBytes : le nombre d'octets qu'un cluster principal du groupe de réplication envoie aux réplicas en lecture.

  • SaveInProgress : une valeur binaire qui indique si un processus de sauvegarde en arrière-plan est en cours d'exécution.

  Pour de plus amples informations, veuillez consulter Surveillance de l'utilisation à l'aide de CloudWatch métriques.

• Un certain nombre de corrections de bogues critiques dans le PSYNC comportement de réplication. Pour plus d'informations, consultez les notes de mise à jour de Redis OSS 2.8.

• Afin de maintenir des performances de réplication améliorées dans les groupes de réplication multi-AZ et d'améliorer la stabilité du cluster, les ElastiCache non-répliques ne sont plus prises en charge.

• Pour améliorer la cohérence des données entre le cluster principal et les réplicas d'un groupe de réplication, les réplicas ne supprimeront plus les clés indépendantes du cluster principal.

• Les variables OSS de configuration Redis ne appendfsync sont pas prises en charge sur Redis OSS version 2.8.22 appendonly et versions ultérieures.

• En cas de mémoire insuffisante, les clients avec un important tampon de sortie peuvent être déconnectés d'un cluster de réplica. En cas de déconnexion, le client doit se reconnecter. De telles situations sont les plus susceptibles de se produire pour les PUBSUB clients.

• Support pour HyperLogLog. Pour plus d'informations, consultez la OSSnouvelle structure de données de Redis : HyperLogLog.

• Le type de données « ensemble trié » prend désormais en charge les requêtes de plage lexicographiques avec les nouvelles commandes ZRANGEBYLEX, ZLEXCOUNT et ZREMRANGEBYLEX.

• Pour empêcher un nœud principal d'envoyer des données périmées à des nœuds de réplication, le maître SYNC échoue si un processus enfant save (bgsave) en arrière-plan est abandonné.

• Support pour la HyperLogLogBasedCommands CloudWatchmétrique. Pour de plus amples informations, veuillez consulter Métriques pour Valkey et Redis OSS.

• Résilience et tolérance aux pannes optimisées pour les réplicas en lecture.

• Prise en charge de la resynchronisation partielle.

• Prise en charge du nombre minimum de réplicas en lecture, défini par l'utilisateur, qui doit être disponible en permanence.

• Prise en charge intégrale de la fonction pub/sub — notification aux clients des événements survenus sur le serveur.

• Détection automatique d'une défaillance du nœud principal et basculement de votre nœud principal vers un nœud secondaire.

• Rééquilibrage de section automatisé.

• Recherches plus rapides dans les tables de hachage avec l'algorithme murmur3.

• LRUAlgorithme segmenté.

• LRUcrawler pour récupérer de la mémoire en arrière-plan.

• --enable-seccomp : option pour la compilation.

• Correctifs cumulatifs, tels que ASCII multigets, CVE -2017-9951 et limite les analyses pour. metadumper

• Meilleure gestion des connexions en fermant les connexions à la limite de connexion.

• Gestion améliorée de la taille d'élément pour une taille d'élément supérieure à 1 Mo.

• Meilleures performances et améliorations de la surcharge de mémoire en réduisant les besoins en mémoire par élément de quelques octets.

• Possibilité de vider toutes les métadonnées pour une classe de sections particulière, une liste de classes de sections ou toutes les classes de sections. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.31.

• Amélioration de la prise en charge pour les éléments volumineux dépassant la taille par défaut de 1 mégaoctet. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.29.

• Possibilité de spécifier pendant combien de temps un client peut rester inactif avant d'être invité à se fermer.

  Possibilité d'augmenter dynamiquement la quantité de mémoire disponible pour Memcached sans avoir à redémarrer le cluster. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.27.

• La journalisation de fetchers, mutations et evictions est désormais prise en charge. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.26.

• La mémoire libérée peut être récupérée dans un pool global et réaffectée à de nouvelles classes de sections. Pour plus d'informations, consultez Notes de mise à jour de Memcached 1.4.25.

• Plusieurs corrections de bugs.

• Quelques nouvelles commandes et paramètres. Pour en obtenir la liste, veuillez consulter Paramètres ajoutés Memcached 1.4.33.

• Gestion la moins récemment utilisée (LRU) à l'aide d'un processus en arrière-plan.

• L'ajout de l'option d'utilisation de jenkins ou murmur3 en tant qu'algorithme de hachage.

• Quelques nouvelles commandes et paramètres. Pour en obtenir la liste, veuillez consulter Paramètres ajoutés Memcached 1.4.24.

• Plusieurs corrections de bugs.

• Capacité de rééquilibrage de section améliorée.

• Amélioration de l'évolutivité et des performances.

• L'ajout de la commande touch pour mettre à jour le délai d'expiration d'un élément existant sans avoir à l'extraire.

• Découverte automatique  : la possibilité pour les programmes client de déterminer automatiquement tous les nœuds de cache dans un cluster, et d'initier et maintenir des connexions à tous ces nœuds.