Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
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, Redis OSS et Memcached.
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 la dernière MINOR version PATCH logicielle à votre cache, sans impact ni interruption de service pour votre application. Aucune action de votre part n'est nécessaire.
Lorsqu'une nouvelle MAJOR version 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 ou API en sélectionnant la dernière version du moteur. CLI
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 PATCH versions et versions disponiblesMAJOR. MINOR 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 OSS cluster Valkey ou Redis 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 Les versions (RedisOSS) sont identifiées par une version sémantique qui comprend un composant MAJOR etMINOR. Par exemple, dans Redis OSS 6.2, la version majeure est 6 et la version mineure 2. Lorsque vous utilisez des clusters conçus par ses soins, ElastiCache (RedisOSS) expose également le PATCH composant, par exemple Redis OSS 6.2.1, et la version du correctif est 1.
MAJORles versions concernent les modifications API incompatibles et MINOR les versions concernent les 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.
Avec Valkey et RedisOSS, 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
Lorsque vous mettez à niveau un OSS cluster Valkey ou Redis 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 Valkey 7.2 et Redis OSS 6.0, ElastiCache nous proposerons une seule version pour chaque version mineure, plutôt que de proposer plusieurs versions de correctif.
À partir de la version 5.0.6 OSS du moteur Redis, 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 est le même mais peut entraîner un temps de basculement plus long pendant la DNS propagation (30 à 1 m).
-
À 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 (RedisOSS) 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 OSS clients Redis, avec des tentatives erronées 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é) à 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é) à Valkey ou Redis OSS (mode cluster activé).
Pour passer d'une version de moteur Valkey ou Redis OSS (mode cluster désactivé) à une version de moteur Valkey ou Redis OSS (mode cluster activé)
-
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.
-
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.
-
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.
-
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 uniques et les OSS 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 OSS clusters Redis sur lesquels le 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.
