Gestion des versions pour ElastiCache

Gérez la manière dont vous souhaitez mettre à jour vos ElastiCache caches et vos clusters conçus par vous-même et mis à jour pour les moteurs Valkey, Memcached et Redis OSS.

Gestion des versions pour ElastiCache Serverless Cache

Gérez si et quand le cache ElastiCache sans serveur est mis à niveau et effectuez les mises à niveau de version selon vos propres conditions et délais.

ElastiCache Serverless applique automatiquement les dernières versions des logiciels MINOR et PATCH à votre cache, sans aucun impact ni interruption de service pour votre application. Aucune action de votre part n'est nécessaire.

Lorsqu'une nouvelle version MAJOR est disponible, ElastiCache Serverless vous envoie une notification dans la console et un événement dans EventBridge. Vous pouvez choisir de mettre à niveau votre cache vers la dernière version majeure en modifiant votre cache à l’aide de la console, de l’interface de ligne de commande ou de l’API et en sélectionnant la dernière version du moteur.

Gestion des versions pour les clusters conçus par vos soins ElastiCache

Lorsque vous travaillez avec des ElastiCache clusters conçus par vous-même, vous pouvez contrôler le moment où le logiciel qui alimente votre cluster de cache est mis à niveau vers les nouvelles versions prises en charge par ElastiCache. Vous pouvez contrôler à quel moment mettre à niveau votre cache vers les dernières versions MAJOR, MINOR et PATCH disponibles. Vous lancez les mises à niveau de version du moteur dans votre cluster ou groupe de réplication en le modifiant et en spécifiant une nouvelle version de moteur.

Vous pouvez contrôler si et quand le logiciel conforme au protocole qui alimente votre cluster de cache est mis à niveau vers de nouvelles versions prises en charge par. ElastiCache Ce niveau de contrôle permet de maintenir la compatibilité avec des versions spécifiques, de tester les nouvelles versions avec votre application avant le déploiement en production et de réaliser des mises à niveau en fonction de vos propres conditions et délais.

Comme les mises à niveau de version peuvent présenter un risque en termes de compatibilité, elles ne se produisent pas automatiquement. Vous devez les initier.

Clusters Valkey et Redis OSS

Note

• Si un cluster Valkey ou Redis OSS est répliqué dans une ou plusieurs régions, la version du moteur est mise à niveau pour les régions secondaires, puis pour la région principale.

• ElastiCache pour Redis OSS, les versions sont identifiées par une version sémantique comprenant un composant MAJEUR et un composant MINEUR. Par exemple, dans Redis OSS 6.2, la version principale est 6 et la version mineure 2. Lorsque vous utilisez des clusters conçus par vos soins, ElastiCache Redis OSS expose également le composant PATCH, par exemple Redis OSS 6.2.1, et la version du correctif est 1.

  Les versions MAJOR concernent les modifications incompatibles avec l'API, tandis que les versions MINOR concernent les nouvelles fonctionnalités ajoutées de manière rétrocompatible Les versions PATCH sont destinées aux correctifs de bogues rétrocompatibles et aux modifications non fonctionnelles

Avec Valkey et Redis OSS, vous initiez les mises à niveau de version du moteur vers votre cluster ou groupe de réplication en le modifiant et en spécifiant une nouvelle version du moteur. Pour de plus amples informations, veuillez consulter Modification d'un groupe de réplication.

Memcached

Avec Memcached, pour passer à une version plus récente, vous devez modifier votre cluster de cache et spécifier la nouvelle version du moteur que vous souhaitez utiliser. La mise à niveau vers une version Memcached plus récente est un processus destructeur – vous perdez vos données et repartez avec un cache passif. Pour de plus amples informations, veuillez consulter Modification d'un ElastiCache cluster.

Vous devez être conscient des exigences suivantes quand vous effectuez une mise à niveau à partir d'une ancienne version de Memcached vers la version 1.4.33 ou une version ultérieure. CreateCacheCluster et ModifyCacheCluster échouent dans les conditions suivantes :

• Si slab_chunk_max > max_item_size.

• Si max_item_size modulo slab_chunk_max != 0.

• Si max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).

  La valeur (max_cache_memory - memcached_connections_overhead) est la mémoire du nœud utilisable pour les données. Pour de plus amples informations, veuillez consulter Surcharge de la connexion Memcached.

Considérations en matière de mise à niveau lorsque vous utilisez des clusters auto-conçus

Note

Les considérations suivantes s’appliquent uniquement lors de la mise à niveau de clusters auto-conçus. Ils ne s'appliquent pas à ElastiCache Serverless.

Considérations relatives à Valkey et Redis OSS

Lors de la mise à niveau d'un cluster Valkey ou Redis OSS conçu par vos soins, tenez compte des points suivants.

• La gestion de la version du moteur est conçue afin que vous ayez autant de contrôle que possible sur le déroulement de la correction. Toutefois, ElastiCache se réserve le droit de corriger votre cluster en votre nom dans le cas peu probable d'une faille de sécurité critique dans le système ou le logiciel de cache.

• À partir de ElastiCache la version 7.2 pour Valkey et de ElastiCache la version 6.0 pour Redis OSS, nous ElastiCache proposerons une version unique pour chaque version mineure, plutôt que de proposer plusieurs versions de correctif.

• À partir de la version 5.0.6 du moteur Redis OSS, vous pouvez mettre à niveau la version de votre cluster avec un temps d'arrêt minimal. Le cluster est disponible pour la lecture pendant toute la mise à niveau et reste disponible pour l'écriture pendant la majeure partie de la mise à niveau, sauf durant l'opération de basculement, qui dure quelques secondes.

• Vous pouvez également mettre à niveau vos ElastiCache clusters avec des versions antérieures à 5.0.6. Le processus impliqué est le même, mais peut entraîner un temps de basculement plus long pendant la propagation DNS (30 s-1 mn).

• À partir de Redis OSS 7, ElastiCache permet de basculer entre Valkey ou Redis OSS (mode cluster désactivé) et Valkey ou Redis OSS (mode cluster activé).

• Le processus de mise à niveau du moteur Amazon ElastiCache for Redis OSS est conçu pour faire de son mieux pour conserver vos données existantes et nécessite une réplication Redis OSS réussie.

• Lors de la mise à niveau du moteur, les connexions client existantes ElastiCache seront interrompues. Pour minimiser les temps d'arrêt lors des mises à niveau du moteur, nous vous recommandons de mettre en œuvre les meilleures pratiques pour les clients Redis OSS, avec des tentatives d'erreur et des retards exponentiels, ainsi que les meilleures pratiques pour minimiser les temps d'arrêt pendant la maintenance.

• Vous ne pouvez pas passer directement de Valkey ou Redis OSS (mode cluster désactivé) vers Valkey ou Redis OSS (mode cluster activé) lorsque vous mettez à niveau votre moteur. La procédure suivante explique comment passer de Valkey ou Redis OSS (mode cluster désactivé) vers Valkey ou Redis OSS (mode cluster activé).

  Pour passer d'une version de moteur Valkey ou Redis OSS (mode cluster désactivé) vers une version de moteur Valkey ou Redis OSS (mode cluster activé)

  1. Effectuez une sauvegarde de votre cluster ou groupe de réplication Valkey ou Redis OSS (mode cluster désactivé). Pour de plus amples informations, veuillez consulter Réalisation de sauvegardes manuelles.

  2. Utilisez la sauvegarde pour créer et amorcer un cluster Valkey ou Redis OSS (mode cluster activé) avec une partition (groupe de nœuds). Spécifiez la nouvelle version du moteur et activez le mode de cluster lors de la création du cluster ou du groupe de réplication. Pour de plus amples informations, veuillez consulter Tutoriel : Création d'un nouveau cluster conçu par vos soins avec une sauvegarde créée en externe.

  3. Supprimez l'ancien cluster ou groupe de réplication Valkey ou Redis OSS (mode cluster désactivé). Pour plus d’informations, consultez Supprimer un cluster dans ElastiCache ou Suppression d'un groupe de réplication.

  4. Adaptez le nouveau cluster ou groupe de réplication Valkey ou Redis OSS (mode cluster activé) au nombre de partitions (groupes de nœuds) dont vous avez besoin. Pour plus d’informations, consultez Mise à l'échelle des clusters dans Valkey ou Redis OSS (mode cluster activé).

• Lors de la mise à niveau des versions majeures du moteur, par exemple de 5.0.6 à 6.0, vous devez également choisir un nouveau groupe de paramètres compatible avec la nouvelle version du moteur.

• Pour les clusters Redis OSS uniques et les clusters dont le mode multi-AZ est désactivé, nous recommandons de mettre suffisamment de mémoire à la disposition de Redis OSS, comme décrit dans. S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS Dans ce cas, le réplica principal n'est pas disponible pour traiter les demandes de service pendant la mise à niveau.

• Pour les clusters Redis OSS sur lesquels le mode multi-AZ est activé, nous vous recommandons également de planifier les mises à niveau du moteur pendant les périodes de faible trafic d'écriture entrant. Lors de la mise à niveau vers Redis OSS 5.0.6 ou une version ultérieure, le cluster principal reste disponible pour les demandes de service pendant le processus de mise à niveau.

  Les clusters et les groupes de réplication avec plusieurs partitions sont traités et soumis à des correctifs comme suit :

  • Toutes les partitions sont traitées en parallèle. Une seule opération de mise à niveau à la fois est effectuée sur une partition.

  • Dans chaque partition, tous les réplicas sont traités avant le réplica principal. S'il y a moins de réplicas dans une partition, le réplica principal de cette partition peut être traité avant que le traitement des réplicas des autres partitions ne soit terminé.

  • Dans toutes les partitions, les nœuds principaux sont traités en séries. Un seul nœud principal est mis à niveau à la fois.

• Si les chiffrements sont activés sur votre cluster ou votre groupe de réplication actuel, vous ne pouvez pas effectuer de mise à niveau vers une version du moteur ne prenant pas en charge le chiffrement, comme par exemple de 3.2.6 vers 3.2.10.

Considérations relatives à Memcached

Lorsque vous mettez à niveau un cluster Memcached conçu par vos soins, tenez compte des points suivants.

• La gestion de la version du moteur est conçue afin que vous ayez autant de contrôle que possible sur le déroulement de la correction. Toutefois, ElastiCache se réserve le droit de corriger votre cluster en votre nom dans le cas peu probable d'une faille de sécurité critique dans le système ou le logiciel de cache.

• Comme le moteur Memcached ne prend pas en charge la persistance, les mises à niveau de version du moteur Memcached sont toujours un processus perturbateur qui efface toutes les données de cache dans le cluster.