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.
# Travailler avec ElastiCache
Dans cette section, vous trouverez des informations sur la manière de gérer les différents composants de votre ElastiCache implémentation.
**Topics**
+ [Instantané et restauration](backups.md)
+ [Versions du moteur et mise à niveau dans ElastiCache](engine-versions.md)
+ [ElastiCache meilleures pratiques et stratégies de mise en cache](BestPractices.md)
+ [Gestion de votre cluster basé sur des nœuds dans ElastiCache](manage-self-designed-cluster.md)
+ [Connexion automatique d'une EC2 instance et d'un ElastiCache cache](compute-connection.md)
+ [Dimensionnement ElastiCache](Scaling.md)
+ [Commencer à utiliser les filtres Bloom](BloomFilters.md)
+ [Commencer à utiliser Watch in Serverless](ServerlessWatch.md)
+ [Commencer à utiliser la recherche vectorielle](vector-search.md)
+ [Commencer à utiliser JSON pour Valkey et Redis OSS](json-gs.md)
+ [Marquer vos ressources ElastiCache](Tagging-Resources.md)
+ [Utilisation de l'objectif Amazon ElastiCache Well-Architected](WellArchitechtedLens.md)
+ [Étapes de dépannage courantes et meilleures pratiques avec ElastiCache](wwe-troubleshooting.md)
# Instantané et restauration
ElastiCache Les caches Amazon exécutant Valkey, Redis OSS ou Serverless Memcached peuvent sauvegarder leurs données en créant un instantané. Vous pouvez utiliser la sauvegarde pour restaurer un cache ou des données de départ dans un nouveau cache. La sauvegarde se compose des métadonnées du cache et de toutes les données figurant dans le cache. Toutes les sauvegardes sont écrites sur Amazon Simple Storage Service (Amazon S3), qui fournit un stockage durable. À tout moment, vous pouvez restaurer vos données en créant un nouveau cache Valkey, Redis OSS ou Serverless Memcached et en le remplissant avec les données d'une sauvegarde. Avec ElastiCache, vous pouvez gérer les sauvegardes à l'aide de AWS Management Console, the AWS Command Line Interface(AWS CLI) et de l' ElastiCache API.
Si vous prévoyez de supprimer un cache et qu’il est important de préserver les données, vous pouvez prendre une précaution supplémentaire. Pour ce faire, créez une sauvegarde manuelle, vérifiez que son statut est *disponible*, puis supprimez le cache. En cas d’échec de la sauvegarde, cette étape garantit que les données du cache seront toujours disponibles. Vous pouvez réessayer de faire une sauvegarde en suivant les bonnes pratiques énoncées précédemment.
**Topics**
+ [Contraintes inhérentes à la sauvegarde](#backups-constraints)
+ [Impact sur les performances des sauvegardes de clusters basés sur des nœuds](#backups-performance)
+ [Planification des sauvegardes automatiques](backups-automatic.md)
+ [Réalisation de sauvegardes manuelles](backups-manual.md)
+ [Création d'une sauvegarde finale](backups-final.md)
+ [Description des sauvegardes](backups-describing.md)
+ [Copie de sauvegardes](backups-copying.md)
+ [Exportation d'une sauvegarde](backups-exporting.md)
+ [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md)
+ [Suppression d'une sauvegarde](backups-deleting.md)
+ [Étiquetage des sauvegardes](backups-tagging.md)
+ [Tutoriel : Création d'un nouveau cluster basé sur des nœuds avec une sauvegarde créée en externe](backups-seeding-redis.md)
## Contraintes inhérentes à la sauvegarde
Les contraintes suivantes doivent être prises en compte lorsque vous planifiez ou procédez à des procédures de sauvegarde :
+ La sauvegarde et la restauration ne sont prises en charge que pour les caches exécutés sur Valkey, Redis OSS ou Serverless Memcached.
+ Pour les clusters Valkey ou Redis OSS (mode cluster désactivé), la sauvegarde et la restauration ne sont pas prises en charge sur les `cache.t1.micro` nœuds. Tous les autres types de nœuds de cache sont pris en charge.
+ Pour les clusters Valkey ou Redis OSS (mode cluster activé), la sauvegarde et la restauration sont prises en charge pour tous les types de nœuds.
+ Au cours d'une période continue de 24 heures, vous ne pouvez pas créer plus de 24 sauvegardes manuelles par cache sans serveur. Pour les clusters basés sur des nœuds Valkey et Redis OSS, vous ne pouvez pas créer plus de 20 sauvegardes manuelles par nœud du cluster.
+ Valkey ou Redis OSS (mode cluster activé) ne prend en charge les sauvegardes qu'au niveau du cluster (pour l'API ou la CLI, au niveau du groupe de réplication). Valkey ou Redis OSS (mode cluster activé) ne prennent pas en charge les sauvegardes au niveau de la partition (pour l'API ou la CLI, au niveau du groupe de nœuds).
+ Pendant le processus de sauvegarde, vous ne pouvez exécuter aucune autre opération d'API ou de CLI sur le cache sans serveur. Vous pouvez exécuter des opérations d'API ou de CLI sur un cluster basé sur un nœud pendant la sauvegarde.
+ Si vous utilisez des caches Valkey ou Redis OSS avec hiérarchisation des données, vous ne pouvez pas exporter de sauvegarde vers Amazon S3.
+ Vous pouvez restaurer une sauvegarde d’un cluster à l’aide du type de nœud r6gd uniquement sur des clusters utilisant le type de nœud r6gd.
## Impact sur les performances des sauvegardes de clusters basés sur des nœuds
Les sauvegardes sur les caches sans serveur sont transparentes pour l’application et n’ont aucun impact sur les performances. Toutefois, lors de la création de sauvegardes pour des clusters basés sur des nœuds, cela peut avoir un impact sur les performances en fonction de la mémoire réservée disponible. Les sauvegardes pour les clusters basés sur des nœuds ne sont pas disponibles avec ElastiCache Memcached, mais sont disponibles avec ElastiCache Redis OSS.
Les instructions suivantes permettent d'améliorer les performances de sauvegarde pour les clusters basés sur des nœuds.
+ Définir le `reserved-memory-percent` paramètre : pour limiter le pagination excessive, nous vous recommandons de définir le *reserved-memory-percent*paramètre. Ce paramètre empêche Valkey et Redis OSS de consommer toute la mémoire disponible du nœud et peut contribuer à réduire la quantité de pagination. Vous pouvez également observer une optimisation des performances simplement en utilisant un nœud plus grand. Pour plus d'informations sur la *mémoire réservée et les *reserved-memory-percent**paramètres, consultez. [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md)
+ Créez des sauvegardes à partir d'une réplique en lecture : si vous exécutez Valkey ou Redis OSS dans un groupe de nœuds comportant plusieurs nœuds, vous pouvez effectuer une sauvegarde à partir du nœud principal ou de l'une des répliques en lecture. En raison des ressources système nécessaires au cours d'un BGSAVE, nous vous conseillons de créer des sauvegardes à partir de l'un des réplicas en lecture. Pendant la création de la sauvegarde à partir du réplica, le nœud principal n'est pas concerné par les exigences de ressources BGSAVE. Le nœud principal peut continuer à répondre aux demandes sans ralentir.
Pour ce faire, veuillez consulter [Création d'une sauvegarde manuelle (console)](backups-manual.md#backups-manual-CON) et dans le **Cluster Name (Nom du cluster)** dans la fenêtre **Create Backup (Créer une Backup)**, choisissez un réplica au lieu du nœud primaire par défaut.
Si vous supprimez un groupe de réplication et demandez une sauvegarde finale, la sauvegarde est ElastiCache toujours prise depuis le nœud principal. Cela garantit que vous capturez les toutes dernières données Valkey ou Redis OSS, avant que le groupe de réplication ne soit supprimé.
# Planification des sauvegardes automatiques
Vous pouvez activer les sauvegardes automatiques pour n'importe quel cache sans serveur ou cluster basé sur des nœuds Valkey ou Redis OSS. Lorsque les sauvegardes automatiques sont activées, ElastiCache crée une sauvegarde du cache sur une base quotidienne. Il n’y a aucun impact sur le cache et le changement est immédiat. Les sauvegardes automatiques peuvent constituer une protection contre la perte de données. En prévision d’une éventuelle défaillance, vous pouvez créer un cache et restaurer vos données à partir de la sauvegarde la plus récente. Vous obtenez ainsi un cache démarré à chaud, dans lequel vos données ont été préchargées, et qui est prêt à l’emploi. Pour de plus amples informations, veuillez consulter [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
Vous pouvez activer les sauvegardes automatiques pour n'importe quel cache Memcached Serverless. Lorsque les sauvegardes automatiques sont activées, ElastiCache crée une sauvegarde du cache sur une base quotidienne. Il n’y a aucun impact sur le cache et le changement est immédiat. Les sauvegardes automatiques peuvent constituer une protection contre la perte de données. En prévision d’une éventuelle défaillance, vous pouvez créer un cache et restaurer vos données à partir de la sauvegarde la plus récente. Vous obtenez ainsi un cache démarré à chaud, dans lequel vos données ont été préchargées, et qui est prêt à l’emploi. Pour de plus amples informations, veuillez consulter [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
Lorsque vous planifiez des sauvegardes automatiques, vous devez prévoir les paramètres suivants :
+ **Heure de début de la sauvegarde** : heure de la journée ElastiCache à laquelle commence la création d'une sauvegarde. Vous pouvez définir le créneau de sauvegarde qui vous convient le mieux. Si vous ne spécifiez pas de fenêtre de sauvegarde, ElastiCache attribuez-en une automatiquement.
+ **Limite de conservation des sauvegardes** – Nombre de jours pendant lesquels la sauvegarde sera conservée dans Amazon S3. Par exemple, si vous définissez la limite de conservation à 5, une sauvegarde effectuée aujourd'hui sera conservée pendant 5 jours. Lorsque la limite de conservation expire, la sauvegarde est supprimée automatiquement.
La limite de conservation maximale des sauvegardes est de 35 jours. Si la limite de conservation des sauvegardes est définie sur 0, les sauvegardes automatiques sont désactivées pour le cache.
Lorsque vous planifiez des sauvegardes automatiques, ElastiCache la création de la sauvegarde commence. Vous pouvez définir le créneau de sauvegarde qui vous convient le mieux. Si vous ne spécifiez pas de fenêtre de sauvegarde, ElastiCache attribuez-en une automatiquement.
Vous pouvez activer ou désactiver les sauvegardes automatiques lors de la création d'un nouveau cache ou de la mise à jour d'un cache existant, à l'aide de la ElastiCache console, de l'AWS CLI API ou de l' ElastiCache API. Pour Valkey et Redis OSS, cela se fait en cochant la case **Activer les sauvegardes automatiques** dans la section Paramètres **avancés de Valkey ou Paramètres** **avancés de Redis** OSS. Pour Memcached, cela se fait en cochant la case **Activer les sauvegardes automatiques** dans la section Paramètres **avancés de Memcached**.
# Réalisation de sauvegardes manuelles
Outre les sauvegardes automatiques, vous pouvez créer une sauvegarde *manuelle* à tout moment. Contrairement aux sauvegardes automatiques, qui sont automatiquement supprimées après une période de conservation spécifiée, les sauvegardes manuelles ne sont pas soumises à une période de conservation et ne sont donc pas automatiquement supprimées. Même si vous supprimez le cache, toutes les sauvegardes manuelles de ce cache sont conservées. Si vous ne souhaitez plus conserver une sauvegarde manuelle, vous devez la supprimer par vous-même.
Les sauvegardes manuelles peuvent non seulement être créées directement, mais également de l'une des façons suivantes :
+ [Copie de sauvegardes](backups-copying.md). Peu importe si la sauvegarde source a été créée automatiquement ou manuellement.
+ [Création d'une sauvegarde finale](backups-final.md). Créez une sauvegarde juste avant de supprimer un cluster ou un nœud.
Vous pouvez créer une sauvegarde manuelle d'un cache à l'aide de AWS Management Console, de AWS CLI, ou de l' ElastiCache API.
Vous pouvez générer des sauvegardes manuelles à partir de répliques dont le mode cluster est activé et le mode cluster est désactivé.
## Création d'une sauvegarde manuelle (console)
**Pour créer une sauvegarde d’un cache (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez les caches **Valkey, les caches** **Redis OSS ou les caches** **Memcached**, selon vos préférences.
1. Cochez la case située à gauche du nom du cache que vous souhaitez sauvegarder.
1. Choisissez **Backup**.
1. Dans la boîte de dialogue **Créer une sauvegarde**, tapez le nom de votre sauvegarde dans la boîte **Nom de la sauvegarde**. Il est préférable que le nom comporte une indication du cluster qui a été sauvegardé, ainsi que la date et l'heure auxquelles la sauvegarde a été effectuée.
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
1. Choisissez **Create Backup**.
L'état du cluster devient *snapshotting*.
## Création d'une sauvegarde manuelle (AWS CLI)
**Sauvegarde manuelle d'un cache sans serveur à l'aide du AWS CLI**
Pour créer une sauvegarde manuelle d'un cache à l'aide de AWS CLI, utilisez l'`create-serverless-snapshot`AWS CLI opération avec les paramètres suivants :
+ `--serverless-cache-name` : nom du cache sans serveur que vous sauvegardez.
+ `--serverless-cache-snapshot-name` – Nom de l'instantané à créer.
Pour Linux, macOS ou Unix :
+
```
aws elasticache create-serverless-snapshot \
--serverless-cache-name CacheName \
--serverless-cache-snapshot-name bkup-20231127
```
Pour Windows :
+
```
aws elasticache create-serverless-snapshot ^
--serverless-cache-name CacheName ^
--serverless-cache-snapshot-name bkup-20231127
```
**Sauvegarde manuelle d'un cluster basé sur des nœuds à l'aide du AWS CLI**
Pour créer une sauvegarde manuelle d'un cluster basé sur un nœud à l'aide de AWS CLI, utilisez l'`create-snapshot`AWS CLI opération avec les paramètres suivants :
+ `--cache-cluster-id`
+ Si le cluster que vous sauvegardez ne possède pas de nœuds de réplication, `--cache-cluster-id` c'est le nom du cluster que vous sauvegardez, par exemple*mycluster*.
+ Si le cluster que vous sauvegardez a un ou plusieurs nœuds de réplica, `--cache-cluster-id` est le nom du nœud du cluster que vous voulez utiliser pour la sauvegarde. Par exemple, le nom peut être*mycluster-002*.
Utilisez ce paramètre uniquement lors de la sauvegarde d'un cluster Valkey ou Redis OSS (mode cluster désactivé).
+ `--replication-group-id`— Nom du cluster Valkey ou Redis OSS (mode cluster activé) (CLI/API : un groupe de réplication) à utiliser comme source pour la sauvegarde. Utilisez ce paramètre lors de la sauvegarde d'un cluster Valkey ou Redis OSS (mode cluster activé).
+ `--snapshot-name` – Nom de l'instantané à créer.
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
### Exemple 1 : sauvegarde d'un cluster Valkey ou Redis OSS (mode cluster désactivé) qui ne possède aucun nœud de réplication
L'AWS CLI opération suivante crée la sauvegarde `bkup-20150515` à partir du cluster Valkey ou Redis OSS (mode cluster désactivé) `myNonClusteredRedis` qui ne possède aucune réplique en lecture.
Pour Linux, macOS ou Unix :
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis \
--snapshot-name bkup-20150515
```
Pour Windows :
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis ^
--snapshot-name bkup-20150515
```
### Exemple 2 : sauvegarde d'un cluster Valkey ou Redis OSS (mode cluster désactivé) avec des nœuds répliques
L'AWS CLI opération suivante crée la sauvegarde `bkup-20150515` à partir du cluster Valkey ou Redis OSS (mode cluster désactivé). `myNonClusteredRedis` Cette sauvegarde a un ou plusieurs réplicas en lecture.
Pour Linux, macOS ou Unix :
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis-001 \
--snapshot-name bkup-20150515
```
Pour Windows :
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis-001 ^
--snapshot-name bkup-20150515
```
**Exemple de sortie : sauvegarde d'un cluster Valkey ou Redis OSS (mode cluster désactivé) avec des nœuds répliqués**
Le résultat de cette opération ressemble à ceci.
```
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis6.x",
"VpcId": "vpc-91280df6",
"CacheClusterId": "myNonClusteredRedis-001",
"SnapshotRetentionLimit": 0,
"NumCacheNodes": 1,
"SnapshotName": "bkup-20150515",
"CacheClusterCreateTime": "2017-01-12T18:59:48.048Z",
"AutoMinorVersionUpgrade": true,
"PreferredAvailabilityZone": "us-east-1c",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "08:30-09:30",
"EngineVersion": "6.0",
"NodeSnapshots": [
{
"CacheSize": "",
"CacheNodeId": "0001",
"CacheNodeCreateTime": "2017-01-12T18:59:48.048Z"
}
],
"CacheSubnetGroupName": "default",
"Port": 6379,
"PreferredMaintenanceWindow": "wed:07:30-wed:08:30",
"CacheNodeType": "cache.m3.2xlarge",
"DataTiering": "disabled"
}
}
```
### Exemple 3 : sauvegarde d'un cluster pour Valkey ou Redis OSS (mode cluster activé)
L'AWS CLI opération suivante crée la sauvegarde `bkup-20150515` à partir du cluster Valkey ou Redis OSS (mode cluster activé). `myClusteredRedis` Notez l'utilisation de `--replication-group-id` au lieu de `--cache-cluster-id` pour identifier la source. Notez également que la sauvegarde ElastiCache est effectuée à l'aide du nœud de réplication lorsqu'il est présent, et qu'il utilise par défaut le nœud principal si un nœud de réplication n'est pas disponible.
Pour Linux, macOS ou Unix :
```
aws elasticache create-snapshot \
--replication-group-id myClusteredRedis \
--snapshot-name bkup-20150515
```
Pour Windows :
```
aws elasticache create-snapshot ^
--replication-group-id myClusteredRedis ^
--snapshot-name bkup-20150515
```
**Exemple de sortie : sauvegarde d'un cluster Valkey ou Redis OSS (mode cluster activé)**
Le résultat de cette opération ressemble à ceci.
```
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis6.x.cluster.on",
"VpcId": "vpc-91280df6",
"NodeSnapshots": [
{
"CacheSize": "",
"NodeGroupId": "0001"
},
{
"CacheSize": "",
"NodeGroupId": "0002"
}
],
"NumNodeGroups": 2,
"SnapshotName": "bkup-20150515",
"ReplicationGroupId": "myClusteredRedis",
"AutoMinorVersionUpgrade": true,
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "10:00-11:00",
"EngineVersion": "6.0",
"CacheSubnetGroupName": "default",
"ReplicationGroupDescription": "2 shards 2 nodes each",
"Port": 6379,
"PreferredMaintenanceWindow": "sat:03:30-sat:04:30",
"CacheNodeType": "cache.r3.large",
"DataTiering": "disabled"
}
}
```
### Rubriques en relation
Pour de plus amples informations, veuillez consulter [create-bucket](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-snapshot.html) dans la *Référence des commandes de la AWS CLI*.
## Création d'une sauvegarde à l'aide de CloudFormation
Vous pouvez l'utiliser CloudFormation pour créer une sauvegarde de votre cache ElastiCache Redis OSS ou Valkey à l'aide des propriétés `AWS::ElastiCache::ServerlessCache` or`AWS::ElastiCache::ReplicationGroup`.
**Utilisation de la `AWS::ElastiCache::ServerlessCache` ressource**
Utilisez-le pour créer une sauvegarde à l'aide de la AWS::ElastiCache::ServerlessCache ressource :
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ServerlessCache
Properties:
...
ServerlessCacheName: "your-cache-name"
Engine: "redis"
CacheUsageLimits
```
**Utilisation de la AWS::ElastiCache::ReplicationGroup ressource**
Utilisez la `AWS::ElastiCache::ReplicationGroup` ressource :
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ReplicationGroup
Properties:
...
ReplicationGroupDescription: "Description of your replication group"
Engine: "redis"
CacheNodeType
NumCacheClusters
AutomaticFailoverEnabled
AtRestEncryptionEnabled
```
# Création d'une sauvegarde finale
Vous pouvez créer une sauvegarde finale à l'aide de la ElastiCache console, de AWS CLI, ou de l' ElastiCache API.
## Création d'une sauvegarde finale (console)
Vous pouvez créer une sauvegarde finale lorsque vous supprimez un cache sans serveur Valkey, Memcached ou Redis OSS, ou un cluster basé sur un nœud Valkey ou Redis OSS, à l'aide de la console. ElastiCache
Pour créer une sauvegarde finale lors de la suppression d'un cache, dans la boîte de dialogue de suppression**, sélectionnez Oui** sous **Créer une sauvegarde** et nommez la sauvegarde.
**Rubriques en relation**
+ [En utilisant le AWS Management Console](Clusters.Delete.md#Clusters.Delete.CON)
+ [Suppression d'un groupe de réplication (console)](Replication.DeletingRepGroup.md#Replication.DeletingRepGroup.CON)
## Création d'une sauvegarde finale (AWS CLI)
Vous pouvez créer une sauvegarde finale lorsque vous supprimez un cache à l'aide du AWS CLI.
**Topics**
+ [Lors de la suppression d'un cache Valkey, d'un cache sans serveur Memcached ou d'un cache Redis OSS](#w2aac24b7c29b7b1b7)
+ [Lors de la suppression d'un cluster Valkey ou Redis OSS sans répliques en lecture](#w2aac24b7c29b7b1b9)
+ [Lors de la suppression d'un cluster Valkey ou Redis OSS avec des répliques de lecture](#w2aac24b7c29b7b1c11)
### Lors de la suppression d'un cache Valkey, d'un cache sans serveur Memcached ou d'un cache Redis OSS
Pour créer une sauvegarde finale, utilisez l'`delete-serverless-cache`AWS CLI opération avec les paramètres suivants.
+ `--serverless-cache-name` : nom du cache en cours de suppression.
+ `--final-snapshot-name` – Nom de la sauvegarde.
Le code suivant permet de créer la sauvegarde finale `bkup-20231127-final` lors de la suppression du cache `myserverlesscache`.
Pour Linux, macOS ou Unix :
```
aws elasticache delete-serverless-cache \
--serverless-cache-name myserverlesscache \
--final-snapshot-name bkup-20231127-final
```
Pour Windows :
```
aws elasticache delete-serverless-cache ^
--serverless-cache-name myserverlesscache ^
--final-snapshot-name bkup-20231127-final
```
Pour plus d’informations, consultez [delete-serverless-cache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache.html) dans la *Référence des commandes de l’AWS CLI*.
### Lors de la suppression d'un cluster Valkey ou Redis OSS sans répliques en lecture
Pour créer une sauvegarde finale pour un cluster basé sur des nœuds sans répliques en lecture, utilisez l'`delete-cache-cluster`AWS CLI opération avec les paramètres suivants.
+ `--cache-cluster-id` – Nom du cluster en cours de suppression.
+ `--final-snapshot-identifier` – Nom de la sauvegarde.
Le code suivant crée la sauvegarde finale `bkup-20150515-final` lors de la suppression du cluster `myRedisCluster`.
Pour Linux, macOS ou Unix :
```
aws elasticache delete-cache-cluster \
--cache-cluster-id myRedisCluster \
--final-snapshot-identifier bkup-20150515-final
```
Pour Windows :
```
aws elasticache delete-cache-cluster ^
--cache-cluster-id myRedisCluster ^
--final-snapshot-identifier bkup-20150515-final
```
Pour plus d’informations, consultez [delete-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-cluster.html) dans la *Référence des commandes de l’AWS CLI*.
### Lors de la suppression d'un cluster Valkey ou Redis OSS avec des répliques de lecture
Pour créer une sauvegarde finale lors de la suppression d'un groupe de réplication, utilisez l'`delete-replication-group`AWS CLI opération, avec les paramètres suivants :
+ `--replication-group-id` – Nom du groupe de réplication en cours de suppression.
+ `--final-snapshot-identifier` – Nom de la sauvegarde finale.
Le code suivant déclenche la sauvegarde finale `bkup-20150515-final` lors de la suppression du groupe de réplication `myReplGroup`.
Pour Linux, macOS ou Unix :
```
aws elasticache delete-replication-group \
--replication-group-id myReplGroup \
--final-snapshot-identifier bkup-20150515-final
```
Pour Windows :
```
aws elasticache delete-replication-group ^
--replication-group-id myReplGroup ^
--final-snapshot-identifier bkup-20150515-final
```
Pour plus d’informations, consultez [delete-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-replication-group.html) dans la *Référence des commandes de l’AWS CLI*.
# Description des sauvegardes
Les procédures suivantes montrent comment afficher la liste de vos sauvegardes. Si vous le souhaitez, vous pouvez également afficher les détails d'une sauvegarde particulière.
## Description des sauvegardes (console)
**Pour afficher les sauvegardes à l'aide du AWS Management Console**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Sauvegardes**.
1. Pour consulter les détails d'une sauvegarde particulière, choisissez la case située à gauche du nom de la sauvegarde.
## Description de sauvegardes sans serveur (AWS CLI)
Pour afficher une liste des sauvegardes sans serveur et, le cas échéant, les détails relatifs à une sauvegarde spécifique, utilisez l’opération d’interface de ligne de commande `describe-serverless-cache-snapshots`.
**Exemples**
L'opération suivante utilise le paramètre `--max-records` pour afficher jusqu'à 20 sauvegardes associées à votre compte. Si le paramètre `--max-records` n'est pas spécifié, la liste répertorie jusqu'à 50 sauvegardes.
```
aws elasticache describe-serverless-cache-snapshots --max-records 20
```
L’opération suivante utilise le paramètre `--serverless-cache-name` pour répertorier uniquement les sauvegardes associées au cache `my-cache`.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-name my-cache
```
L'opération suivante utilise le paramètre `--serverless-cache-snapshot-name` pour afficher les détails de la sauvegarde `my-backup`.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-snapshot-name my-backup
```
Pour plus d'informations, consultez [describe-serverless-cache-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-serverless-cache-snapshots.html)le manuel de référence des AWS CLI commandes.
## Décrire les sauvegardes de clusters basées sur des nœuds ()AWS CLI
Pour afficher une liste de sauvegardes de clusters basées sur des nœuds et éventuellement des détails sur une sauvegarde spécifique, utilisez l'opération `describe-snapshots` CLI.
**Exemples**
L'opération suivante utilise le paramètre `--max-records` pour afficher jusqu'à 20 sauvegardes associées à votre compte. Si le paramètre `--max-records` n'est pas spécifié, la liste répertorie jusqu'à 50 sauvegardes.
```
aws elasticache describe-snapshots --max-records 20
```
L'opération suivante utilise le paramètre `--cache-cluster-id` pour afficher uniquement les sauvegardes associées au cluster `my-cluster`.
```
aws elasticache describe-snapshots --cache-cluster-id my-cluster
```
L'opération suivante utilise le paramètre `--snapshot-name` pour afficher les détails de la sauvegarde `my-backup`.
```
aws elasticache describe-snapshots --snapshot-name my-backup
```
Pour plus d'informations, consultez la section [describe-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-snapshots.html) dans le AWS CLI manuel de référence des commandes.
# Copie de sauvegardes
Vous pouvez créer une copie de n’importe quelle sauvegarde, qu’elle ait été créée automatiquement ou manuellement. Vous pouvez également exporter votre sauvegarde afin d'y accéder de l'extérieur ElastiCache. Pour obtenir de l'aide lors de l'exportation de votre sauvegarde, consultez [Exportation d'une sauvegarde](backups-exporting.md).
Les étapes suivantes expliquent comment copier une sauvegarde.
## Copie de sauvegardes (console)
**Pour copier une sauvegarde (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Sauvegardes** pour afficher la liste de vos sauvegardes.
1. Dans la liste des sauvegardes, cochez la case située à gauche du nom de la sauvegarde à copier.
1. Choisissez **Actions**, puis **Copier**.
1. Saisissez un nom pour votre nouvelle sauvegarde dans la zone **New Backup name**.
1. Choisissez **Copier**.
## Copie d’une sauvegarde sans serveur (AWS CLI)
Pour copier une sauvegarde d’un cache sans serveur, utilisez l’opération `copy-serverless-cache-snapshot`.
**Parameters**
+ `--source-serverless-cache-snapshot-name` – Nom de la sauvegarde à copier.
+ `--target-serverless-cache-snapshot-name` – Nom de la copie de la sauvegarde.
L'exemple suivant fait une copie d'une sauvegarde automatique.
Pour Linux, macOS ou Unix :
```
aws elasticache copy-serverless-cache-snapshot \
--source-serverless-cache-snapshot-name automatic.my-cache-2023-11-27-03-15 \
--target-serverless-cache-snapshot-name my-backup-copy
```
Pour Windows :
```
aws elasticache copy-serverless-cache-snapshot ^
--source-serverless-cache-snapshot-name automatic.my-cache-2023-11-27-03-15 ^
--target-serverless-cache-snapshot-name my-backup-copy
```
Pour plus d’informations, consultez [https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-serverless-cache-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-serverless-cache-snapshot.html) dans le *AWS CLI*.
## Copier une sauvegarde de cluster basée sur un nœud ()AWS CLI
Pour copier une sauvegarde d'un cluster basé sur des nœuds, utilisez l'`copy-snapshot`opération.
**Parameters**
+ `--source-snapshot-name` – Nom de la sauvegarde à copier.
+ `--target-snapshot-name` – Nom de la copie de la sauvegarde.
+ `--target-bucket` – Réservé à l'exportation d'une sauvegarde. N'utilisez pas ce paramètre lorsque vous copiez une sauvegarde. Pour de plus amples informations, veuillez consulter [Exportation d'une sauvegarde](backups-exporting.md).
L'exemple suivant fait une copie d'une sauvegarde automatique.
Pour Linux, macOS ou Unix :
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 \
--target-snapshot-name amzn-s3-demo-bucket
```
Pour Windows :
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 ^
--target-snapshot-name amzn-s3-demo-bucket
```
Pour plus d’informations, consultez [https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html) dans le *AWS CLI*.
# Exportation d'une sauvegarde
Amazon ElastiCache prend en charge l'exportation de votre sauvegarde ElastiCache pour Redis OSS vers un bucket Amazon Simple Storage Service (Amazon S3), ce qui vous permet d'y accéder depuis l'extérieur. ElastiCache Vous pouvez exporter une sauvegarde à l'aide de la ElastiCache console AWS CLI, de l'API ou de l' ElastiCache API.
L'exportation d'une sauvegarde peut s'avérer utile si vous devez lancer un cluster dans une autre AWS région. Vous pouvez exporter vos données dans une AWS région, copier le fichier .rdb dans la nouvelle AWS région, puis utiliser ce fichier .rdb pour amorcer le nouveau cache au lieu d'attendre que le nouveau cluster soit rempli en cours d'utilisation. Pour de plus amples informations sur l'amorçage d'un nouveau cluster, veuillez consulter [Tutoriel : Création d'un nouveau cluster basé sur des nœuds avec une sauvegarde créée en externe](backups-seeding-redis.md). Une autre raison pour laquelle vous souhaiterez peut-être exporter les données de votre cache est d'utiliser le fichier .rdb pour le traitement hors ligne.
**Important**
La ElastiCache sauvegarde et le compartiment Amazon S3 dans lequel vous souhaitez la copier doivent se trouver dans la même AWS région.
Bien que les sauvegardes copiées sur un compartiment Amazon S3 soient chiffrées, nous vous conseillons vivement de ne pas autoriser l'accès au compartiment Amazon S3 dans lequel vous souhaitez stocker vos sauvegardes.
L’exportation d’une sauvegarde vers Amazon S3 n’est pas prise en charge pour les clusters utilisant la hiérarchisation des données. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
L'exportation d'une sauvegarde est disponible pour : les clusters Valkey basés sur des nœuds, les clusters Redis OSS basés sur des nœuds et les caches sans serveur Valkey, Memcached et Redis OSS. L'exportation d'une sauvegarde n'est pas disponible pour les clusters Memcached basés sur des nœuds.
Avant de pouvoir exporter une sauvegarde vers un compartiment Amazon S3, vous devez disposer d'un compartiment Amazon S3 dans la même AWS région que la sauvegarde. Accordez l' ElastiCache accès au bucket. Les deux premières étapes vous indiquent comment procéder.
## Créer un compartiment Amazon S3
Les étapes suivantes utilisent la console Amazon S3 pour créer un compartiment Amazon S3 dans lequel vous exportez et stockez votre ElastiCache sauvegarde.
**Pour créer un compartiment Amazon S3**
1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez **Créer un compartiment**.
1. Dans la fenêtre **Create a Bucket – Select a Bucket Name and Region**, procédez comme suit :
1. Dans **Bucket Name (Nom du compartiment)**, indiquez le nom de votre compartiment Amazon S3.
Le nom de votre compartiment Amazon S3 doit être conforme au DNS. Dans le cas contraire, ElastiCache vous ne pourrez pas accéder à votre fichier de sauvegarde. Les règles de conformité DNS sont les suivantes :
+ Les noms de compartiments doivent comporter entre 3 et 63 caractères.
+ Les noms doivent être une série d'une ou plusieurs étiquettes séparées par un point (.) où chaque étiquette :
+ Il doit commencer par une minuscule ou un chiffre.
+ Il doit terminer par une minuscule ou un chiffre.
+ Contient uniquement des lettres minuscules, des chiffres et des traits d'union.
+ Il ne peut pas présenter le même format qu'une adresse IP (par exemple, 192.0.2.0).
1. Dans la liste des **régions**, choisissez une AWS région pour votre compartiment Amazon S3. Cette AWS région doit être la même AWS que celle de la ElastiCache sauvegarde que vous souhaitez exporter.
1. Choisissez **Créer**.
Pour plus d'informations sur la création d'un compartiment Amazon S3, veuillez consulter [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
## Accordez l' ElastiCache accès à votre compartiment Amazon S3
ElastiCache Pour pouvoir copier un instantané dans un compartiment Amazon S3, vous devez mettre à jour votre politique de compartiment IAM afin d'autoriser l' ElastiCache accès au compartiment.
**Avertissement**
Bien que les sauvegardes copiées dans un compartiment Amazon S3 soient chiffrées, vos données sont accessibles à toute personne ayant accès à votre compartiment Amazon S3. De ce fait, nous vous recommandons vivement de configurer les politiques IAM afin d'empêcher tout accès non autorisé à ce compartiment Amazon S3. Pour plus d'informations, consultez [Gestion des accès](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) dans le *Guide de l'utilisateur Amazon S3*.
Pour créer les autorisations appropriées sur un compartiment Amazon S3, procédez comme suit.
**Pour accorder ElastiCache l'accès à un compartiment S3**
1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez le nom du compartiment Amazon S3 dans lequel vous souhaitez copier la sauvegarde. Il doit s'agir du compartiment S3 que vous avez créé dans [Créer un compartiment Amazon S3](#backups-exporting-create-s3-bucket).
1. Choisissez l'onglet **Permissions** (Autorisations) et sous **Permissions** (Autorisations), choisissez **Access control list (ACL)** (Liste de contrôle d'accès (ACL)), puis choisissez **Edit** (Modifier).
1. Ajoutez l'identifiant canonique du bénéficiaire `540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353` avec les options suivantes :
+ **Objets : Liste, Écriture**
+ **ACL de compartiment : Lecture, Écriture**
**Note**
Pour la GovCloud région PDT, l'identifiant canonique est. `40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6`
Pour la GovCloud région OSU, l'identifiant canonique est. `c54286759d2a83da9c480405349819c993557275cf37d820d514b42da6893f5c`
1. Choisissez **Enregistrer**.
## Exporter une ElastiCache sauvegarde
Vous avez maintenant créé votre compartiment S3 et vous avez accordé ElastiCache les autorisations nécessaires pour y accéder. Ensuite, vous pouvez utiliser la ElastiCache console, la AWS CLI ou l' ElastiCache API pour y exporter votre instantané.
La politique mise à jour devrait ressembler à l'exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399484",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
}
]
}
```
------
Pour les régions optionnelles, voici un exemple de ce à quoi pourrait ressembler la politique IAM mise à jour pour le compartiment S3. (Cet exemple utilise la région Asie-Pacifique (Hong Kong).)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
},
{
"Sid": "Stmt15399484",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
}
]
}
```
------
### Exportation d'une ElastiCache sauvegarde (console)
Les étapes suivantes utilisent la ElastiCache console pour exporter une sauvegarde vers un compartiment Amazon S3 afin que vous puissiez y accéder depuis l'extérieur ElastiCache. Le compartiment Amazon S3 doit se trouver dans la même AWS région que la ElastiCache sauvegarde.
**Pour exporter une ElastiCache sauvegarde vers un compartiment Amazon S3**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Sauvegardes** pour afficher la liste de vos sauvegardes.
1. Dans la liste des sauvegardes, choisissez la case située à gauche du nom de la sauvegarde à exporter.
1. Choisissez **Copier**.
1. Dans **Create Copy of the Backup? (Créer une copie de la sauvegarde ?)**, procédez comme suit :
1. Saisissez un nom pour votre nouvelle sauvegarde dans la zone **New Backup name**.
Le nom doit comprendre entre 1 et 1 000 caractères et pouvoir être encodé en UTF-8.
ElastiCache ajoute un identifiant d'instance et `.rdb` à la valeur que vous entrez ici. Par exemple, si vous entrez `my-exported-backup`, ElastiCache crée `my-exported-backup-0001.rdb`.
1. Dans la liste **Emplacement S3 cible**, choisissez le nom du compartiment Amazon S3 dans lequel vous souhaitez copier votre sauvegarde (le compartiment que vous avez créé dans [Créer un compartiment Amazon S3](#backups-exporting-create-s3-bucket)).
L'**emplacement S3 cible** doit être un compartiment Amazon S3 situé dans la AWS région de la sauvegarde avec les autorisations suivantes pour que le processus d'exportation réussisse.
+ Accès à l'objet – **Lecture** et **Écriture**.
+ Accès aux autorisations – **Lecture**.
Pour de plus amples informations, veuillez consulter [Accordez l' ElastiCache accès à votre compartiment Amazon S3](#backups-exporting-grant-access).
1. Choisissez **Copier**.
**Note**
Si votre compartiment S3 ne dispose pas des autorisations nécessaires ElastiCache pour y exporter une sauvegarde, vous recevez l'un des messages d'erreur suivants. Revenez à [Accordez l' ElastiCache accès à votre compartiment Amazon S3](#backups-exporting-grant-access) pour ajouter les autorisations spécifiées et essayer à nouveau d'exporter votre sauvegarde.
ElastiCache n'a pas obtenu les autorisations READ %s sur le compartiment S3.
**Solution :** ajoutez des autorisations de lecture sur le compartiment.
ElastiCache n'a pas obtenu les autorisations WRITE %s sur le compartiment S3.
**Solution :** ajoutez des autorisations d'écriture sur le compartiment.
ElastiCache n'a pas obtenu les autorisations READ\$1ACP %s sur le compartiment S3.
**Solution :** ajoutez **Read** pour l'accès aux autorisations sur le compartiment.
Si vous souhaitez copier votre sauvegarde vers une autre AWS région, utilisez Amazon S3 pour la copier. Pour de plus amples informations, veuillez consulter [Copie d'objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MakingaCopyofanObject.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
### Exportation d'une sauvegarde ElastiCache sans serveur ()AWS CLI
**Exportation d’une sauvegarde d’un cache sans serveur**
Exportez la sauvegarde dans un compartiment Amazon S3 à l'aide de l'opération `export-serverless-cache-snapshot` de la CLI avec les paramètres suivants :
**Parameters**
+ `--serverless-cache-snapshot-name` – Nom de la sauvegarde à copier.
+ `--s3-bucket-name` – Nom du compartiment Amazon S3 dans lequel vous voulez exporter la sauvegarde. Une copie de la sauvegarde est effectuée dans le compartiment spécifié.
`--s3-bucket-name`Il doit s'agir d'un compartiment Amazon S3 dans la AWS région de la sauvegarde avec les autorisations suivantes pour que le processus d'exportation réussisse.
+ Accès à l'objet – **Lecture** et **Écriture**.
+ Accès aux autorisations – **Lecture**.
L'opération suivante copie une sauvegarde dans le compartiment my-s3-bucket.
Pour Linux, macOS ou Unix :
```
aws elasticache export-serverless-cache-snapshot \
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 \
--s3-bucket-name my-s3-bucket
```
Pour Windows :
```
aws elasticache export-serverless-cache-snapshot ^
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 ^
--s3-bucket-name my-s3-bucket
```
### Exportation d'une sauvegarde de ElastiCache cluster basée sur un nœud ()AWS CLI
**Exportation d'une sauvegarde d'un cluster basé sur des nœuds**
Exportez la sauvegarde dans un compartiment Amazon S3 à l'aide de l'opération `copy-snapshot` de la CLI avec les paramètres suivants :
**Parameters**
+ `--source-snapshot-name` – Nom de la sauvegarde à copier.
+ `--target-snapshot-name` – Nom de la copie de la sauvegarde.
Le nom doit comprendre entre 1 et 1 000 caractères et pouvoir être encodé en UTF-8.
ElastiCache ajoute un identifiant d'instance et `.rdb` à la valeur que vous entrez ici. Par exemple, si vous entrez `my-exported-backup`, ElastiCache crée `my-exported-backup-0001.rdb`.
+ `--target-bucket` – Nom du compartiment Amazon S3 dans lequel vous voulez exporter la sauvegarde. Une copie de la sauvegarde est effectuée dans le compartiment spécifié.
`--target-bucket`Il doit s'agir d'un compartiment Amazon S3 dans la AWS région de la sauvegarde avec les autorisations suivantes pour que le processus d'exportation réussisse.
+ Accès à l'objet – **Lecture** et **Écriture**.
+ Accès aux autorisations – **Lecture**.
Pour de plus amples informations, veuillez consulter [Accordez l' ElastiCache accès à votre compartiment Amazon S3](#backups-exporting-grant-access).
L'opération suivante copie une sauvegarde dans le compartiment my-s3-bucket.
Pour Linux, macOS ou Unix :
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2016-06-27-03-15 \
--target-snapshot-name my-exported-backup \
--target-bucket my-s3-bucket
```
Pour Windows :
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2016-06-27-03-15 ^
--target-snapshot-name my-exported-backup ^
--target-bucket my-s3-bucket
```
# Restauration à partir d’une sauvegarde dans un nouveau cache
Vous pouvez restaurer une sauvegarde existante de Valkey dans un nouveau cache Valkey ou un cluster basé sur des nœuds, et restaurer une sauvegarde Redis OSS existante dans un nouveau cache Redis OSS ou un nouveau cluster basé sur des nœuds. Vous pouvez également restaurer une sauvegarde de cache sans serveur Memcached existante dans un nouveau cache Memcached sans serveur.
## Restauration d’une sauvegarde dans un cache sans serveur (console)
**Note**
ElastiCache Serverless prend en charge les fichiers RDB compatibles avec Valkey 7.2 et versions ultérieures, ainsi que les versions Redis OSS comprises entre la version 5.0 et la dernière version disponible.
**Pour restaurer une sauvegarde sur un cache sans serveur (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Sauvegardes**.
1. Dans la liste des sauvegardes, cochez la case située à gauche du nom de la sauvegarde à restaurer.
1. Choisissez **Actions**, puis **Restaurer**.
1. Entrez un nom et une description facultative pour le nouveau cache sans serveur.
1. Cliquez sur **Créer** pour créer votre cache et importer les données de votre sauvegarde.
## Restauration d'une sauvegarde dans un cluster basé sur un nœud (console)
**Pour restaurer une sauvegarde sur un cluster basé sur un nœud (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Sauvegardes**.
1. Dans la liste des sauvegardes, cochez la case située à gauche du nom de la sauvegarde à restaurer.
1. Choisissez **Actions**, puis **Restaurer**.
1. Choisissez le **cache basé sur les nœuds** et personnalisez les paramètres du cluster, tels que le type de nœud, les tailles, le nombre de partitions, les répliques, le placement AZ et les paramètres de sécurité.
1. Choisissez **Créer** pour créer votre nouveau cluster basé sur des nœuds et importer les données de votre sauvegarde.
## Restauration d’une sauvegarde dans un cache sans serveur (AWS CLI)
**Note**
ElastiCache Serverless prend en charge les fichiers RDB compatibles avec Valkey 7.2 et versions ultérieures, ainsi que les versions Redis OSS comprises entre la version 5.0 et la dernière version disponible.
**Pour restaurer une sauvegarde sur un nouveau cache sans serveur (AWS CLI)**
L'AWS CLI exemple suivant crée un nouveau cache en utilisant les données d'une sauvegarde `create-serverless-cache` et en importe les données.
Pour Linux, macOS ou Unix :
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine redis
--snapshot-arns-to-restore Snapshot-ARN
```
Pour Windows :
```
aws elasticache create-serverless-cache ^
--serverless-cache-name CacheName ^
--engine redis ^
--snapshot-arns-to-restore Snapshot-ARN
```
# Suppression d'une sauvegarde
Une sauvegarde automatique est supprimée automatiquement à l'expiration de sa limite de conservation. Si vous supprimez un cluster, toutes ses sauvegardes automatiques sont également supprimées. Si vous supprimez un groupe de réplication, toutes les sauvegardes automatiques des clusters de ce groupe sont également supprimées.
ElastiCache fournit une opération d'API de suppression qui vous permet de supprimer une sauvegarde à tout moment, que la sauvegarde ait été créée automatiquement ou manuellement. Puisque les sauvegardes manuelles n'ont pas de limite de conversation, une suppression manuelle est le seul moyen de les supprimer.
Vous pouvez supprimer une sauvegarde à l'aide de la ElastiCache console AWS CLI, de l'API ou de l' ElastiCache API.
## Suppression d'une sauvegarde (console)
La procédure suivante permet de supprimer une sauvegarde à l'aide de la ElastiCache console.
**Pour supprimer une sauvegarde**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Sauvegardes**.
La fenêtre Backups affiche une liste de vos sauvegardes.
1. Cochez la case située à gauche du nom de la sauvegarde à supprimer.
1. Sélectionnez **Delete (Supprimer)**.
1. Si vous souhaitez supprimer cette sauvegarde, sélectionnez **Supprimer** sur l'écran de confirmation **Supprimer une sauvegarde**. L'état passe à *deleting*.
## Suppression d’une sauvegarde sans serveur (AWS CLI)
Utilisez l'AWS CLI opération delete-snapshot avec le paramètre suivant pour supprimer une sauvegarde sans serveur.
+ `--serverless-cache-snapshot-name` – Nom de la sauvegarde à supprimer.
Le code suivant supprime la sauvegarde `myBackup`.
```
aws elasticache delete-serverless-cache-snapshot --serverless-cache-snapshot-name myBackup
```
Pour plus d’informations, consultez [delete-serverless-cache-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache-snapshot.html) dans la *Référence des commandes de l’AWS CLI*.
## Suppression d'une sauvegarde de cluster basée sur un nœud ()AWS CLI
Utilisez l'AWS CLI opération delete-snapshot avec le paramètre suivant pour supprimer une sauvegarde de cluster basée sur un nœud.
+ `--snapshot-name` – Nom de la sauvegarde à supprimer.
Le code suivant supprime la sauvegarde `myBackup`.
```
aws elasticache delete-snapshot --snapshot-name myBackup
```
Pour plus d'informations, veuillez consulter [delete-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-snapshot.html) dans la *Référence des commandes AWS CLI*.
# Étiquetage des sauvegardes
Vous pouvez attribuer vos propres métadonnées à chaque sauvegarde sous la forme de balises. Les balises vous permettent de classer vos ressources de différentes manières, par exemple, par objectif, par propriétaire ou par environnement. Cette approche est utile lorsque vous avez de nombreuses ressources de même type. Elle vous permet d’identifier rapidement une ressource spécifique en fonction des balises que vous lui avez attribuées. Pour de plus amples informations, veuillez consulter [Ressources que vous pouvez étiqueter](Tagging-Resources.md#Tagging-your-resources).
Les étiquettes de répartition des coûts sont un moyen de suivre vos coûts sur plusieurs AWS services en regroupant vos dépenses sur les factures par valeur de balise. Pour en savoir plus sur les balises de répartition des coûts, veuillez consulter [Utilisation des balises de répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html).
À l'aide de la ElastiCache console AWS CLI, de l' ElastiCache API ou de l'API, vous pouvez ajouter, répertorier, modifier, supprimer ou copier des balises de répartition des coûts sur vos sauvegardes. Pour de plus amples informations, veuillez consulter [Surveillance des coûts avec des balises de répartition des coûts](Tagging.md).
# Tutoriel : Création d'un nouveau cluster basé sur des nœuds avec une sauvegarde créée en externe
Lorsque vous créez un nouveau cluster basé sur un nœud Valkey ou Redis OSS, vous pouvez l'amorcer avec les données d'un fichier de sauvegarde Valkey ou Redis OSS .rdb. L'ensemencement du cluster est utile si vous gérez actuellement une instance Valkey ou Redis OSS en dehors de ElastiCache et si vous souhaitez remplir votre nouveau ElastiCache cluster basé sur un nœud Redis OSS avec vos données Valkey ou Redis OSS existantes.
Pour démarrer un nouveau cluster basé sur un nœud Valkey ou Redis OSS à partir d'une sauvegarde Valkey ou Redis OSS créée sur Amazon, consultez. ElastiCache [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md)
Lorsque vous utilisez un fichier .rdb Valkey ou Redis OSS pour amorcer un nouveau cluster basé sur des nœuds, vous pouvez effectuer les opérations suivantes :
+ Passez d'un cluster non partitionné à un cluster basé sur un nœud Valkey ou Redis OSS (mode cluster activé) exécutant Redis OSS version 3.2.4.
+ Spécifiez un certain nombre de partitions (appelées groupes de nœuds dans l'API et la CLI) dans le nouveau cluster basé sur des nœuds. Ce nombre peut être différent du nombre de partitions du cluster basé sur des nœuds qui a été utilisé pour créer le fichier de sauvegarde.
+ Spécifiez un type de nœud différent pour le nouveau cluster basé sur des nœuds, plus grand ou plus petit que celui utilisé dans le cluster qui a effectué la sauvegarde. Si vous optez pour un type de nœud plus petit, assurez-vous que le nouveau type de nœud dispose de suffisamment de mémoire pour vos données et pour la surcharge de Valkey ou Redis OSS. Pour de plus amples informations, veuillez consulter [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md).
+ Répartissez vos clés dans les emplacements du nouveau cluster Valkey ou Redis OSS (mode cluster activé) différemment que dans le cluster utilisé pour créer le fichier de sauvegarde.
**Note**
Vous ne pouvez pas démarrer un cluster Valkey ou Redis OSS (mode cluster désactivé) à partir d'un fichier .rdb créé à partir d'un cluster Valkey ou Redis OSS (mode cluster activé).
**Important**
Vous devez vous assurer que vos données de sauvegarde Valkey ou Redis OSS ne dépassent pas les ressources du nœud. Par exemple, vous ne pouvez pas télécharger un fichier .rdb contenant 5 Go de données Valkey ou Redis OSS vers un nœud cache.m3.medium doté de 2,9 Go de mémoire.
Si la sauvegarde est trop volumineuse, le cluster obtenu aura le statut `restore-failed`. Si cela se produit, vous devez supprimer le cluster et recommencer.
Pour une liste complète des types de nœuds et de leurs spécifications, consultez [Paramètres spécifiques au type de nœud Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) la section [Caractéristiques et détails des ElastiCache produits Amazon](https://aws.amazon.com/elasticache/details/).
Vous pouvez chiffrer un fichier .rdb Valkey ou Redis OSS uniquement avec le chiffrement côté serveur Amazon S3 (SSE-S3). Pour plus d'informations, consultez [ Protection des données à l'aide du chiffrement côté serveur](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html).
Vous trouverez ci-dessous des rubriques qui vous guident dans la migration de votre cluster depuis l'extérieur ElastiCache pour Valkey ou Redis OSS vers ElastiCache Redis OSS.
**Topics**
+ [Étape 1 : créer une sauvegarde Valkey ou Redis OSS](#backups-seeding-redis-create-backup)
+ [Étape 2 : Créer un compartiment et un dossier Amazon S3](#backups-seeding-redis-create-s3-bucket)
+ [Étape 3 : Charger votre sauvegarde sur Amazon S3](#backups-seeding-redis-upload)
+ [Étape 4 : Accorder l'accès en ElastiCache lecture au fichier .rdb](#backups-seeding-redis-grant-access)
**Topics**
+ [Étape 1 : créer une sauvegarde Valkey ou Redis OSS](#backups-seeding-redis-create-backup)
+ [Étape 2 : Créer un compartiment et un dossier Amazon S3](#backups-seeding-redis-create-s3-bucket)
+ [Étape 3 : Charger votre sauvegarde sur Amazon S3](#backups-seeding-redis-upload)
+ [Étape 4 : Accorder l'accès en ElastiCache lecture au fichier .rdb](#backups-seeding-redis-grant-access)
## Étape 1 : créer une sauvegarde Valkey ou Redis OSS
**Pour créer la sauvegarde Valkey ou Redis OSS afin de démarrer votre ElastiCache instance Redis OSS**
1. Connectez-vous à votre instance Valkey ou Redis OSS existante.
1. Exécutez l'`BGSAVE`une ou `SAVE` l'autre opération pour créer une sauvegarde. Notez l'emplacement de votre fichier .rdb.
`BGSAVE` est asynchrone et ne bloque pas les autres clients lors du traitement. Pour plus d'informations, consultez [BGSAVE](https://valkey.io/commands/bgsave) sur le site Web de Valkey.
`SAVE` est synchrone et bloque les autres processus jusqu'à la fin. Pour plus d'informations, consultez [SAVE](https://valkey.io/commands/save) sur le site Web de Valkey.
Pour plus d'informations sur la création d'une sauvegarde, consultez [Persistence](https://valkey.io/topics/persistence) sur le site Web de Valkey.
## Étape 2 : Créer un compartiment et un dossier Amazon S3
Une fois que vous avez créé le fichier de sauvegarde, vous devez le télécharger dans un dossier du compartiment Amazon S3. Pour cela, vous devez disposer d'un compartiment Amazon S3 et d'un dossier dans ce compartiment. Si vous avez déjà un compartiment et un dossier Amazon S3 avec les autorisations appropriées, vous pouvez ignorer cette étape et passer à [Étape 3 : Charger votre sauvegarde sur Amazon S3](#backups-seeding-redis-upload).
**Pour créer un compartiment Amazon S3**
1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Pour créer un compartiment Amazon S3, suivez les instructions de la section [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html) dans le *Guide de l'utilisateur de la console Amazon Simple Storage Service*.
Le nom de votre compartiment Amazon S3 doit être conforme au DNS. Sinon, ElastiCache vous ne pourrez pas accéder à votre fichier de sauvegarde. Les règles de conformité DNS sont les suivantes :
+ Les noms de compartiments doivent comporter entre 3 et 63 caractères.
+ Les noms doivent être une série d'une ou plusieurs étiquettes séparées par un point (.) où chaque étiquette :
+ Il doit commencer par une minuscule ou un chiffre.
+ Il doit terminer par une minuscule ou un chiffre.
+ Contient uniquement des lettres minuscules, des chiffres et des traits d'union.
+ Il ne peut pas présenter le même format qu'une adresse IP (par exemple, 192.0.2.0).
Vous devez créer votre compartiment Amazon S3 dans la même AWS région que votre nouveau ElastiCache cluster Redis OSS. Cette approche garantit la vitesse de transfert de données la plus élevée lors de la ElastiCache lecture de votre fichier .rdb depuis Amazon S3.
**Note**
Pour sécuriser au maximum vos données, définissez les autorisations les plus restrictives possible sur votre compartiment Amazon S3. Dans le même temps, les autorisations doivent toujours autoriser l'utilisation du bucket et de son contenu pour démarrer votre nouveau cluster Valkey ou Redis OSS.
**Pour ajouter un dossier à un compartiment Amazon S3**
1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez le nom du compartiment dans lequel le fichier .rdb sera téléchargé.
1. Choisissez **Créer un dossier**.
1. Saisissez un nom dans votre nouveau dossier.
1. Choisissez **Enregistrer**.
Notez le nom du compartiment et celui du dossier.
## Étape 3 : Charger votre sauvegarde sur Amazon S3
Maintenant, téléchargez le fichier .rdb que vous avez créé dans [Étape 1 : créer une sauvegarde Valkey ou Redis OSS](#backups-seeding-redis-create-backup). Vous le téléchargez dans le compartiment Amazon S3 et le dossier que vous avez créé dans [Étape 2 : Créer un compartiment et un dossier Amazon S3](#backups-seeding-redis-create-s3-bucket). Pour plus d'informations sur cette tâche, veuillez consulter [Ajouter un objet à un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html). Entre les étapes 2 et 3, choisissez le nom du dossier que vous avez créé.
**Pour charger votre fichier .rdb dans un dossier Amazon S3**
1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez le nom du compartiment Amazon S3 que vous avez créé à l'étape 2.
1. Choisissez le nom du dossier que vous avez créé à l'étape 2.
1. Choisissez **Charger**.
1. Choisissez **Add files**.
1. Recherchez le ou les fichiers que vous souhaitez charger, puis choisissez-les. Pour choisir plusieurs fichiers, maintenez la touche Ctrl enfoncée pendant que vous sélectionnez chaque nom de fichier.
1. Choisissez **Ouvrir**.
1. Vérifiez que le ou les bons fichiers figurent dans la boîte de dialogue **Charger**, puis choisissez **Charger**.
Notez le chemin de votre fichier .rdb. Par exemple, si le nom de votre compartiment est `myBucket` et que le chemin est `myFolder/redis.rdb`, entrez `myBucket/myFolder/redis.rdb`. Vous avez besoin de ce chemin d'accès pour alimenter le nouveau cluster avec les données de cette sauvegarde.
Pour de plus amples informations, veuillez consulter [Limites et restrictions applicables aux compartiments](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) dans le *Guide de l'utilisateur Amazon Simple Storage Service*.
## Étape 4 : Accorder l'accès en ElastiCache lecture au fichier .rdb
Accordez maintenant l'accès en ElastiCache lecture à votre fichier de sauvegarde .rdb. Vous accordez ElastiCache l'accès à votre fichier de sauvegarde d'une manière différente selon que votre compartiment se trouve dans une AWS région par défaut ou dans une AWS région optionnelle.
AWS Les régions introduites avant le 20 mars 2019 sont activées par défaut. Vous pouvez commencer à travailler dans ces AWS régions immédiatement. Les régions introduites après le 20 mars 2019, telles que l'Asie-Pacifique (Hong Kong) et Moyen-Orient (Bahreïn), sont désactivées par défaut. Vous devez activer ces régions, ou vous y inscrire, avant de pouvoir les utiliser, comme décrit dans la rubrique [Gestion des régions AWS](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) dans le document *Références générales AWS*.
Choisissez votre approche en fonction de votre AWS région :
+ Pour une région par défaut, utilisez la procédure de [Accorder l'accès en ElastiCache lecture au fichier .rdb dans une région par défaut](#backups-seeding-redis-default-region).
+ Pour une région pour laquelle une inscription est nécessaire, utilisez la procédure de [Accorder l'accès en ElastiCache lecture au fichier .rdb dans une région optionnelle](#backups-seeding-opt-in-region).
### Accorder l'accès en ElastiCache lecture au fichier .rdb dans une région par défaut
AWS Les régions introduites avant le 20 mars 2019 sont activées par défaut. Vous pouvez commencer à travailler dans ces AWS régions immédiatement. Les régions introduites après le 20 mars 2019, telles que l'Asie-Pacifique (Hong Kong) et Moyen-Orient (Bahreïn), sont désactivées par défaut. Vous devez activer ces régions, ou vous y inscrire, avant de pouvoir les utiliser, comme décrit dans la rubrique [Gestion des régions AWS](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) dans le document *Références générales AWS*.
**Pour accorder un accès en ElastiCache lecture au fichier de sauvegarde dans une AWS région activée par défaut**
1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez le nom du compartiment S3 qui contient votre fichier .rdb.
1. Choisissez le nom du dossier qui contient votre fichier .rdb.
1. Choisissez le nom de votre fichier de sauvegarde .rdb. Le nom du fichier sélectionné apparaît au-dessus des onglets en haut de la page.
1. Choisissez **Autorisations**.
1. Si **aws-scs-s3-readonly** ou l'un des modèles canoniques de la liste suivante n'est pas répertorié IDs en tant qu'utilisateur, procédez comme suit :
1. Sous **Accès pour les autres AWS comptes**, choisissez **Ajouter un bénéficiaire**.
1. Dans le champ, ajoutez l'identifiant canonique de la AWS région comme indiqué ci-dessous :
+ AWS GovCloud Région (ouest des États-Unis) :
```
40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6
```
**Important**
La sauvegarde doit se trouver dans un compartiment S3 AWS GovCloud (US) pour que vous puissiez la télécharger sur un cluster Valkey ou Redis OSS.AWS GovCloud (US)
+ AWS Régions activées par défaut :
```
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
```
1. Définissez les autorisations sur le compartiment en choisissant **Oui** pour :
+ **Objet en liste/écriture**
+ **Autorisations ACL de l'objet en lecture/écriture**
1. Choisissez **Enregistrer**.
1. Choisissez **Présentation**, puis **Télécharger**.
### Accorder l'accès en ElastiCache lecture au fichier .rdb dans une région optionnelle
AWS Les régions introduites avant le 20 mars 2019 sont activées par défaut. Vous pouvez commencer à travailler dans ces AWS régions immédiatement. Les régions introduites après le 20 mars 2019, telles que l'Asie-Pacifique (Hong Kong) et Moyen-Orient (Bahreïn), sont désactivées par défaut. Vous devez activer ces régions, ou vous y inscrire, avant de pouvoir les utiliser, comme décrit dans la rubrique [Gestion des régions AWS](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) dans le document *Références générales AWS*.
Accordez maintenant l'accès en ElastiCache lecture à votre fichier de sauvegarde .rdb.
**Pour accorder un accès en ElastiCache lecture au fichier de sauvegarde**
1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez le nom du compartiment S3 qui contient votre fichier .rdb.
1. Choisissez le nom du dossier qui contient votre fichier .rdb.
1. Choisissez le nom de votre fichier de sauvegarde .rdb. Le nom du fichier sélectionné apparaît au-dessus des onglets en haut de la page.
1. Sélectionnez l’onglet **Autorisations**.
1. Sous **Permissions** (Autorisations), choisissez **Bucket policy** (Politique de compartiment), puis **Edit** (Modifier).
1. Mettez à jour la politique pour accorder les autorisations ElastiCache requises pour effectuer des opérations :
+ Ajoutez `[ "Service" : "region-full-name.elasticache-snapshot.amazonaws.com" ]` à `Principal`.
+ Ajoutez les autorisations suivantes requises pour exporter un instantané vers le compartiment Amazon S3 :
+ `"s3:GetObject"`
+ `"s3:ListBucket"`
+ `"s3:GetBucketAcl"`
La politique mise à jour devrait ressembler à l'exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/backup1.rdb",
"arn:aws:s3:::amzn-s3-demo-bucket/backup2.rdb"
]
}
]
}
```
------
1. Sélectionnez **Enregistrer les modifications**.
### Ensemencez le ElastiCache cluster avec les données du fichier .rdb
Vous êtes maintenant prêt à créer un ElastiCache cluster et à l'ensemencer avec les données du fichier .rdb. Pour créer le cluster, suivez les instructions de [Création d'un cluster pour Valkey ou Redis OSS](Clusters.Create.md) ou [Création d'un groupe de réplication Valkey ou Redis OSS à partir de zéro](Replication.CreatingReplGroup.NoExistingCluster.md). Assurez-vous de choisir Valkey ou Redis OSS comme moteur de cluster.
La méthode que vous utilisez pour savoir ElastiCache où trouver la sauvegarde que vous avez téléchargée sur Amazon S3 dépend de la méthode que vous avez utilisée pour créer le cluster :
**Ensemencez le ElastiCache cluster ou le groupe de réplication Redis OSS avec les données du fichier .rdb**
+ **Utilisation de la ElastiCache console**
Lorsque vous sélectionnez **Cluster settings** (Paramètres du cluster), choisissez **Restore from backups** (Restaurer à partir de sauvegardes) comme méthode de création du cluster, puis choisissez **Other backups** (Autres sauvegardes) comme **Source** dans la section **Backup source** (Source de sauvegarde). Dans la zone **Seed RDB file S3 location (Ensemencer l'emplacement S3 du fichier RDB)**, tapez le chemin d'accès Amazon S3 pour le ou les fichiers. Si vous avez plusieurs fichiers .rdb, tapez le chemin d'accès à chaque fichier dans une liste séparée par des virgules. Le chemin Amazon S3 ressemble à `myBucket/myFolder/myBackupFilename.rdb`.
+ **En utilisant le AWS CLI**
Si vous utilisez l'opération `create-cache-cluster` ou `create-replication-group`, définissez le paramètre `--snapshot-arns` afin de spécifier un ARN qualifié pour chaque fichier .rdb. Par exemple, `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`. L'ARN doit résoudre les fichiers de sauvegarde stockés dans Amazon S3.
+ **Utilisation de l' ElastiCache API**
Si vous utilisez l'opération `CreateCacheCluster` ou l'`CreateReplicationGroup` ElastiCache API, utilisez le paramètre `SnapshotArns` pour spécifier un ARN complet pour chaque fichier .rdb. Par exemple, `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`. L'ARN doit résoudre les fichiers de sauvegarde stockés dans Amazon S3.
**Important**
Lors de l'amorçage d'un cluster Valkey ou Redis OSS (mode cluster activé), vous devez configurer chaque groupe de nœuds (partition) dans le nouveau cluster ou groupe de réplication. Pour ce faire, utilisez le paramètre `--node-group-configuration` (API : `NodeGroupConfiguration`). Pour plus d’informations, consultez les ressources suivantes :
CLI : [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)dans la AWS CLI référence
API : [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)dans la référence de ElastiCache l'API
Au cours du processus de création de votre cluster, les données de votre sauvegarde Valkey ou Redis OSS sont écrites dans le cluster. Vous pouvez suivre la progression en consultant les messages des ElastiCache événements. Pour ce faire, consultez la ElastiCache console et choisissez **Cache Events**. Vous pouvez également utiliser l'interface de ligne de AWS ElastiCache commande ou l' ElastiCache API pour obtenir des messages d'événements. Pour de plus amples informations, veuillez consulter [Affichage des ElastiCache événements](ECEvents.Viewing.md).
# Versions du moteur et mise à niveau dans ElastiCache
Cette section décrit les moteurs Valkey, Memcached et Redis OSS pris en charge et explique comment procéder à la mise à niveau. Notez que toutes les fonctionnalités disponibles avec Redis OSS 7.2 sont disponibles par défaut dans Valkey 7.2 et versions ultérieures. Vous pouvez également passer de certains moteurs Redis OSS existants ElastiCache à un moteur Valkey.
# Mise à niveau des versions du moteur, y compris les mises à niveau entre
**Valkey et Redis OSS**
Avec Valkey et Redis OSS, vous initiez les mises à niveau de version de votre cluster ou groupe de réplication en le modifiant à l'aide de la ElastiCache console, de l'API ou de l' AWS CLI ElastiCache API et en spécifiant une version du moteur plus récente.
Vous pouvez également effectuer une mise à niveau croisée de Redis OSS vers Valkey. Pour plus d'informations sur les mises à niveau croisées, consultez[Comment passer de Redis OSS à Valkey](#VersionManagement.HowTo.cross-engine-upgrade).
**Topics**
+ [Comment passer de Redis OSS à Valkey](#VersionManagement.HowTo.cross-engine-upgrade)
+ [Résolution des mises à niveau bloquées du moteur Valkey ou Redis OSS](#resolving-blocked-engine-upgrades)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Memcached**
Avec Memcached, pour démarrer les mises à niveau de version de votre cluster, vous devez le modifier et spécifier une version du moteur plus récente. Vous pouvez le faire en utilisant la ElastiCache console, le AWS CLI, ou l' ElastiCache API :
+ Pour utiliser le AWS Management Console, voir —[À l'aide du ElastiCache AWS Management Console](Clusters.Modify.md#Clusters.Modify.CON).
+ Pour utiliser le AWS CLI, voir[En utilisant le AWS CLI avec ElastiCache](Clusters.Modify.md#Clusters.Modify.CLI).
+ Pour utiliser l' ElastiCache API, consultez[Utilisation de l' ElastiCache API](Clusters.Modify.md#Clusters.Modify.API).
## Comment passer de Redis OSS à Valkey
Valkey est conçu pour remplacer directement Redis OSS 7. Vous pouvez effectuer une mise à niveau de Redis OSS vers Valkey à l'aide de la console, de l'API ou de la CLI, en spécifiant le nouveau moteur et la version principale du moteur. L'adresse IP du point de terminaison et tous les autres aspects de l'application ne seront pas modifiés par la mise à niveau. Lors de la mise à niveau depuis Redis OSS 5.0.6 ou version ultérieure, vous ne subirez aucun temps d'arrêt.
**Note**
**AWS Exigences relatives à la version de la CLI pour les mises à niveau de Redis OSS vers Valkey :**
Pour la AWS CLI v1 : version minimale requise 1.35.2 (version actuelle : 1.40.22)
Pour la AWS CLI v2 : version minimale requise 2.18.2 (version actuelle : 2.27.22)
**Note**
Lors de la mise à niveau à partir de versions antérieures de Redis OSS à 5.0.6, vous pouvez rencontrer un temps de basculement de 30 à 60 secondes pendant la propagation du DNS.
Pour mettre à niveau un cluster à nœud unique Redis OSS (mode cluster désactivé) existant vers le moteur Valkey, procédez d'abord comme suit :. [Création d'un groupe de réplication à l'aide d'un cluster existant](Replication.CreatingReplGroup.ExistingCluster.md) Une fois que le cluster à nœud unique Redis OSS (mode cluster désactivé) a été ajouté à un groupe de réplication, vous pouvez effectuer une mise à niveau entre moteurs vers Valkey.
### Mise à niveau d'un groupe de réplication de Redis OSS vers Valkey
Si vous avez un groupe de réplication Redis OSS existant qui utilise le groupe de paramètres de cache par défaut, vous pouvez passer à Valkey en spécifiant le nouveau moteur et la nouvelle version du moteur avec modify-replication-group l'API.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0
```
Si un groupe de paramètres de cache personnalisé est appliqué au groupe de réplication Redis OSS existant que vous souhaitez mettre à niveau, vous devrez également transmettre un groupe de paramètres de cache Valkey personnalisé dans la demande. Le groupe de paramètres personnalisés Valkey en entrée doit avoir les mêmes valeurs de paramètres statiques Redis OSS que le groupe de paramètres personnalisés Redis OSS existant.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0 \
--cache-parameter-group-name myParamGroup
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--cache-parameter-group-name myParamGroup
```
### Mise à niveau d'un cache sans serveur Redis OSS vers Valkey avec la CLI
Pour Linux, macOS ou Unix :
```
aws elasticache modify-serverless-cache \
--serverless-cache-name myCluster \
--engine valkey \
--major-engine-version 8
```
Pour Windows :
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name myCluster ^
--engine valkey ^
--major-engine-version 8
```
### Mise à niveau de Redis OSS vers Valkey avec la console
**Mise à niveau de Redis OSS 5 vers Valkey**
1. Sélectionnez le cache Redis OSS à mettre à niveau.
1. Une fenêtre **de mise à niveau vers Valkey** devrait apparaître. Cliquez sur le bouton **Upgrade to Valkey**.
1. Accédez aux **paramètres du cache**, puis sélectionnez **Version du moteur**. La version la plus récente de Valkey est recommandée.
1. Si ce cache est sans serveur, vous devez mettre à jour le groupe de paramètres. Accédez à la zone **Groupes de paramètres** des **paramètres du cache**, sélectionnez un groupe de paramètres approprié tel que *default.valkey8*.
1. Sélectionnez **Mettre à niveau**.
Ce cache sera désormais répertorié dans la zone Valkey de la console.
**Note**
La mise à niveau directe de Redis OSS 4 ou d'une version antérieure vers Valkey peut entraîner un temps de basculement plus long de 30 à 60 secondes pendant la propagation du DNS.
### Comment rétrograder de Valkey à Redis OSS
Si, pour une raison quelconque, vous souhaitez annuler votre cluster mis à niveau, Amazon ElastiCache prend en charge la restauration d'un cache Valkey 7.2 vers Redis OSS 7.1. Vous pouvez effectuer une restauration en utilisant les mêmes étapes de console, d'API ou de CLI qu'une mise à niveau du moteur et en spécifiant Redis OSS 7.1 comme version du moteur cible. Les annulations utilisent les mêmes processus qu'une mise à niveau. L'adresse IP du point de terminaison et tous les autres aspects de l'application ne seront pas modifiés par le rollback et vous ne subirez aucun temps d'arrêt.
En outre, vous pouvez restaurer un instantané créé à partir de votre cache Valkey 7.2 en tant que cache Redis OSS 7.1. Lorsque vous effectuez une restauration à partir d'un instantané, vous pouvez spécifier Redis OSS 7.1 comme version du moteur cible. Lorsque vous utilisez cette option, un nouveau cache sera créé à partir de l'instantané. La restauration à partir d'un instantané n'a aucun effet sur le cache Valkey à partir duquel le cliché a été créé.
Les exigences et limitations suivantes s'appliquent lors de l'exécution d'un rollback :
+ ElastiCache prend uniquement en charge le retour de Valkey 7.2 à Redis OSS 7.1. Cela est vrai même si vous êtes passé à Valkey 7.2 à partir d'une version antérieure à Redis OSS 7.1.
+ Tous les groupes d'utilisateurs et utilisateurs associés au groupe de réplication ou au cache sans serveur en cours de restauration doivent être configurés avec le type de `REDIS` moteur.
## Résolution des mises à niveau bloquées du moteur Valkey ou Redis OSS
Comme indiqué dans le tableau suivant, votre opération de mise à niveau du moteur Valkey ou Redis OSS est bloquée si vous avez une opération de mise à l'échelle en attente.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Pour résoudre une mise à niveau bloquée du moteur Valkey ou Redis OSS**
+ Effectuez l’une des actions suivantes :
+ Planifiez votre opération de mise à niveau du moteur Redis OSS ou Valkey pour la prochaine fenêtre de maintenance en décochant la case **Appliquer immédiatement**.
Avec la CLI, utilisez `--no-apply-immediately`. Avec l'API, utilisez `ApplyImmediately=false`.
+ Attendez votre prochaine fenêtre de maintenance (ou après) pour effectuer l'opération de mise à niveau du moteur Redis OSS.
+ Ajoutez l'opération de mise à l'échelle Redis OSS à cette modification de cluster en **cochant la case Appliquer immédiatement**.
Avec la CLI, utilisez `--apply-immediately`. Avec l'API, utilisez `ApplyImmediately=true`.
Cette approche annule efficacement la mise à niveau du moteur lors de la prochaine fenêtre de maintenance en l'effectuant immédiatement.
# ElastiCache Support étendu
Grâce ElastiCache au Support étendu, vous pouvez continuer à exécuter votre cache sur une version majeure du moteur après la date de fin du support standard moyennant des frais supplémentaires. Si vous ne procédez pas à la mise à niveau après la date de fin du support standard, des frais vous seront facturés.
Le support étendu fournit les mises à jour et le support technique suivants :
+ Mises à jour de sécurité critiques et élevées CVEs pour votre cache et votre moteur de cache
+ Corrections de bogues et correctifs pour les problèmes critiques
+ Possibilité d'ouvrir des dossiers de support et de recevoir de l'aide au dépannage dans le cadre du contrat ElastiCache de niveau de service standard
Cette offre payante vous donne plus de temps pour passer à une version majeure du moteur compatible.
Par exemple, la date de ElastiCache fin du support standard pour Redis OSS 4.0.10 est le 31 janvier 2026. Si vous n'êtes pas prêt à passer manuellement à Valkey ou à Redis OSS 6 ou version ultérieure à cette date, vos caches ElastiCache seront automatiquement inscrits au Support étendu et vous pourrez continuer à exécuter Redis OSS 4.0.10. À compter du premier jour du mois suivant la fin du support standard, le 1er février 2026, le support étendu vous ElastiCache sera automatiquement facturé.
Le support étendu est disponible jusqu'à 3 ans après la date de fin du support standard pour une version majeure du moteur. Pour les versions 4 et 5 d'Elasticache pour Redis OSS, ce sera le 31 janvier 2029. Après cette date, tous les caches qui exécutent encore les versions 4 et 5 de Redis OSS seront automatiquement mis à niveau vers la dernière version de Valkey.
Une fois la période de support d'un moteur terminée, les caches qui continuent à exécuter cette ancienne version passeront automatiquement au support étendu. Vous serez averti avant la date de début des tarifs du Support étendu afin que vous puissiez mettre à niveau votre instance à la place. Vous pouvez également vous désinscrire explicitement à tout moment en effectuant une mise à niveau vers les versions prises en charge.
Pour plus d'informations sur les dates de fin du support standard et les dates de fin du support étendu, consultez [ElastiCache versions pour le calendrier de fin de vie de Redis OSS](engine-versions.md#deprecated-engine-versions) Valkey, Memcached ou Redis OSS.
**Topics**
+ [ElastiCache Frais de Support étendu](extended-support-charges.md)
+ [Versions avec Support ElastiCache étendu](extended-support-versions.md)
+ [ElastiCache et responsabilités du client avec ElastiCache Extended Support](extended-support-responsibilities.md)
# ElastiCache Frais de Support étendu
Vous devrez payer des frais pour tous les moteurs inscrits au Support ElastiCache étendu à compter du lendemain de la fin du support standard. Pour connaître la date de ElastiCache fin du support standard, consultez[Versions avec Support ElastiCache étendu](extended-support-versions.md).
Les frais supplémentaires pour le Support ElastiCache étendu s'arrêtent automatiquement lorsque vous effectuez l'une des actions suivantes :
+ Passez à une version du moteur couverte par le support standard.
+ Supprimez le cache qui exécute une version majeure après la date de ElastiCache fin de support standard.
Les frais reprendront si la version de votre moteur cible bénéficie du Support étendu à l'avenir.
Par exemple, supposons que la ElastiCache version 4 de Redis OSS entre dans le support étendu le 1er février 2026 et que vous mettez à niveau vos caches de la v4 vers la v6 le 1er janvier 2027. Vous ne serez facturé que pour 11 mois de Support étendu, sur la ElastiCache version 4 de Redis OSS. Si vous continuez à exécuter ElastiCache la version 6 pour Redis OSS après la date de fin du support standard du 31 janvier 2027, ces caches seront à nouveau soumis à des frais de support étendu à compter du 1er février 2027.
Vous pouvez éviter de payer des frais de ElastiCacheExtended support en ElastiCache empêchant la création ou la restauration d'un cache après la date de ElastiCache fin du support standard.
Pour plus d'informations, consultez les [ ElastiCache tarifs Amazon](https://aws.amazon.com/elasticache/pricing/).
# Versions avec Support ElastiCache étendu
Les versions 4 et 5 du logiciel libre Redis (OSS) ont atteint la fin de vie de leur communauté en 2020 et 2022, respectivement. Cela signifie qu'aucune autre mise à jour, correction de bogue ou correctif de sécurité n'est publiée par la communauté. Le support standard pour les versions 4 et 5 de ElastiCache Redis OSS ElastiCache prendra fin le 31 janvier 2026. Si vous continuez à utiliser des versions non prises en charge de Redis OSS, vos données risquent d'être vulnérables à des [vulnérabilités et à des expositions courantes](https://nvd.nist.gov/vuln-metrics/cvss) connues (). CVEs
À compter du 1er février 2026, ElastiCache les caches toujours en cours d'exécution sur les versions 4 et 5 de Redis OSS seront automatiquement inscrits au Support étendu, afin de garantir une disponibilité et une sécurité continues. Bien que le support étendu offre de la flexibilité, nous vous recommandons de considérer la fin du support standard comme une étape de planification de vos charges de travail de production. Nous vous encourageons vivement à mettre à niveau vos caches Redis OSS v4 et v5 vers ElastiCache Valkey ou Redis OSS v6 ou version ultérieure, avant la fin du support standard.
Le tableau suivant récapitule la date de ElastiCache fin du support standard d'Amazon et les dates du support étendu.
**Support étendu et calendrier de fin de vie**
| Version principale du moteur | Support standard terminé | Début du Support étendu Y1 Premium | Début du Support étendu Y2 Premium | Début du Support étendu Y3 Premium | Fin du support étendu et de la version EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31/01/2026 | 01/02/2026 | 01/02/2027 | 01/02/2028 | 31/01/2029 |
| Redis OSS v5 | 31/01/2026 | 01/02/2026 | 01/02/2027 | 01/02/2028 | 31/01/2029 |
| Redis OSS 6 | 31/01/2027 | 01/02/2027 | 01/02/2028 | 01/02/2029 | 31/01/2030 |
Support étendu ne sera proposé que pour la dernière version de correctif prise en charge de chaque version majeure de Redis OSS. Lorsque le support étendu débutera le 1er février 2026, si vos clusters Redis OSS v4 et v5 ne disposent pas déjà des dernières versions de correctif, ils seront automatiquement mis à niveau vers la version 4.0.10 pour Redis OSS v4 et vers la version 5.0.6 pour Redis OSS v5, avant d'être inscrits au support étendu. Cela garantit que vous recevrez des mises à jour de sécurité et des corrections de bogues par le biais du Support étendu. Vous n'avez aucune action à effectuer pour passer à ces dernières versions de correctifs dans le cadre de la transition vers le Support étendu.
# ElastiCache et responsabilités du client avec ElastiCache Extended Support
Vous trouverez ci-dessous les responsabilités d'Amazon ElastiCache et vos responsabilités en matière de Support ElastiCache étendu.
** ElastiCache Responsabilités d'Amazon**
Après la ElastiCache fin de la date de support standard, Amazon ElastiCache fournira des correctifs, des corrections de bogues et des mises à niveau pour les moteurs inscrits au support ElastiCache étendu. Cela se produira pendant 3 ans au maximum, ou jusqu'à ce que vous arrêtiez d'utiliser les moteurs dans le cadre du Support étendu, selon la première éventualité.
**Vos responsabilités**
Vous êtes responsable de l'application des correctifs, des corrections de bogues et des mises à niveau proposés pour les caches dans le cadre du Support ElastiCache étendu. Amazon ElastiCache se réserve le droit de modifier, de remplacer ou de retirer ces correctifs, corrections de bogues et mises à niveau à tout moment. Si un correctif est nécessaire pour résoudre des problèmes de sécurité ou de stabilité critiques, Amazon ElastiCache se réserve le droit de mettre à jour vos caches avec le correctif ou d'exiger que vous installiez le correctif.
Vous êtes également responsable de la mise à niveau de votre moteur vers une version plus récente avant la ElastiCache fin de la date de Support étendu. La date de ElastiCache fin du support étendu est généralement 3 ans après la date de ElastiCache fin du support standard.
Si vous ne mettez pas à niveau votre moteur, après la ElastiCache fin de la date de support étendu, Amazon ElastiCache tentera de le mettre à niveau vers une version plus récente prise en charge dans le cadre du support ElastiCache standard. Si la mise à niveau échoue, Amazon ElastiCache se réserve le droit de supprimer le cache qui exécute le moteur après la date de ElastiCache fin du support standard. Cependant, avant de le faire, Amazon ElastiCache préservera vos données provenant de ce moteur.
# Gestion des versions pour ElastiCache
Gérez la manière dont vous souhaitez mettre à jour vos ElastiCache caches et vos clusters basés sur des nœuds 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 la dernière version mineure et corrective du logiciel à 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 majeure 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. À l'instar des mises à niveau mineures et des correctifs, les mises à niveau des versions majeures sont effectuées sans interruption de service de votre application.
## Gestion des versions pour les clusters basés sur des nœuds ElastiCache
Lorsque vous travaillez avec des ElastiCache clusters basés sur des nœuds, vous pouvez contrôler le moment où le logiciel qui alimente votre cluster 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 majeures, mineures et patchs 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 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 basés sur des nœuds, ElastiCache Redis OSS expose également le composant correctif, par exemple Redis OSS 6.2.1, et la version du correctif est 1.
Les versions majeures concernent les modifications incompatibles avec l'API et les versions mineures sont destinées aux 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.
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](Replication.Modify.md).
**Memcached**
Avec Memcached, pour passer à une version plus récente, vous devez modifier votre cluster 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](Clusters.Modify.md).
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](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead).
## Moteurs et versions pris en charge
ElastiCache les caches sans serveur prennent en charge ElastiCache la version 7.2 pour Valkey et versions ultérieures, la ElastiCache version 1.6 pour Memcached et versions ultérieures, et ElastiCache 7.0 pour Redis OSS et versions ultérieures.
ElastiCache Les clusters basés sur des nœuds prennent en charge ElastiCache la version 7.2 pour Valkey et versions ultérieures, la ElastiCache version 1.4.5 pour Memcached et versions ultérieures, et ElastiCache 4.0.10 pour Redis OSS et versions ultérieures.
**Topics**
+ [Versions de Valkey prises en charge](#supported-engine-versions.valkey)
+ [Vallée 8,2](#valkey-version-8.2)
+ [Vallée 8.1](#valkey-version-8.1)
+ [Valkey 8.0](#valkey-version-8)
+ [ElastiCache version 7.2.6 pour Valkey](#valkey-version-7.2.6)
### Versions de Valkey prises en charge
Versions de Valkey prises en charge ci-dessous. Notez que Valkey prend en charge la plupart des fonctionnalités disponibles dans ElastiCache la version 7.2 pour Redis OSS par défaut.
+ 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](BestPractices.Clients.redis.md), avec des tentatives d'erreur et des retards exponentiels, ainsi que les meilleures pratiques pour [minimiser](BestPractices.MinimizeDowntime.md) 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](backups-manual.md).
1. 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 basé sur des nœuds avec une sauvegarde créée en externe](backups-seeding-redis.md).
1. 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](Clusters.Delete.md) ou [Suppression d'un groupe de réplication](Replication.DeletingRepGroup.md).
1. 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 de plus amples informations, consultez [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md).
+ 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](BestPractices.BGSAVE.md) 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**
Lors de la mise à niveau d'un cluster Memcached basé sur des nœuds, 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.
### ElastiCache version 8.2 pour Valkey
Voici quelques-unes des nouvelles fonctionnalités introduites dans Valkey 8.2 (par rapport à ElastiCache Valkey 8.1) :
+ Support natif de la [recherche vectorielle](vector-search.md), qui vous permet de stocker, d'indexer, de rechercher et de mettre à jour des milliards d'intégrations vectorielles de grande dimension en mémoire avec des latences aussi faibles que les microsecondes.
Pour plus d'informations sur Valkey, voir [Valkey](https://valkey.io/).
Pour plus d'informations sur la version 8.2 de Valkey et sur l'introduction de la recherche vectorielle, consultez [Valkey](https://github.com/valkey-io/valkey-search) Search.
### ElastiCache version 8.1 pour Valkey
Voici quelques-unes des nouvelles fonctionnalités introduites dans Valkey 8.1 (par rapport à ElastiCache Valkey 8.0) :
+ Une [nouvelle implémentation de table de hachage](https://valkey.io/blog/new-hash-table/) qui réduit la surcharge mémoire afin de réduire l'utilisation de la mémoire jusqu'à 20 % pour les key/value modèles courants.
+ Support natif des [filtres Bloom](https://valkey.io/topics/bloomfilters/), un nouveau type de données qui vous permet d'effectuer des recherches en utilisant jusqu'à 98 % de mémoire en moins par rapport au type de données Set.
+ Nouvelle commande [COMMANDLOG](https://valkey.io/commands/commandlog-get/) qui enregistre les exécutions lentes, les demandes volumineuses et les réponses volumineuses.
+ Nouveau support de mise à jour conditionnelle de la commande SET à l'aide de l'argument IFEQ.
+ Améliorations des performances, notamment une latence jusqu'à 45 % inférieure pour la commande ZRANK, des performances jusqu'à 12 fois plus rapides pour PFMERGE et PFCOUNT, et un débit jusqu'à 514 % plus élevé pour BITCOUNT.
[Pour plus d'informations sur Valkey, voir Valkey](https://valkey.io/)
Pour plus d'informations sur la version Valkey 8.1, consultez les notes de mise à jour de [Valkey 8.1](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)
### ElastiCache version 8.0 pour Valkey
Voici quelques-unes des nouvelles fonctionnalités introduites dans Valkey 8.0 (par rapport à ElastiCache Valkey 7.2.6) :
+ Améliorations de l'efficacité de la mémoire, permettant aux utilisateurs de stocker jusqu'à 20 % de données supplémentaires par nœud sans aucune modification de l'application.
+ Infrastructure de métriques par slot récemment introduite pour les clusters basés sur des nœuds, offrant une visibilité détaillée sur les performances et l'utilisation des ressources des emplacements individuels.
+ ElastiCache Serverless for Valkey 8.0 peut doubler le nombre de demandes prises en charge par seconde (RPS) toutes les 2 à 3 minutes, pour atteindre 5 millions de RPS par cache contre zéro en moins de 13 minutes, avec une latence de lecture constante inférieure à la milliseconde p50.
[Pour plus d'informations sur Valkey, voir Valkey](https://valkey.io/)
Pour plus d'informations sur la version de Valkey 8, consultez les notes de mise à jour de [Valkey 8](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)
### ElastiCache version 7.2.6 pour Valkey
Le 10 octobre 2024, ElastiCache la version 7.2.6 pour Valkey est sortie. Voici quelques-unes des nouvelles fonctionnalités introduites dans la version 7.2 (par rapport à la ElastiCache version 7.1 pour Redis OSS) :
+ Optimisations des performances et de la mémoire pour différents types de données : optimisation de la mémoire pour les touches de type liste et ensemble, optimisation de la vitesse pour les commandes d'ensembles triés, optimisation des performances pour les commandes comportant plusieurs touches en mode cluster, amélioration des pub/sub performances, optimisation des performances pour les commandes SCAN, SSCAN, HSCAN, ZSCAN et de nombreuses autres optimisations de moindre envergure.
+ Nouvelle option WITHSCORE pour les commandes ZRANK et ZREVRANK
+ CLIENT NO-TOUCH pour que les clients puissent exécuter des commandes sans affecter LRU/LFU les 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.
[Pour plus d'informations sur Valkey, voir Valkey](https://valkey.io/)
Pour plus d'informations sur la ElastiCache version 7.2 pour Valkey, consultez les [notes de mise à jour de Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (la ElastiCache version 7.2 pour Valkey inclut toutes les modifications depuis la ElastiCache version 7.1 pour Redis OSS jusqu'à la ElastiCache version 7.2.4 pour Redis OSS). [Notes de mise à jour de Valkey 7.2](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) chez Valkey on. GitHub
## ElastiCache version 8.2 pour Valkey
Voici quelques-unes des nouvelles fonctionnalités introduites dans Valkey 8.2 (par rapport à ElastiCache Valkey 8.1) :
+ Support natif de la [recherche vectorielle](vector-search.md), qui vous permet de stocker, d'indexer, de rechercher et de mettre à jour des milliards d'intégrations vectorielles de grande dimension en mémoire avec des latences aussi faibles que les microsecondes.
Pour plus d'informations sur Valkey, voir [Valkey](https://valkey.io/).
Pour plus d'informations sur la version 8.2 de Valkey et sur l'introduction de la recherche vectorielle, consultez [Valkey](https://github.com/valkey-io/valkey-search) Search.
## ElastiCache version 8.1 pour Valkey
Voici quelques-unes des nouvelles fonctionnalités introduites dans Valkey 8.1 (par rapport à ElastiCache Valkey 8.0) :
+ Une [nouvelle implémentation de table de hachage](https://valkey.io/blog/new-hash-table/) qui réduit la surcharge mémoire afin de réduire l'utilisation de la mémoire jusqu'à 20 % pour les key/value modèles courants.
+ Support natif des [filtres Bloom](https://valkey.io/topics/bloomfilters/), un nouveau type de données qui vous permet d'effectuer des recherches en utilisant jusqu'à 98 % de mémoire en moins par rapport au type de données Set.
+ Nouvelle commande [COMMANDLOG](https://valkey.io/commands/commandlog-get/) qui enregistre les exécutions lentes, les demandes volumineuses et les réponses volumineuses.
+ Nouveau support de mise à jour conditionnelle de la commande SET à l'aide de l'argument IFEQ.
+ Améliorations des performances, notamment une latence jusqu'à 45 % inférieure pour la commande ZRANK, des performances jusqu'à 12 fois plus rapides pour PFMERGE et PFCOUNT, et un débit jusqu'à 514 % plus élevé pour BITCOUNT.
[Pour plus d'informations sur Valkey, voir Valkey](https://valkey.io/)
Pour plus d'informations sur la version Valkey 8.1, consultez les notes de mise à jour de [Valkey 8.1](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)
## ElastiCache version 8.0 pour Valkey
Voici quelques-unes des nouvelles fonctionnalités introduites dans Valkey 8.0 (par rapport à ElastiCache Valkey 7.2.6) :
+ Améliorations de l'efficacité de la mémoire, permettant aux utilisateurs de stocker jusqu'à 20 % de données supplémentaires par nœud sans aucune modification de l'application.
+ Infrastructure de métriques par slot récemment introduite pour les clusters basés sur des nœuds, offrant une visibilité détaillée sur les performances et l'utilisation des ressources des emplacements individuels.
+ ElastiCache Serverless for Valkey 8.0 peut doubler le nombre de demandes prises en charge par seconde (RPS) toutes les 2 à 3 minutes, pour atteindre 5 millions de RPS par cache contre zéro en moins de 13 minutes, avec une latence de lecture constante inférieure à la milliseconde p50.
[Pour plus d'informations sur Valkey, voir Valkey](https://valkey.io/)
Pour plus d'informations sur la version de Valkey 8, consultez les notes de mise à jour de [Valkey 8](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)
## ElastiCache version 7.2.6 pour Valkey
Le 10 octobre 2024, ElastiCache la version 7.2.6 pour Valkey est sortie. Voici quelques-unes des nouvelles fonctionnalités introduites dans la version 7.2 (par rapport à la ElastiCache version 7.1 pour Redis OSS) :
+ Optimisations des performances et de la mémoire pour différents types de données : optimisation de la mémoire pour les touches de type liste et ensemble, optimisation de la vitesse pour les commandes d'ensembles triés, optimisation des performances pour les commandes comportant plusieurs touches en mode cluster, amélioration des pub/sub performances, optimisation des performances pour les commandes SCAN, SSCAN, HSCAN, ZSCAN et de nombreuses autres optimisations de moindre envergure.
+ Nouvelle option WITHSCORE pour les commandes ZRANK et ZREVRANK
+ CLIENT NO-TOUCH pour que les clients puissent exécuter des commandes sans affecter LRU/LFU les 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.
[Pour plus d'informations sur Valkey, voir Valkey](https://valkey.io/)
Pour plus d'informations sur la ElastiCache version 7.2 pour Valkey, consultez les [notes de mise à jour de Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (la ElastiCache version 7.2 pour Valkey inclut toutes les modifications depuis la ElastiCache version 7.1 pour Redis OSS jusqu'à la ElastiCache version 7.2.4 pour Redis OSS). [Notes de mise à jour de Valkey 7.2](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) chez Valkey on. GitHub
## Versions du moteur Redis OSS prises en charge
ElastiCache Les caches sans serveur et les clusters basés sur des nœuds prennent en charge toutes les versions 7.1 et antérieures de Redis OSS.
+ [ElastiCache version 7.1 pour Redis OSS (améliorée)](#redis-version-7.1)
**Topics**
+ [ElastiCache version 7.1 pour Redis OSS (améliorée)](#redis-version-7.1)
+ [ElastiCache version 7.0 pour Redis OSS (améliorée)](#redis-version-7.0)
+ [ElastiCache version 6.2 pour Redis OSS (améliorée)](#redis-version-6.2)
+ [ElastiCache version 6.0 pour Redis OSS (améliorée)](#redis-version-6.0)
+ [ElastiCache version 5.0.6 pour Redis OSS (améliorée)](#redis-version-5-0.6)
+ [ElastiCache version 5.0.5 pour Redis OSS (obsolète, utilisez la version 5.0.6)](#redis-version-5-0.5)
+ [ElastiCache version 5.0.4 pour Redis OSS (obsolète, utilisez la version 5.0.6)](#redis-version-5-0.4)
+ [ElastiCache version 5.0.3 pour Redis OSS (obsolète, utilisez la version 5.0.6)](#redis-version-5-0.3)
+ [ElastiCache version 5.0.0 pour Redis OSS (obsolète, utilisez la version 5.0.6)](#redis-version-5-0)
+ [ElastiCache version 4.0.10 pour Redis OSS (améliorée)](#redis-version-4-0-10)
+ [Versions dont la fin de vie (EOL) est passée (3.x)](#redis-version-3-2-10-scheduled-eol)
+ [Versions dont la fin de vie (EOL) est passée (2.x)](#redis-version-2-x-eol)
### ElastiCache version 7.1 pour Redis OSS (améliorée)
Cette version contient des améliorations de performances qui permettent aux charges de travail d'augmenter le débit et de réduire les latences opérationnelles. ElastiCache la version 7.1 pour Redis OSS introduit [deux améliorations principales](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/) :
Nous avons étendu la fonctionnalité améliorée I/O des threads pour également gérer la logique de la couche de présentation. Par couche de présentation, nous entendons les threads d'E/S améliorés qui non seulement lisent les entrées du client, mais les analysent également au format de commande binaire Redis OSS. Elles sont ensuite transférées au thread principal pour exécution, ce qui permet un gain de performance. Modèle d'accès à la mémoire Redis OSS amélioré. Les étapes d’exécution de nombreuses opérations de structure de données sont entrelacées afin de garantir un accès parallèle à la mémoire et de réduire la latence d’accès à la mémoire. Lorsqu'ils utilisent un système basé ElastiCache sur Graviton3 `R7g.4xlarge` ou une version supérieure, les clients peuvent traiter plus d'un million de requêtes par seconde et par nœud. Grâce aux améliorations de performances apportées à ElastiCache Redis OSS v7.1, les clients peuvent obtenir jusqu'à 100 % de débit en plus et 50 % de latence P99 en moins par rapport à ElastiCache Redis OSS v7.0. Ces améliorations sont activées sur les nœuds dotés d’au moins 8 cœurs physiques (`2xlarge` sur Graviton et `4xlarge` sur x86), quel que soit le type de CPU, et ne nécessitent aucune modification du client.
**Note**
ElastiCache v7.1 est compatible avec Redis OSS v7.0.
### ElastiCache version 7.0 pour Redis OSS (améliorée)
ElastiCache pour Redis OSS 7.0 ajoute un certain nombre d'améliorations et prend en charge de nouvelles fonctionnalités :
+ [Fonctions](https://valkey.io/topics/functions-intro/) : ElastiCache pour Redis OSS, 7 ajoute la prise en charge des fonctions Redis OSS et fournit une expérience gérée permettant aux développeurs d'exécuter des [scripts LUA](https://valkey.io/topics/eval-intro/) avec la logique d'application stockée sur le ElastiCache cluster, sans que les clients n'aient à renvoyer les scripts au serveur à chaque connexion.
+ [Améliorations de l'ACL](https://valkey.io/topics/acl/) : Valkey et Redis OSS 7 ajoutent le support pour la prochaine version des listes de contrôle d'accès ()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.
+ [Sharded Pub/Sub](https://valkey.io/topics/pubsub/) : ElastiCache pour Valkey et Redis, OSS 7 ajoute la prise en charge des Pub/Sub functionality in a sharded way when running ElastiCache in Cluster Mode Enabled (CME). Pub/Sub fonctionnalités permettant 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é.
+ I/O Multiplexage amélioré : ElastiCache pour Valkey et Redis, OSS 7 introduit un multiplexage d'E/S amélioré, qui fournit un débit accru et une latence réduite 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 pour Redis OSS. ElastiCache
Pour plus d'informations sur Valkey, voir [Valkey](https://valkey.io/). Pour plus d'informations sur la version 7.0 de Redis OSS, consultez les [notes de mise à jour de Redis OSS 7.0](https://github.com/redis/redis/blob/7.0/00-RELEASENOTES) sur Redis OSS on. GitHub
### ElastiCache version 6.2 pour Redis OSS (améliorée)
ElastiCache pour Redis OSS 6.2 inclut des améliorations de performances pour les clusters compatibles TLS utilisant des types de nœuds x86 avec 8 V CPUs ou plus ou des types de nœuds Graviton2 avec 4 V ou plus. CPUs Ces améliorations améliorent le débit et réduisent le temps d'établissement de la connexion client en transférant le chiffrement vers d'autres versions. CPUs Avec Redis OSS 6.2, vous pouvez également gérer l'accès aux canaux Pub/Sub avec des règles de liste de contrôle d'accès (ACL).
Avec cette version, nous introduisons également la prise en charge de la hiérarchisation des données sur les nœuds de cluster contenant un NVMe SSD connecté localement. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
La version 6.2.6 du moteur Redis OSS intègre également la prise en charge du format natif JSON ( JavaScript Object Notation), un moyen simple et sans schéma d'encoder des ensembles de données complexes dans des clusters Redis OSS. Grâce au support JSON, vous pouvez tirer parti des performances et de Redis OSS APIs pour les applications qui fonctionnent via JSON. Pour plus d'informations, consultez [Mise en route avec JSON](json-gs.md). Sont également incluses les métriques liées au JSON `JsonBasedCmds` et`JsonBasedCmdsLatency`, qui sont intégrées CloudWatch pour surveiller l'utilisation de ce type de données. Pour de plus amples informations, veuillez consulter [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md).
Vous spécifiez la version du moteur à l'aide de la version 6.2. ElastiCache invoquera automatiquement la version de correctif préférée de Redis OSS 6.2 disponible. Par exemple, lorsque vous créez/modifiez un cluster, vous définissez le `--engine-version` paramètre sur 6.2. Le cluster sera lancé avec la version de correctif préférée actuellement disponible de Redis OSS 6.2 à ce creation/modification moment-là. Si vous spécifiez la version 6.x du moteur dans l'API, vous obtiendrez la dernière version mineure de Redis OSS 6.
Pour les clusters 6.0 existants, vous pouvez opter pour la prochaine mise à niveau automatique de la version mineure en définissant le `AutoMinorVersionUpgrade` paramètre sur `yes` dans le `CreateCacheCluster``ModifyCacheCluster`, `CreateReplicationGroup` ou `ModifyReplicationGroup` APIs. ElastiCache mettra à niveau la version mineure de vos clusters 6.0 existants vers la version 6.2 à l'aide de mises à jour en libre-service. Pour plus d'informations, consultez la section [Mises à jour en libre-service sur Amazon ElastiCache](Self-Service-Updates.md).
Lors de l'appel de l' DescribeCacheEngineVersions API, la valeur du `EngineVersion` paramètre sera définie sur 6.2 et la version réelle du moteur avec la version du correctif sera renvoyée dans le `CacheEngineVersionDescription` champ.
Pour plus d'informations sur la version 6.2 de Redis OSS, consultez les [notes de mise à jour de Redis OSS 6.2](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES) sur Redis OSS on. GitHub
### ElastiCache version 6.0 pour Redis OSS (améliorée)
Amazon ElastiCache présente la prochaine version du ElastiCache moteur Redis OSS, qui inclut l'[authentification des utilisateurs grâce au contrôle d'accès basé sur les rôles](Clusters.RBAC.md), la mise en cache côté client et des améliorations opérationnelles significatives.
À partir de Redis OSS 6.0, nous ElastiCache proposerons une version unique pour chaque version mineure de Redis OSS, au lieu de proposer plusieurs versions de correctif. ElastiCache gérera automatiquement la version du correctif de vos clusters en cours d'exécution, garantissant ainsi de meilleures performances et une sécurité renforcée.
Vous pouvez également opter pour la prochaine mise à niveau automatique de la version mineure en définissant le `AutoMinorVersionUpgrade` paramètre sur `yes` et vous ElastiCache gérerez la mise à niveau de la version mineure par le biais de mises à jour en libre-service. Pour de plus amples informations, veuillez consulter [Mises à jour du service dans ElastiCache](Self-Service-Updates.md).
Vous spécifiez la version du moteur en utilisant`6.0`. ElastiCache invoquera automatiquement la version de correctif préférée de Redis OSS 6.0 disponible. Par exemple, lorsque vous êtes create/modify un cluster, vous définissez le `--engine-version` paramètre sur 6.0. Le cluster sera lancé avec la version de correctif préférée actuellement disponible de Redis OSS 6.0 au moment de la création/modification. Toute demande avec une valeur de version de correctif spécifique sera rejetée, une exception sera levée et le processus échouera.
Lors de l'appel de l' DescribeCacheEngineVersions API, la valeur du `EngineVersion` paramètre sera définie sur 6.0 et la version réelle du moteur avec la version du correctif sera renvoyée dans le `CacheEngineVersionDescription` champ.
Pour plus d'informations sur la version 6.0 de Redis OSS, consultez les [notes de mise à jour de Redis OSS 6.0](https://github.com/redis/redis/blob/6.0/00-RELEASENOTES) sur Redis OSS on. GitHub
### ElastiCache version 5.0.6 pour Redis OSS (améliorée)
Amazon ElastiCache présente la prochaine version du ElastiCache moteur Redis OSS, qui inclut des corrections de bogues et les mises à jour cumulatives suivantes :
+ 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 commandes Redis OSS 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 le logiciel libre Redis 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](ParameterGroups.Engine.md#ParameterGroups.Redis.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](https://kafka.apache.org/documentation/). Pour plus d'informations, consultez [Streams](https://valkey.io/topics/streams-intro).
+ 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](https://valkey.io/commands/#stream).
+ Plusieurs paramètres nouveaux et renommés. Pour de plus amples informations, veuillez consulter [Modifications des paramètres de Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Une nouvelle métrique Redis OSS,`StreamBasedCmds`.
+ Temps de capture légèrement plus rapide pour les nœuds Redis OSS.
**Important**
ElastiCache a rétroporté deux corrections de bogues critiques depuis la [version open source 5.0.1 de Redis OSS](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES). Elles sont répertoriées ci-dessous.
Réponse incohérente de RESTORE lorsque certaines clés ont déjà expiré.
La commande `XCLAIM` peut éventuellement renvoyer une entrée incorrecte ou désynchroniser le protocole.
Ces deux corrections de bogues sont incluses dans le support de Redis OSS ElastiCache pour la version 5.0.0 du moteur Redis OSS et seront prises en compte dans les futures mises à jour de version.
Pour plus d'informations, consultez les [notes de mise à jour de Redis OSS 5.0.6](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) sur Redis OSS on. GitHub
### ElastiCache version 5.0.5 pour Redis OSS (obsolète, utilisez la version 5.0.6)
Amazon ElastiCache présente la prochaine version de ElastiCache pour le moteur Redis OSS ;. Il inclut les modifications de configuration en ligne pour les clusters ElastiCache de basculement automatique au cours de toutes les opérations planifiées. Vous pouvez désormais faire évoluer votre cluster, mettre à niveau la version du moteur Redis OSS et appliquer des correctifs et des mises à jour de maintenance pendant que le cluster reste en ligne et continue de traiter les demandes entrantes. Elle inclut également des correctifs de bogue.
Pour plus d'informations, consultez les [notes de mise à jour de Redis OSS 5.0.5](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) sur Redis OSS on. GitHub
### ElastiCache version 5.0.4 pour Redis OSS (obsolète, utilisez la version 5.0.6)
Amazon ElastiCache présente la prochaine version du moteur Redis OSS prise en charge par ElastiCache. Elle inclut les améliorations suivantes :
+ 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`
Pour plus d'informations, consultez les [notes de mise à jour de Redis OSS 5.0.4](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) sur Redis OSS on. GitHub
### ElastiCache version 5.0.3 pour Redis OSS (obsolète, utilisez la version 5.0.6)
Amazon ElastiCache présente la prochaine version du ElastiCache moteur Redis OSS, qui inclut des corrections de bogues.
### ElastiCache version 5.0.0 pour Redis OSS (obsolète, utilisez la version 5.0.6)
Amazon ElastiCache présente la prochaine version majeure de ElastiCache pour le moteur Redis OSS. ElastiCache la version 5.0.0 pour Redis OSS prend en charge les améliorations suivantes :
+ 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](https://kafka.apache.org/documentation/). Pour plus d'informations, consultez [Streams](https://valkey.io/topics/streams-intro).
+ 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](https://valkey.io/commands/#stream).
+ Plusieurs paramètres nouveaux et renommés. Pour de plus amples informations, veuillez consulter [Modifications des paramètres de Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Une nouvelle métrique Redis OSS,`StreamBasedCmds`.
+ Temps de capture légèrement plus rapide pour les nœuds Redis OSS.
### ElastiCache version 4.0.10 pour Redis OSS (améliorée)
Amazon ElastiCache présente la prochaine version majeure de ElastiCache pour le moteur Redis OSS. ElastiCache la version 4.0.10 pour Redis OSS prend en charge les améliorations suivantes :
+ Le redimensionnement du cluster en ligne et le chiffrement en une seule ElastiCache version. Pour plus d’informations, consultez les ressources suivantes :
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md)
+ [Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Sécurité des données sur Amazon ElastiCache](encryption.md)
+ Plusieurs nouveaux paramètres. Pour de plus amples informations, veuillez consulter [Modifications des paramètres de Redis OSS 4.0.10](ParameterGroups.Engine.md#ParameterGroups.Redis.4-0-10).
+ Prise en charge des familles de commandes de mémoire, comme `MEMORY`. Pour plus d'informations, voir [Commandes](https://valkey.io/commands) (recherche dans MEMO).
+ 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 pour Redis OSS prend en charge des commandes telles que`UNLINK`, `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 métrique Redis OSS,`ActiveDefragHits`. Pour plus d'informations, consultez [Metrics for Redis OSS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CacheMetrics.Redis.html).
Les utilisateurs de Redis OSS (mode cluster désactivé) exécutant la ElastiCache version 3.2.10 pour Redis OSS peuvent utiliser la console pour mettre à niveau leurs clusters via une mise à niveau en ligne.
**Comparaison ElastiCache du redimensionnement des clusters et de la prise en charge du chiffrement**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/engine-versions.html)
### Versions dont la fin de vie (EOL) est passée (3.x)
#### ElastiCache version 3.2.10 pour Redis OSS (améliorée)
Amazon ElastiCache présente la prochaine version majeure de ElastiCache pour le moteur Redis OSS. ElastiCache la version 3.2.10 pour Redis OSS (améliorée) introduit le redimensionnement du cluster en ligne pour ajouter ou supprimer des fragments du cluster tout en continuant à traiter les demandes entrantes. I/O ElastiCache pour Redis OSS 3.2.10, les utilisateurs disposent de toutes les fonctionnalités des versions antérieures de Redis OSS, à l'exception de la possibilité de chiffrer leurs données. Cette fonctionnalité est actuellement disponible pour la version 3.2.6 uniquement.
**Comparaison des ElastiCache versions 3.2.6 et 3.2.10 pour Redis OSS**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/engine-versions.html)
Pour plus d’informations, consultez les ressources suivantes :
+ [Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Redimensionnement de cluster en ligne](best-practices-online-resharding.md)
#### ElastiCache version 3.2.6 pour Redis OSS (améliorée)
Amazon ElastiCache présente la prochaine version majeure de ElastiCache pour le moteur Redis OSS. ElastiCache version 3.2.6 pour les utilisateurs de Redis OSS ont accès à toutes les fonctionnalités des versions antérieures de Redis OSS, ainsi qu'à la possibilité de chiffrer leurs données. Pour plus d’informations, consultez les ressources suivantes :
+ [ElastiCache chiffrement en transit (TLS)](in-transit-encryption.md)
+ [Chiffrement au repos dans ElastiCache](at-rest-encryption.md)
+ [Validation de conformité pour Amazon ElastiCache](elasticache-compliance.md)
#### ElastiCache version 3.2.4 pour Redis OSS (améliorée)
ElastiCache La version 3.2.4 d'Amazon introduit la prochaine version majeure de ElastiCache pour le moteur Redis OSS. ElastiCache 3.2.4 Les utilisateurs disposent de toutes les fonctionnalités des versions antérieures de Redis OSS, ainsi que de la possibilité d'exécuter en *mode cluster ou en mode* *hors* cluster. Le tableau suivant résume les possibilités.
**Comparaison du mode hors cluster et du mode cluster de Redis OSS 3.2.4**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/engine-versions.html)
**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 des [commandes Redis OSS GEO\$1 Commandes : GEO](http://valkey.io/commands#geo) sur la page des commandes Valkey (filtrée pour GEO).
Pour plus d'informations sur les fonctionnalités supplémentaires de Redis OSS 3, consultez les notes de version de [Redis OSS 3.2 et les notes de version](https://github.com/redis/redis/blob/3.2/00-RELEASENOTES) de [Redis OSS 3.0](https://github.com/redis/redis/blob/3.0/00-RELEASENOTES).
Valkey ou Redis OSS actuellement ElastiCache géré (mode cluster activé) ne prend pas en charge les fonctionnalités Redis OSS 3.2 suivantes :
+ Migration de réplica
+ Rééquilibrage du cluster
+ Débogueur LUA
ElastiCache désactive les commandes de gestion Redis OSS 3.2 suivantes :
+ `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`
Pour plus d'informations sur les paramètres de Redis OSS 3.2.4, consultez. [Modifications des paramètres de Redis OSS 3.2.4](ParameterGroups.Engine.md#ParameterGroups.Redis.3-2-4)
### Versions dont la fin de vie (EOL) est passée (2.x)
#### ElastiCache version 2.8.24 pour Redis OSS (améliorée)
Les améliorations apportées à Redis OSS depuis la version 2.8.23 incluent des corrections de bogues et l'enregistrement des mauvaises adresses d'accès à la mémoire. Pour plus d'informations, consultez les [notes de mise à jour de Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache version 2.8.23 pour Redis OSS (améliorée)
Les améliorations apportées à Redis OSS depuis la version 2.8.22 incluent des corrections de bogues. Pour plus d'informations, consultez les [notes de mise à jour de Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). Cette version comprend également la prise en charge du nouveau paramètre `close-on-slave-write` qui, s'il est activé, déconnecte les clients qui tentent d'écrire sur un réplica en lecture seule.
Pour plus d'informations sur les paramètres de Redis OSS 2.8.23, consultez le guide de [Paramètres ajoutés à Redis OSS 2.8.23 (amélioré)](ParameterGroups.Engine.md#ParameterGroups.Redis.2-8-23) l' ElastiCache utilisateur.
#### ElastiCache version 2.8.22 pour Redis OSS (améliorée)
Les améliorations apportées à Redis OSS depuis la version 2.8.21 sont les suivantes :
+ 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](Replication.Redis.Versions.md). 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](CacheMetrics.md).
+ Plusieurs correctifs de bogues essentiels dans le comportement de réplication PSYNC. Pour plus d'informations, consultez les [notes de mise à jour de Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
+ 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 de configuration Redis OSS 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. Ces situations sont plus susceptibles de se produire pour les clients PUBSUB.
#### ElastiCache version 2.8.21 pour Redis OSS
Les améliorations apportées à Redis OSS depuis la version 2.8.19 incluent un certain nombre de corrections de bogues. Pour plus d'informations, consultez les [notes de mise à jour de Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache version 2.8.19 pour Redis OSS
Les améliorations apportées à Redis OSS depuis la version 2.8.6 sont les suivantes :
+ Support pour HyperLogLog. Pour plus d'informations, consultez la [nouvelle structure de données de Redis OSS : HyperLogLog](http://antirez.com/news/75).
+ 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 éviter qu'un nœud principal envoie des données obsolètes aux nœuds de réplica, la synchronisation principale échoue si un processus enfant (`bgsave`) d'enregistrement en arrière-plan est interrompu.
+ Support pour la *HyperLogLogBasedCommands* CloudWatchmétrique. Pour de plus amples informations, veuillez consulter [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md).
#### ElastiCache version 2.8.6 pour Redis OSS
Les améliorations apportées à Redis OSS depuis la version 2.6.13 sont les suivantes :
+ 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.
#### ElastiCache version 2.6.13 pour Redis OSS
ElastiCache la version 2.6.13 pour Redis OSS était la version initiale supportée par Redis OSS. ElastiCache Le multi-AZ n'est pas pris en charge dans la ElastiCache version 2.6.13 pour Redis OSS.
## ElastiCache versions pour le calendrier de fin de vie de Redis OSS
Cette section définit les dates de fin de vie (EOL) pour les anciennes versions majeures au fur et à mesure qu'elles sont annoncées. Cela vous permet de prendre des décisions concernant les versions et les mises à niveau pour l'avenir.
**Note**
ElastiCache les versions 5.0.0 à 5.0.5 pour Redis OSS sont obsolètes. Utilisez les versions 5.0.6 ou ultérieures.
Le tableau suivant présente le calendrier du [Support étendu](extended-support.md) ElastiCache pour les moteurs Redis OSS.
**Support étendu et calendrier de fin de vie**
| Version principale du moteur | Support standard terminé | Début du Support étendu Y1 Premium | Début du Support étendu Y2 Premium | Début du Support étendu Y3 Premium | Fin du support étendu et de la version EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31/01/2026 | 01/02/2026 | 01/02/2027 | 01/02/2028 | 31/01/2029 |
| Redis OSS v5 | 31/01/2026 | 01/02/2026 | 01/02/2027 | 01/02/2028 | 31/01/2029 |
| Redis OSS 6 | 31/01/2027 | 01/02/2027 | 01/02/2028 | 01/02/2029 | 31/01/2030 |
Le tableau suivant récapitule chaque version et sa date EOL annoncée, ainsi que la version cible de mise à niveau recommandée.
**EOL passée**
| Version majeure de la source | Versions mineures de la source | Cible de mise à niveau recommandée | Date EOL |
| --- | --- | --- | --- |
| Version 3 | 3.2.4, 3.2.6 et 3.2.10 | Version 6.2 ou supérieure Pour les régions US-ISO-EAST US-ISO-WEST -1, -1 et US-ISOB-EAST -1, nous recommandons la version 5.0.6 ou supérieure. | 31 juillet 2023 |
| Version 2 | 2,8,24, 2,8,23, 2,8,22, 2,8,21, 2.8,19, 2.8,12, 2,8.6, 2.6,13 | Version 6.2 ou supérieure Pour les régions US-ISO-EAST US-ISO-WEST -1, -1 et US-ISOB-EAST -1, nous recommandons la version 5.0.6 ou supérieure. | 13 janvier 2023 |
## Pris en charge ElastiCache pour les versions de Memcached
ElastiCache prend en charge les versions suivantes de Memcached et la mise à niveau vers des versions plus récentes. Dans ce dernier cas, faites attention aux conditions qui causeront l'échec de la mise à niveau si elles ne sont pas remplies.
**Topics**
+ [ElastiCache version 1.6.22 pour Memcached](#memcached-version-1-6-22)
+ [ElastiCache version 1.6.17 pour Memcached](#memcached-version-1-6-17)
+ [ElastiCache version 1.6.12 pour Memcached](#memcached-version-1-6-12)
+ [ElastiCache version 1.6.6 pour Memcached](#memcached-version-1-6-6)
+ [ElastiCache version 1.5.16 pour Memcached](#memcached-version-1-5-16)
+ [ElastiCache version 1.5.10 pour Memcached](#memcached-version-1-5-10)
+ [ElastiCache version 1.4.34 pour Memcached](#memcached-version-1-4-34)
+ [ElastiCache version 1.4.33 pour Memcached](#memcached-version-1-4-33)
+ [ElastiCache version 1.4.24 pour Memcached](#memcached-version-1-4-24)
+ [ElastiCache version 1.4.14 pour Memcached](#memcached-version-1-4-14)
+ [ElastiCache version 1.4.5 pour Memcached](#memcached-version-1-4-5)
### ElastiCache version 1.6.22 pour Memcached
ElastiCache pour Memcached version 1.6.22 pour Memcached ajoute le support pour Memcached version 1.6.22. Il n’inclut aucune nouvelle fonctionnalité, mais offre des correctifs de bogue et des mises à jour cumulatives à partir de [Memcached 1.6.18](https://github.com/memcached/memcached/wiki/ReleaseNotes1618).
Pour plus d'informations, consultez [ReleaseNotes1622](https://github.com/memcached/memcached/wiki/ReleaseNotes1622) sur Memcached on. GitHub
### ElastiCache version 1.6.17 pour Memcached
ElastiCache pour Memcached version 1.6.17 pour Memcached ajoute le support pour le moteur Memcached version 1.6.17. Il n’inclut aucune nouvelle fonctionnalité, mais offre des correctifs de bogue et des mises à jour cumulatives à partir de [Memcached 1.6.17](https://github.com/memcached/memcached/wiki/ReleaseNotes1617).
Pour plus d'informations, consultez [ReleaseNotes1617](https://github.com/memcached/memcached/wiki/ReleaseNotes1617) sur Memcached on. GitHub
### ElastiCache version 1.6.12 pour Memcached
ElastiCache pour Memcached, la version 1.6.12 pour Memcached ajoute la prise en charge du moteur Memcached 1.6.12 et du chiffrement en transit. Il inclut également les correctifs de bogue et les mises à jour cumulatives de [Memcached 1.6.6](https://github.com/memcached/memcached/wiki/ReleaseNotes166).
Pour plus d'informations, consultez [ReleaseNotes1612](https://github.com/memcached/memcached/wiki/ReleaseNotes1612) sur Memcached on. GitHub
### ElastiCache version 1.6.6 pour Memcached
ElastiCache pour Memcached version 1.6.6 pour Memcached ajoute le support pour Memcached version 1.6.6. Il n'inclut aucune nouvelle fonctionnalité, mais inclut des corrections de bogues et des mises à jour cumulatives depuis [Memcached](https://github.com/memcached/memcached/wiki/ReleaseNotes1.5.16) 1.5.16. ElastiCache [pour Memcached n'inclut pas le support pour Extstore.](https://memcached.org/extstore)
Pour plus d'informations, consultez [ReleaseNotes166](https://github.com/memcached/memcached/wiki/ReleaseNotes166) sur Memcached on. GitHub
### ElastiCache version 1.5.16 pour Memcached
ElastiCache la version 1.5.16 pour Memcached ajoute le support pour la version 1.5.16 de Memcached. Sans aucune nouvelle fonctionnalité, il inclut des correctifs de bogue et des mises à jour cumulatives à partir des versions [Memcached 1.5.14](https://github.com/memcached/memcached/wiki/ReleaseNotes1514) et [Memcached 1.5.15](https://github.com/memcached/memcached/wiki/ReleaseNotes1515).
Pour plus d'informations, consultez les [notes de mise à jour de Memcached 1.5.16](https://github.com/memcached/memcached/wiki/ReleaseNotes1516) sur Memcached on. GitHub
### ElastiCache version 1.5.10 pour Memcached
ElastiCache la version 1.5.10 pour Memcached prend en charge les fonctionnalités suivantes de Memcached :
+ Rééquilibrage de section automatisé.
+ Recherches plus rapides dans les tables de hachage avec l'algorithme `murmur3`.
+ Algorithme LRU segmenté.
+ Crawler LRU pour la récupération de mémoire d'arrière-plan
+ `--enable-seccomp` : option pour la compilation.
Elle introduit aussi les paramètres `no_modern` et `inline_ascii_resp`. Pour de plus amples informations, veuillez consulter [Modifications des paramètres Memcached 1.5.10](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-5-10).
Les améliorations apportées à Memcached depuis la ElastiCache version 1.4.34 pour Memcached sont les suivantes :
+ Correctifs cumulés, par exemple opérations de lecture multiples ASCII, CVE-2017-9951 et analyses des limites 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.
Pour plus d'informations, consultez les [notes de mise à jour de Memcached 1.5.10 sur](https://github.com/memcached/memcached/wiki/ReleaseNotes1510) Memcached on. GitHub
### ElastiCache version 1.4.34 pour Memcached
ElastiCache la version 1.4.34 pour Memcached n'ajoute aucune nouvelle fonctionnalité à la version 1.4.33. La version 1.4.34 est une version de correctifs qui est plus volumineuse que les versions habituelles de ce type.
Pour plus d'informations, consultez les [notes de mise à jour de Memcached 1.4.34](https://github.com/memcached/memcached/wiki/ReleaseNotes1434) sur Memcached on. GitHub
### ElastiCache version 1.4.33 pour Memcached
Les améliorations ajoutées depuis la version 1.4.24 sont les suivantes :
+ 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](https://github.com/memcached/memcached/wiki/ReleaseNotes1431).
+ 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](https://github.com/memcached/memcached/wiki/ReleaseNotes1429).
+ 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](https://github.com/memcached/memcached/wiki/ReleaseNotes1427).
+ 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](https://github.com/memcached/memcached/wiki/ReleaseNotes1426).
+ 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](https://github.com/memcached/memcached/wiki/ReleaseNotes1425).
+ 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](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-33).
### ElastiCache version 1.4.24 pour Memcached
Les améliorations ajoutées depuis la version 1.4.14 sont les suivantes :
+ Une gestion de type LRU (Last Recently Used, moins récemment utilisé) à l'aide d'un processus d'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](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-24).
+ Plusieurs corrections de bugs.
### ElastiCache version 1.4.14 pour Memcached
Les améliorations apportées depuis la version 1.4.5 sont les suivantes :
+ 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.
### ElastiCache version 1.4.5 pour Memcached
ElastiCache la version 1.4.5 pour Memcached était le moteur initial et la version pris en charge par Amazon ElastiCache pour Memcached.
# Principales différences de comportement entre les versions du moteur et de compatibilité avec Valkey
Valkey 7.2.6 présente des différences de compatibilité similaires avec les versions précédentes de Redis OSS 7.2.4. Pour la dernière version prise en charge de Valkey, consultez[Moteurs et versions pris en charge](VersionManagement.md#supported-engine-versions).
Pour plus d'informations sur la version 7.2 de Valkey, consultez les [notes de mise à jour de Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (Valkey 7.2 inclut toutes les modifications depuis Redis OSS jusqu'à la version 7.2.4) et les notes de version de Valkey 7.2 sur [Valkey](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) on. GitHub
Voici les changements de comportement potentiellement perturbants entre Valkey 7.2 et Redis OSS 7.1 (ou 7.0) :
+ L'échantillonnage pendant le temps de gel a lieu lors de l'exécution des commandes et dans les scripts.
+ Une commande de diffusion bloquée lancée lorsque la clé n'existe plus contient un code d'erreur différent (-NOGROUP ou -WRONGTYPE au lieu de -UNBLOCKED).
+ 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 de EVAL/FCALL.
# Principales différences de comportement entre les versions du moteur et de compatibilité avec Redis OSS
**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 Redis OSS sont identifiées par une version sémantique qui comprend un composant majeur, un composant mineur et un composant correctif. 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 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 aux corrections de bogues rétrocompatibles et aux modifications non fonctionnelles
Nous vous recommandons de toujours utiliser la dernière version du correctif au sein d'une version **majeure .minor** donnée afin de bénéficier des dernières améliorations de performances et de stabilité. À partir de ElastiCache la version 6.0 pour Redis OSS, nous ElastiCache proposerons une version unique pour chaque version mineure de Redis OSS plutôt que de proposer plusieurs versions de correctif. ElastiCachegérera automatiquement la version du correctif de vos clusters 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 **majeures .minor** les plus récentes à l'époque pour la nouvelle région. ****Par exemple, si une nouvelle AWS région est lancée et que les dernières ElastiCache versions majeures de .minor pour Redis OSS sont **7.0 et 6.2, les versions 7.0** **et 6.2** de Redis OSS ElastiCache seront prises en charge dans la nouvelle région.****AWS Au fur et à mesure que les nouvelles versions majeures .minor de ElastiCache pour Redis OSS seront publiées, ElastiCache nous continuerons à ajouter le support pour les nouvelles versions. Pour en savoir plus sur le choix des régions pour ElastiCache, consultez la section [Choix des régions et des zones de disponibilité](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html#SupportedRegions).
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](https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES).
+ `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](https://valkey.io/topics/functions-intro/).
+ 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](https://raw.githubusercontent.com/redis/redis/6.2/00-RELEASENOTES).
+ 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 key/value paires 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](https://raw.githubusercontent.com/redis/redis/6.0/00-RELEASENOTES).
+ 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](Self-Service-Updates.md).
## 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](https://raw.githubusercontent.com/redis/redis/5.0/00-RELEASENOTES).
+ 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 ?](CacheMetrics.WhichShouldIMonitor.md) 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](https://raw.githubusercontent.com/redis/redis/4.0/00-RELEASENOTES).
+ 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](https://raw.githubusercontent.com/redis/redis/3.2/00-RELEASENOTES).
+ Il n'y a pas de modifications de compatibilité à signaler pour cette version.
Pour de plus amples informations, veuillez consulter [ElastiCache versions pour le calendrier de fin de vie de Redis OSS](engine-versions.md#deprecated-engine-versions).
### 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](https://raw.githubusercontent.com/redis/redis/2.8/00-RELEASENOTES).
+ À 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.
Pour de plus amples informations, veuillez consulter [ElastiCache versions pour le calendrier de fin de vie de Redis OSS](engine-versions.md#deprecated-engine-versions).
# Considérations relatives à la mise à niveau lors de l'utilisation de clusters basés sur des nœuds
**Note**
Les considérations suivantes s'appliquent uniquement lors de la mise à niveau de clusters basés sur des nœuds. 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 basé sur des nœuds, 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](BestPractices.Clients.redis.md), avec des tentatives d'erreur et des retards exponentiels, ainsi que les meilleures pratiques pour [minimiser](BestPractices.MinimizeDowntime.md) 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](backups-manual.md).
1. 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 basé sur des nœuds avec une sauvegarde créée en externe](backups-seeding-redis.md).
1. 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](Clusters.Delete.md) ou [Suppression d'un groupe de réplication](Replication.DeletingRepGroup.md).
1. 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 de plus amples informations, consultez [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md).
+ 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](BestPractices.BGSAVE.md) 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**
Lors de la mise à niveau d'un cluster Memcached basé sur des nœuds, 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.
# ElastiCache meilleures pratiques et stratégies de mise en cache
Vous trouverez ci-dessous les meilleures pratiques recommandées pour Amazon ElastiCache. La mise en œuvre de ces bonnes pratiques améliore les performances et la fiabilité de votre cache.
**Topics**
+ [Bonnes pratiques générales](WorkingWithRedis.md)
+ [Bonnes pratiques d'utilisation des répliques de lecture](ReadReplicas.md)
+ [Commandes Valkey, Memcached et Redis OSS prises en charge et restreintes](SupportedCommands.md)
+ [Configuration et limites de Valkey et Redis OSS](RedisConfiguration.md)
+ [IPv6 exemples de clients pour Valkey, Memcached et Redis OSS](network-type-best-practices.md)
+ [Bonnes pratiques pour les clients (Valkey et Redis OSS)](BestPractices.Clients.redis.md)
+ [Bonnes pratiques pour les clients (Memcached)](BestPractices.Clients.memcached.md)
+ [Clusters à double pile ElastiCache compatibles TLS](#network-type-configuring-tls-enabled-dual-stack)
+ [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md)
+ [Meilleures pratiques lors de l'utilisation de clusters basés sur des nœuds Valkey et Redis OSS](BestPractices.SelfDesigned.md)
+ [Stratégies de mise en cache pour Memcached](Strategies.md)
# Bonnes pratiques générales
Vous trouverez ci-dessous des informations sur les meilleures pratiques relatives à l'utilisation des interfaces Valkey, Memcached et Redis OSS dans ce cadre. ElastiCache
+ **Utiliser des configurations activées en mode cluster : le mode cluster activé** permet au cache de s'adapter horizontalement pour obtenir un stockage et un débit supérieurs à ceux d'une configuration désactivée en mode cluster. ElastiCache le mode serverless n'est disponible que dans une configuration activée en mode cluster.
+ **Utilisez des connexions longue durée** : la création d’une connexion est coûteuse et nécessite du temps et des ressources de CPU provenant du cache. Réutilisez les connexions dans la mesure du possible (en regroupant les connexions, par exemple) pour amortir ce coût sur de nombreuses commandes.
+ **Lecture à partir de répliques** : si vous utilisez des répliques ElastiCache sans serveur ou si vous avez provisionné des répliques de lecture (clusters basés sur des nœuds), effectuez des lectures directes vers des répliques pour obtenir une meilleure évolutivité et réduire la latence. and/or Les lectures de réplicas sont cohérentes avec le nœud primaire à terme.
Dans un cluster basé sur un nœud, évitez de diriger les demandes de lecture vers une seule réplique de lecture, car les lectures peuvent ne pas être disponibles temporairement en cas de défaillance du nœud. Configurez votre client pour qu’il dirige les demandes de lecture vers au moins deux réplicas en lecture, ou qu’il dirige les lectures vers un seul réplica et le nœud primaire.
En mode ElastiCache sans serveur, la lecture depuis le port de réplication (6380) dirige les lectures vers la zone de disponibilité locale du client lorsque cela est possible, réduisant ainsi le temps de latence de récupération. Il retombera automatiquement sur les autres nœuds en cas de défaillance.
+ **Évitez les commandes coûteuses** : évitez d'exécuter des opérations de calcul I/O intensives, telles que les commandes `KEYS` et`SMEMBERS`. Nous suggérons cette approche, car ces opérations augmentent la charge sur le cluster et ont un impact sur ses performances. Utilisez à la place les commandes `SCAN` et `SSCAN`.
+ **Suivez les bonnes pratiques Lua** – Évitez les longues exécutions de scripts Lua et déclarez toujours les clés utilisées dans les scripts Lua en amont. Nous recommandons cette approche pour déterminer que le script Lua n'utilise pas de commandes inter-emplacements. Veillez à ce que les clés utilisées dans les scripts Lua appartiennent au même emplacement.
+ **Utiliser un pub/sub** fragmenté : lorsque vous utilisez Valkey ou Redis OSS pour prendre en charge des pub/sub charges de travail à haut débit, nous vous recommandons d'utiliser un [pub/sub fragmenté (disponible avec Valkey et](https://valkey.io/topics/pubsub/) avec Redis OSS 7 ou version ultérieure). Les clusters traditionnels activés pub/sub en mode cluster diffusent des messages à tous les nœuds du cluster, ce qui peut entraîner une hausse. `EngineCPUUtilization` Notez que dans les pub/sub commands internally use sharded pub/sub commandes traditionnelles ElastiCache sans serveur.
**Topics**
# Bonnes pratiques d'utilisation des répliques de lecture
De nombreuses applications, telles que les magasins de sessions, les classements et les moteurs de recommandation, nécessitent une haute disponibilité et gèrent beaucoup plus d'opérations de lecture que d'opérations d'écriture. Ces applications peuvent souvent tolérer des données légèrement périmées (cohérence éventuelle), ce qui signifie qu'il est acceptable que différents utilisateurs voient momentanément des versions légèrement différentes des mêmes données. Par exemple :
+ Les résultats des requêtes mis en cache peuvent souvent tolérer des données légèrement périmées, en particulier pour les modèles de cache où la source de vérité est externe.
+ Dans un classement de jeu, un retard de quelques secondes dans la mise à jour des scores n'a souvent pas d'impact significatif sur l'expérience utilisateur.
+ Pour les magasins de sessions, certains légers retards dans la propagation des données de session entre les répliques affectent rarement les fonctionnalités de l'application.
+ Les moteurs de recommandation utilisent généralement l'analyse des données historiques, de sorte que la cohérence en temps réel est moins critique.
La cohérence éventuelle signifie que tous les nœuds de réplication renverront les mêmes données une fois le processus de réplication terminé, généralement en quelques millisecondes. Dans de tels cas d'utilisation, la mise en œuvre de répliques de lecture constitue une stratégie efficace pour réduire la latence lors de la lecture depuis votre ElastiCache instance.
L'utilisation de répliques de lecture dans Amazon ElastiCache peut apporter des avantages significatifs en termes de performances grâce à :
**Évolutivité de lecture améliorée**
+ Répartit les opérations de lecture sur plusieurs nœuds de réplication
+ Décharge le trafic de lecture du nœud principal
+ Réduit la latence de lecture en répondant aux demandes provenant de répliques géographiquement plus proches
**Performances optimisées du nœud principal**
+ Dédie les ressources du nœud principal aux opérations d'écriture
+ Réduit les frais de connexion sur le nœud principal
+ Améliore les performances d'écriture et maintient de meilleurs temps de réponse pendant les périodes de pointe
## Utilisation de Read from Replica en mode ElastiCache Serverless
ElastiCache serverless fournit deux points de terminaison différents, pour des exigences de cohérence différentes. Les deux points de terminaison utilisent le même nom DNS mais des ports différents. Pour utiliser le read-from-replica port, vous devez autoriser l'accès aux deux ports depuis votre application cliente en [configurant les groupes de sécurité et les listes de contrôle d'accès réseau de votre VPC](set-up.md#elasticache-install-grant-access-VPN).
**Point de terminaison principal (port 6379)**
+ Utilisation pour les opérations nécessitant une cohérence immédiate
+ Garantit la lecture d'un maximum up-to-date de données
+ Idéal pour les transactions critiques et les opérations d'écriture
+ Nécessaire pour les opérations d'écriture
+ Exemple : `test-12345.serverless.use1.cache.amazonaws.com:6379`
**Point de terminaison optimisé pour la latence (port 6380)**
+ Optimisé pour les opérations de lecture qui peuvent tolérer une éventuelle cohérence
+ Lorsque cela est possible, le mode ElastiCache sans serveur achemine automatiquement les demandes de lecture vers le nœud de réplication dans la zone de disponibilité locale du client. Cette optimisation permet de réduire la latence en évitant la latence réseau supplémentaire encourue lors de la récupération de données à partir d'un nœud situé dans une autre zone de disponibilité.
+ ElastiCache serverless sélectionne automatiquement les nœuds disponibles dans d'autres zones si un nœud local n'est pas disponible
+ Exemple : `test-12345.serverless.use1.cache.amazonaws.com:6380`
+ Les clients tels que Glide et Lettuce détectent et acheminent automatiquement les lectures vers le point de terminaison optimisé pour la latence si vous fournissez la configuration de lecture depuis une réplique. Si votre client ne prend pas en charge la configuration du routage (par exemple, Valkey-Java et les anciennes versions de Jedis), vous devez définir le port et la configuration client appropriés pour lire les répliques.
## Connexion pour lire des répliques en mode ElastiCache Serverless - Valkey and Glide
L'extrait de code suivant montre comment configurer la lecture depuis une réplique pour ElastiCache Serverless dans la bibliothèque Valkey Glide. Il n'est pas nécessaire de spécifier le port pour la lecture à partir des répliques, mais vous devez configurer la configuration `ReadFrom.PREFER_REPLICA` du routage.
```
package glide.examples;
import glide.api.GlideClusterClient;
import glide.api.logging.Logger;
import glide.api.models.configuration.GlideClusterClientConfiguration;
import glide.api.models.configuration.NodeAddress;
import glide.api.models.exceptions.ClosingException;
import glide.api.models.exceptions.ConnectionException;
import glide.api.models.exceptions.TimeoutException;
import glide.api.models.configuration.ReadFrom;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutionException;
public class ClusterExample {
public static void main(String[] args) {
// Set logger configuration
Logger.setLoggerConfig(Logger.Level.INFO);
GlideClusterClient client = null;
try {
System.out.println("Connecting to Valkey Glide...");
// Configure the Glide Client
GlideClusterClientConfiguration config = GlideClusterClientConfiguration.builder()
.address(NodeAddress.builder()
.host("your-endpoint")
.port(6379)
.build())
.useTLS(true)
.readFrom(ReadFrom.PREFER_REPLICA)
.build();
// Create the GlideClusterClient
client = GlideClusterClient.createClient(config).get();
System.out.println("Connected successfully.");
// Perform SET operation
CompletableFuture setResponse = client.set("key", "value");
System.out.println("Set key 'key' to 'value': " + setResponse.get());
// Perform GET operation
CompletableFuture getResponse = client.get("key");
System.out.println("Get response for 'key': " + getResponse.get());
// Perform PING operation
CompletableFuture pingResponse = client.ping();
System.out.println("PING response: " + pingResponse.get());
} catch (ClosingException | ConnectionException | TimeoutException | ExecutionException e) {
System.err.println("An exception occurred: ");
e.printStackTrace();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
// Close the client connection
if (client != null) {
try {
client.close();
System.out.println("Client connection closed.");
} catch (ClosingException | ExecutionException e) {
System.err.println("Error closing client: " + e.getMessage());
}
}
}
}
}
```
# Commandes Valkey, Memcached et Redis OSS prises en charge et restreintes
## Commandes Valkey et Redis OSS prises en charge
**Commandes Valkey et Redis OSS prises en charge**
Les commandes Valkey et Redis OSS suivantes sont prises en charge par les caches sans serveur. Outre ces commandes, les commandes répertoriées à la rubrique [Commandes Valkey et Redis OSS prises en chargeCommandes JSON](json-list-commands.md) sont également prises en charge.
Pour plus d'informations sur les commandes du filtre Bloom, voir [Commandes du filtre Bloom](BloomFilters.md#SupportedCommandsBloom)
**Commandes Bitmap**
+ `BITCOUNT`
Compte le nombre de bits définis (comptage de la population) dans une chaîne.
[En savoir plus](https://valkey.io/commands/bitcount/)
+ `BITFIELD`
Effectue des opérations arbitraires sur des champs de bits entiers dans des chaînes.
[En savoir plus](https://valkey.io/commands/bitfield/)
+ `BITFIELD_RO`
Effectue des opérations arbitraires sur des champs de bits entiers en lecture seule dans des chaînes.
[En savoir plus](https://valkey.io/commands/bitfield_ro/)
+ `BITOP`
Effectue des opérations au niveau du bit sur plusieurs chaînes et stocke le résultat.
[En savoir plus](https://valkey.io/commands/bitop/)
+ `BITPOS`
Recherche le premier bit défini (1) ou effacé (0) dans une chaîne.
[En savoir plus](https://valkey.io/commands/bitpos/)
+ `GETBIT`
Renvoie une valeur de bit par décalage.
[En savoir plus](https://valkey.io/commands/getbit/)
+ `SETBIT`
Définit ou efface le bit décalé par rapport à la valeur de chaîne. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/setbit/)
**Commandes de gestion des clusters**
+ `CLUSTER COUNTKEYSINSLOT`
Renvoie le nombre de clés dans un emplacement de hachage.
[En savoir plus](https://valkey.io/commands/cluster-countkeysinslot/)
+ `CLUSTER GETKEYSINSLOT`
Renvoie les noms de clés dans un emplacement de hachage.
[En savoir plus](https://valkey.io/commands/cluster-getkeysinslot/)
+ `CLUSTER INFO`
Renvoie des informations sur l’état d’un nœud. Dans un cache sans serveur, renvoie l’état de l’unique « partition » virtuelle exposée au client.
[En savoir plus](https://valkey.io/commands/cluster-info/)
+ `CLUSTER KEYSLOT`
Renvoie l’emplacement de hachage d’une clé.
[En savoir plus](https://valkey.io/commands/cluster-keyslot/)
+ `CLUSTER MYID`
Renvoie l’ID d’un nœud. Dans un cache sans serveur, renvoie l’état de l’unique « partition » virtuelle exposée au client.
[En savoir plus](https://valkey.io/commands/cluster-myid/)
+ `CLUSTER NODES`
Renvoie la configuration de cluster d’un nœud. Dans un cache sans serveur, renvoie l’état de l’unique « partition » virtuelle exposée au client.
[En savoir plus](https://valkey.io/commands/cluster-nodes/)
+ `CLUSTER REPLICAS`
Répertorie les nœuds de réplica d’un nœud principal. Dans un cache sans serveur, renvoie l’état de l’unique « partition » virtuelle exposée au client.
[En savoir plus](https://valkey.io/commands/cluster-replicas/)
+ `CLUSTER SHARDS`
Renvoie le mappage des emplacements de cluster aux partitions. Dans un cache sans serveur, renvoie l’état de l’unique « partition » virtuelle exposée au client.
[En savoir plus](https://valkey.io/commands/cluster-shards/)
+ `CLUSTER SLOTS`
Renvoie le mappage des emplacements de cluster aux nœuds. Dans un cache sans serveur, renvoie l’état de l’unique « partition » virtuelle exposée au client.
[En savoir plus](https://valkey.io/commands/cluster-slots/)
+ `CLUSTER SLOT-STATS`
Permet le suivi des métriques par slot pour le nombre de clés, l'utilisation du processeur, les octets réseau entrants et les octets réseau sortants.
[En savoir plus](https://valkey.io/commands/cluster-slot-stats/)
+ `READONLY`
Active les requêtes en lecture seule pour une connexion à un nœud de réplication Valkey ou Redis OSS Cluster.
[En savoir plus](https://valkey.io/commands/readonly/)
+ `READWRITE`
Active les requêtes en lecture-écriture pour une connexion à un nœud de réplication Valkey ou Redis OSS Cluster.
[En savoir plus](https://valkey.io/commands/readwrite/)
+ `SCRIPT SHOW`
Renvoie le code source d'origine d'un script dans le cache de scripts.
[En savoir plus](https://valkey.io/commands/script-show/)
**Commandes de gestion des connexions**
+ `AUTH`
Authentifie la connexion.
[En savoir plus](https://valkey.io/commands/auth/)
+ `CLIENT GETNAME`
Renvoie le nom de la connexion.
[En savoir plus](https://valkey.io/commands/client-getname/)
+ `CLIENT REPLY`
Demande au serveur de répondre ou non aux commandes.
[En savoir plus](https://valkey.io/commands/client-reply/)
+ `CLIENT SETNAME`
Définit le nom de la connexion.
[En savoir plus](https://valkey.io/commands/client-setname/)
+ `ECHO`
Renvoie la chaîne donnée.
[En savoir plus](https://valkey.io/commands/echo/)
+ `HELLO`
Poignées de main avec le serveur Valkey ou Redis OSS.
[En savoir plus](https://valkey.io/commands/hello/)
+ `PING`
Indique si la connexion au serveur est toujours active.
[En savoir plus](https://valkey.io/commands/ping/)
+ `QUIT`
Ferme la connexion.
[En savoir plus](https://valkey.io/commands/quit/)
+ `RESET`
Réinitialise la connexion.
[En savoir plus](https://valkey.io/commands/reset/)
+ `SELECT`
Modifie la base de données sélectionnée.
[En savoir plus](https://valkey.io/commands/select/)
**Commandes génériques**
+ `COPY`
Copie la valeur d’une clé dans une nouvelle clé.
[En savoir plus](https://valkey.io/commands/copy/)
+ `DEL`
Supprime une ou plusieurs clés.
[En savoir plus](https://valkey.io/commands/del/)
+ `DUMP`
Renvoie une représentation sérialisée de la valeur stockée dans une clé.
[En savoir plus](https://valkey.io/commands/dump/)
+ `EXISTS`
Détermine si une ou plusieurs clés existent.
[En savoir plus](https://valkey.io/commands/exists/)
+ `EXPIRE`
Définit le délai d’expiration d’une clé en secondes.
[En savoir plus](https://valkey.io/commands/expire/)
+ `EXPIREAT`
Définit le délai d’expiration d’une clé selon un horodatage Unix.
[En savoir plus](https://valkey.io/commands/expireat/)
+ `EXPIRETIME`
Renvoie le délai d’expiration d’une clé au format d’horodatage Unix.
[En savoir plus](https://valkey.io/commands/expiretime/)
+ `PERSIST`
Supprime le délai d’expiration d’une clé.
[En savoir plus](https://valkey.io/commands/persist/)
+ `PEXPIRE`
Définit le délai d’expiration d’une clé en millisecondes.
[En savoir plus](https://valkey.io/commands/pexpire/)
+ `PEXPIREAT`
Définit le délai d’expiration d’une clé selon un horodatage Unix en millisecondes.
[En savoir plus](https://valkey.io/commands/pexpireat/)
+ `PEXPIRETIME`
Renvoie le délai d’expiration d’une clé au format d’horodatage Unix en millisecondes.
[En savoir plus](https://valkey.io/commands/pexpiretime/)
+ `PTTL`
Renvoie le délai d’expiration d’une clé en millisecondes.
[En savoir plus](https://valkey.io/commands/pttl/)
+ `RANDOMKEY`
Renvoie un nom de clé aléatoire à partir de la base de données.
[En savoir plus](https://valkey.io/commands/randomkey/)
+ `RENAME`
Renomme une clé et remplace la destination.
[En savoir plus](https://valkey.io/commands/rename/)
+ `RENAMENX`
Renomme une clé uniquement lorsque le nom de la clé cible n’existe pas.
[En savoir plus](https://valkey.io/commands/renamenx/)
+ `RESTORE`
Crée une clé à partir de la représentation sérialisée d’une valeur.
[En savoir plus](https://valkey.io/commands/restore/)
+ `SCAN`
Effectue une itération sur les noms de clés de la base de données.
[En savoir plus](https://valkey.io/commands/scan/)
+ `SORT`
Trie les éléments d’une liste, d’un ensemble ou d’un ensemble trié, en stockant éventuellement le résultat.
[En savoir plus](https://valkey.io/commands/sort/)
+ `SORT_RO`
Renvoie les éléments triés d’une liste, d’un ensemble ou d’un ensemble trié.
[En savoir plus](https://valkey.io/commands/sort_ro/)
+ `TOUCH`
Renvoie le nombre de clés existantes parmi celles spécifiées après la mise à jour de l’heure de leur dernier accès.
[En savoir plus](https://valkey.io/commands/touch/)
+ `TTL`
Renvoie le délai d’expiration d’une clé en secondes.
[En savoir plus](https://valkey.io/commands/ttl/)
+ `TYPE`
Détermine le type de valeur stockée dans une clé.
[En savoir plus](https://valkey.io/commands/type/)
+ `UNLINK`
Supprime une ou plusieurs clés de manière asynchrone.
[En savoir plus](https://valkey.io/commands/unlink/)
**Commandes géospatiales**
+ `GEOADD`
Ajoute un ou plusieurs membres à un index géospatial. La clé est créée si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/geoadd/)
+ `GEODIST`
Renvoie la distance entre deux membres d’un index géospatial.
[En savoir plus](https://valkey.io/commands/geodist/)
+ `GEOHASH`
Renvoie les membres d’un index géospatial sous forme de chaînes geohash.
[En savoir plus](https://valkey.io/commands/geohash/)
+ `GEOPOS`
Renvoie la longitude et la latitude des membres à partir d’un index géospatial.
[En savoir plus](https://valkey.io/commands/geopos/)
+ `GEORADIUS`
Recherche dans un index géospatial les membres situés à une certaine distance d’une coordonnée, puis stocke éventuellement le résultat.
[En savoir plus](https://valkey.io/commands/georadius/)
+ `GEORADIUS_RO`
Renvoie les membres d’un index géospatial situés à une certaine distance d’une coordonnée.
[En savoir plus](https://valkey.io/commands/georadius_ro/)
+ `GEORADIUSBYMEMBER`
Recherche dans un index géospatial les membres situés à une certaine distance d’un membre, puis stocke éventuellement le résultat.
[En savoir plus](https://valkey.io/commands/georadiusbymember/)
+ `GEORADIUSBYMEMBER_RO`
Renvoie les membres d’un index géospatial situés à une certaine distance d’un membre.
[En savoir plus](https://valkey.io/commands/georadiusbymember_ro/)
+ `GEOSEARCH`
Recherche dans un index géospatial les membres situés à l’intérieur une zone d’une boîte ou d’un cercle.
[En savoir plus](https://valkey.io/commands/geosearch/)
+ `GEOSEARCHSTORE`
Recherche dans un index géospatial les membres situés à l’intérieur une zone d’une boîte ou d’un cercle, puis stocke éventuellement le résultat.
[En savoir plus](https://valkey.io/commands/geosearchstore/)
**Commandes de hachage**
+ `HDEL`
Supprime un ou plusieurs champs et leurs valeurs d’un hachage. Supprime le hachage s’il ne reste aucun champ.
[En savoir plus](https://valkey.io/commands/hdel/)
+ `HEXISTS`
Détermine si un champ existe dans un hachage.
[En savoir plus](https://valkey.io/commands/hexists/)
+ `HGET`
Renvoie la valeur d’un champ dans un hachage.
[En savoir plus](https://valkey.io/commands/hget/)
+ `HGETALL`
Renvoie tous les champs et toutes les valeurs d’un hachage.
[En savoir plus](https://valkey.io/commands/hgetall/)
+ `HINCRBY`
Incrémente d’un nombre la valeur entière d’un champ dans un hachage. Utilise 0 comme valeur initiale si le champ n’existe pas.
[En savoir plus](https://valkey.io/commands/hincrby/)
+ `HINCRBYFLOAT`
Incrémente d’un nombre la valeur à virgule flottante d’un champ. Utilise 0 comme valeur initiale si le champ n’existe pas.
[En savoir plus](https://valkey.io/commands/hincrbyfloat/)
+ `HKEYS`
Renvoie tous les champs d’un hachage.
[En savoir plus](https://valkey.io/commands/hkeys/)
+ `HLEN`
Renvoie le nombre de champs d’un hachage.
[En savoir plus](https://valkey.io/commands/hlen/)
+ `HMGET`
Renvoie les valeurs de tous les champs d’un hachage.
[En savoir plus](https://valkey.io/commands/hmget/)
+ `HMSET`
Définit les valeurs de plusieurs champs.
[En savoir plus](https://valkey.io/commands/hmset/)
+ `HRANDFIELD`
Renvoie un ou plusieurs champs aléatoires à partir d’un hachage.
[En savoir plus](https://valkey.io/commands/hrandfield/)
+ `HSCAN`
Effectue une itération sur les champs et les valeurs d’un hachage.
[En savoir plus](https://valkey.io/commands/hscan/)
+ `HSET`
Crée ou modifie la valeur d’un champ dans un hachage.
[En savoir plus](https://valkey.io/commands/hset/)
+ `HSETNX`
Définit la valeur d’un champ dans un hachage uniquement lorsque le champ n’existe pas.
[En savoir plus](https://valkey.io/commands/hsetnx/)
+ `HSTRLEN`
Renvoie la longueur de la valeur d’un champ.
[En savoir plus](https://valkey.io/commands/hstrlen/)
+ `HVALS`
Renvoie toutes les valeurs d’un hachage.
[En savoir plus](https://valkey.io/commands/hvals/)
**HyperLogLog Commandes**
+ `PFADD`
Ajoute des éléments à une HyperLogLog clé. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/pfadd/)
+ `PFCOUNT`
Renvoie la cardinalité approximative du ou des ensembles observés par la ou les HyperLogLog touches.
[En savoir plus](https://valkey.io/commands/pfcount/)
+ `PFMERGE`
Fusionne une ou plusieurs HyperLogLog valeurs en une seule clé.
[En savoir plus](https://valkey.io/commands/pfmerge/)
**Commandes de liste**
+ `BLMOVE`
Extrait un élément d’une liste, le transmet à une autre liste et le renvoie. Bloque jusqu’à ce qu’un élément soit disponible autrement. Supprime la liste si le dernier élément a été déplacé.
[En savoir plus](https://valkey.io/commands/blmove/)
+ `BLMPOP`
Extrait le premier élément de l’une des listes. Bloque jusqu’à ce qu’un élément soit disponible autrement. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/blmpop/)
+ `BLPOP`
Supprime et renvoie le premier élément d’une liste. Bloque jusqu’à ce qu’un élément soit disponible autrement. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/blpop/)
+ `BRPOP`
Supprime et renvoie le dernier élément d’une liste. Bloque jusqu’à ce qu’un élément soit disponible autrement. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/brpop/)
+ `BRPOPLPUSH`
Extrait un élément d’une liste, le transmet à une autre liste et le renvoie. Bloque jusqu’à ce qu’un élément soit disponible autrement. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/brpoplpush/)
+ `LINDEX`
Renvoie un élément d’une liste en fonction de son index.
[En savoir plus](https://valkey.io/commands/lindex/)
+ `LINSERT`
Insère un élément avant ou après un autre élément dans une liste.
[En savoir plus](https://valkey.io/commands/linsert/)
+ `LLEN`
Renvoie la longueur d’une liste.
[En savoir plus](https://valkey.io/commands/llen/)
+ `LMOVE`
Renvoie un élément après l’avoir extrait d’une liste et l’avoir transféré vers une autre. Supprime la liste si le dernier élément a été déplacé.
[En savoir plus](https://valkey.io/commands/lmove/)
+ `LMPOP`
Renvoie plusieurs éléments d’une liste après les avoir retirés. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/lmpop/)
+ `LPOP`
Renvoie les premiers éléments d’une liste après les avoir retirés. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/lpop/)
+ `LPOS`
Renvoie l’index des éléments correspondants dans une liste.
[En savoir plus](https://valkey.io/commands/lpos/)
+ `LPUSH`
Ajoute un ou plusieurs éléments à une liste. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/lpush/)
+ `LPUSHX`
Ajoute un ou plusieurs éléments avant une liste uniquement lorsque celle-ci existe.
[En savoir plus](https://valkey.io/commands/lpushx/)
+ `LRANGE`
Renvoie un ensemble d’éléments à partir d’une liste.
[En savoir plus](https://valkey.io/commands/lrange/)
+ `LREM`
Retire les éléments d’une liste. Supprime la liste si le dernier élément a été retiré.
[En savoir plus](https://valkey.io/commands/lrem/)
+ `LSET`
Définit la valeur d’un élément d’une liste en fonction de son index.
[En savoir plus](https://valkey.io/commands/lset/)
+ `LTRIM`
Retire des éléments aux deux extrémités d’une liste. Supprime la liste si tous les éléments ont été tronqués.
[En savoir plus](https://valkey.io/commands/ltrim/)
+ `RPOP`
Renvoie et retire les derniers éléments d’une liste. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/rpop/)
+ `RPOPLPUSH`
Renvoie le dernier élément d’une liste après l’avoir retiré et transféré vers une autre liste. Supprime la liste si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/rpoplpush/)
+ `RPUSH`
Ajoute un ou plusieurs éléments à une liste. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/rpush/)
+ `RPUSHX`
Ajoute un élément à une liste uniquement lorsque celle-ci existe.
[En savoir plus](https://valkey.io/commands/rpushx/)
**Commandes Pub/Sub**
**Note**
Étant donné que les commandes PUBSUB utilisent en interne un mécanisme PUBSUB partitionné, les noms de canaux seront mélangés.
+ `PUBLISH`
Publie un message sur un canal.
[En savoir plus](https://valkey.io/commands/publish/)
+ `PUBSUB CHANNELS`
Renvoie les canaux actifs.
[En savoir plus](https://valkey.io/commands/pubsub-channels/)
+ `PUBSUB NUMSUB`
Renvoie le nombre d’abonnés aux canaux.
[En savoir plus](https://valkey.io/commands/pubsub-numsub/)
+ `PUBSUB SHARDCHANNELS`
Renvoie les canaux de partition actifs.
[En savoir plus](https://valkey.io/commands/pubsub-shardchannels/)
+ `PUBSUB SHARDNUMSUB`
Renvoie le nombre d’abonnés aux canaux de partition.
[En savoir plus](https://valkey.io/commands/pubsub-shardnumsub/)
+ `SPUBLISH`
Publie un message sur un canal de partition.
[En savoir plus](https://valkey.io/commands/spublish/)
+ `SSUBSCRIBE`
Écoute les messages publiés sur les canaux de partition.
[En savoir plus](https://valkey.io/commands/ssubscribe/)
+ `SUBSCRIBE`
Écoute les messages publiés sur les canaux.
[En savoir plus](https://valkey.io/commands/subscribe/)
+ `SUNSUBSCRIBE`
Arrête d’écouter les messages publiés sur les canaux de partition.
[En savoir plus](https://valkey.io/commands/sunsubscribe/)
+ `UNSUBSCRIBE`
Arrête d’écouter les messages publiés sur les canaux.
[En savoir plus](https://valkey.io/commands/unsubscribe/)
**Commandes de création de script**
+ `EVAL`
Exécute un script Lua côté serveur.
[En savoir plus](https://valkey.io/commands/eval/)
+ `EVAL_RO`
Exécute un script Lua côté serveur en lecture seule.
[En savoir plus](https://valkey.io/commands/eval_ro/)
+ `EVALSHA`
Exécute un script Lua côté serveur par digest. SHA1
[En savoir plus](https://valkey.io/commands/evalsha/)
+ `EVALSHA_RO`
Exécute un script Lua en lecture seule côté serveur par digest. SHA1
[En savoir plus](https://valkey.io/commands/evalsha_ro/)
+ `SCRIPT EXISTS`
Détermine si des scripts Lua côté serveur existent dans le cache de script.
[En savoir plus](https://valkey.io/commands/script-exists/)
+ `SCRIPT FLUSH`
Actuellement, un cache de script no-op est géré par le service.
[En savoir plus](https://valkey.io/commands/script-flush/)
+ `SCRIPT LOAD`
Charge un script Lua côté serveur dans le cache de script.
[En savoir plus](https://valkey.io/commands/script-load/)
**Commandes de gestion des serveurs**
**Note**
Lorsque vous utilisez des ElastiCache clusters basés sur des nœuds pour Valkey et Redis OSS, le client doit envoyer des commandes de vidage à chaque serveur principal pour vider toutes les clés. ElastiCache Serverless pour Valkey et Redis OSS fonctionne différemment, car il fait abstraction de la topologie de cluster sous-jacente. Le résultat est que dans ElastiCache Serverless, `FLUSHDB` les `FLUSHALL` commandes effleurent toujours toutes les clés du cluster. Pour cette raison, les commandes flush ne peuvent pas être incluses dans une transaction sans serveur.
+ `ACL CAT`
Répertorie les catégories de liste ACL ou les commandes d’une catégorie.
[En savoir plus](https://valkey.io/commands/acl-cat/)
+ `ACL GENPASS`
Génère un mot de passe sécurisé pseudo-aléatoire qui peut être utilisé pour identifier les utilisateurs de liste ACL.
[En savoir plus](https://valkey.io/commands/acl-genpass/)
+ `ACL GETUSER`
Répertorie les règles de liste ACL d’un utilisateur.
[En savoir plus](https://valkey.io/commands/acl-getuser/)
+ `ACL LIST`
Vide les règles en vigueur au format de fichier ACL.
[En savoir plus](https://valkey.io/commands/acl-list/)
+ `ACL USERS`
Répertorie tous les utilisateurs de liste ACL.
[En savoir plus](https://valkey.io/commands/acl-users/)
+ `ACL WHOAMI`
Renvoie le nom d’utilisateur authentifié de la connexion en cours.
[En savoir plus](https://valkey.io/commands/acl-whoami/)
+ `DBSIZE`
Renvoie le nombre de clés dans la base de données actuellement sélectionnée. Il n’est pas garanti que cette opération soit atomique sur tous les emplacements.
[En savoir plus](https://valkey.io/commands/dbsize/)
+ `COMMAND`
Renvoie des informations détaillées sur toutes les commandes.
[En savoir plus](https://valkey.io/commands/command/)
+ `COMMAND COUNT`
Renvoie le nombre de commandes.
[En savoir plus](https://valkey.io/commands/command-count/)
+ `COMMAND DOCS`
Renvoie des informations documentaires sur une, plusieurs ou toutes les commandes.
[En savoir plus](https://valkey.io/commands/command-docs/)
+ `COMMAND GETKEYS`
Extrait les noms de clés d’une commande arbitraire.
[En savoir plus](https://valkey.io/commands/command-getkeys/)
+ `COMMAND GETKEYSANDFLAGS`
Extrait les noms de clés et les indicateurs d’accès d’une commande arbitraire.
[En savoir plus](https://valkey.io/commands/command-getkeysandflags/)
+ `COMMAND INFO`
Renvoie des informations sur une, plusieurs ou toutes les commandes.
[En savoir plus](https://valkey.io/commands/command-info/)
+ `COMMAND LIST`
Renvoie la liste des noms de commandes.
[En savoir plus](https://valkey.io/commands/command-list/)
+ `COMMANDLOG`
Un conteneur pour les commandes du journal des commandes.
[En savoir plus](https://valkey.io/commands/commandlog/)
+ `COMMANDLOG GET`
Renvoie les entrées du journal de commandes spécifié.
[En savoir plus](https://valkey.io/commands/commandlog-get/)
+ `COMMANDLOG HELP`
Afficher un texte utile sur les différentes sous-commandes.
[En savoir plus](https://valkey.io/commands/commandlog-help/)
+ `COMMANDLOG LEN`
Renvoie le nombre d'entrées dans le type de journal de commandes spécifié.
[En savoir plus](https://valkey.io/commands/commandlog-len/)
+ `COMMANDLOG RESET`
Efface toutes les entrées du type de journal de commandes spécifié.
[En savoir plus](https://valkey.io/commands/commandlog-reset/)
+ `FLUSHALL`
Retire toutes les clés de toutes les bases de données. Il n’est pas garanti que cette opération soit atomique sur tous les emplacements.
[En savoir plus](https://valkey.io/commands/flushall/)
+ `FLUSHDB`
Retire toutes les clés de la base de données en cours. Il n’est pas garanti que cette opération soit atomique sur tous les emplacements.
[En savoir plus](https://valkey.io/commands/flushdb/)
+ `INFO`
Renvoie des informations et des statistiques sur le serveur.
[En savoir plus](https://valkey.io/commands/info/)
+ `LOLWUT`
Affiche les illustrations informatiques et la version Valkey ou Redis OSS.
[En savoir plus](https://valkey.io/commands/lolwut/)
+ `ROLE`
Renvoie le rôle de réplication.
[En savoir plus](https://valkey.io/commands/role/)
+ `TIME`
Renvoie l’heure du serveur.
[En savoir plus](https://valkey.io/commands/time/)
**Commandes d’ensemble**
+ `SADD`
Ajoute un ou plusieurs membres à un ensemble. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/sadd/)
+ `SCARD`
Renvoie le nombre de membres d’un ensemble.
[En savoir plus](https://valkey.io/commands/scard/)
+ `SDIFF`
Renvoie la différence entre plusieurs ensembles.
[En savoir plus](https://valkey.io/commands/sdiff/)
+ `SDIFFSTORE`
Stocke dans une clé la différence entre plusieurs ensembles.
[En savoir plus](https://valkey.io/commands/sdiffstore/)
+ `SINTER`
Renvoie l’intersection de plusieurs ensembles.
[En savoir plus](https://valkey.io/commands/sinter/)
+ `SINTERCARD`
Renvoie le nombre de membres de l’intersection de plusieurs ensembles.
[En savoir plus](https://valkey.io/commands/sintercard/)
+ `SINTERSTORE`
Stocke dans une clé l’intersection de plusieurs ensembles.
[En savoir plus](https://valkey.io/commands/sinterstore/)
+ `SISMEMBER`
Détermine si un membre appartient à un ensemble.
[En savoir plus](https://valkey.io/commands/sismember/)
+ `SMEMBERS`
Renvoie tous les membres d’un ensemble.
[En savoir plus](https://valkey.io/commands/smembers/)
+ `SMISMEMBER`
Détermine si plusieurs membres appartiennent à un ensemble.
[En savoir plus](https://valkey.io/commands/smismember/)
+ `SMOVE`
Déplace un membre d’un ensemble à un autre.
[En savoir plus](https://valkey.io/commands/smove/)
+ `SPOP`
Renvoie un ou plusieurs membres aléatoires d’un ensemble après les avoir retirés. Supprime l’ensemble si le dernier membre a été extrait.
[En savoir plus](https://valkey.io/commands/spop/)
+ `SRANDMEMBER`
Obtient un ou plusieurs membres aléatoires à partir d’un ensemble.
[En savoir plus](https://valkey.io/commands/srandmember/)
+ `SREM`
Retire un ou plusieurs membres d’un ensemble. Supprime l’ensemble si le dernier membre a été retiré.
[En savoir plus](https://valkey.io/commands/srem/)
+ `SSCAN`
Effectue une itération sur les membres d’un ensemble.
[En savoir plus](https://valkey.io/commands/sscan/)
+ `SUNION`
Renvoie l’union de plusieurs ensembles.
[En savoir plus](https://valkey.io/commands/sunion/)
+ `SUNIONSTORE`
Stocke dans une clé l’union de plusieurs ensembles.
[En savoir plus](https://valkey.io/commands/sunionstore/)
**Commandes d’ensemble trié**
+ `BZMPOP`
Retire et renvoie un membre en fonction de son score dans un ou plusieurs ensembles triés. Bloque jusqu’à ce qu’un membre soit disponible autrement. Supprime l’ensemble trié si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/bzmpop/)
+ `BZPOPMAX`
Retire et renvoie le membre ayant le score le plus élevé dans ou plusieurs ensembles triés. Bloque jusqu’à ce qu’un membre soit disponible autrement. Supprime l’ensemble trié si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/bzpopmax/)
+ `BZPOPMIN`
Retire et renvoie le membre ayant le score le plus faible dans ou plusieurs ensembles triés. Bloque jusqu’à ce qu’un membre soit disponible autrement. Supprime l’ensemble trié si le dernier élément a été extrait.
[En savoir plus](https://valkey.io/commands/bzpopmin/)
+ `ZADD`
Ajoute un ou plusieurs membres à un ensemble trié ou met à jour leurs scores. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/zadd/)
+ `ZCARD`
Renvoie le nombre de membres d’un ensemble trié.
[En savoir plus](https://valkey.io/commands/zcard/)
+ `ZCOUNT`
Renvoie le nombre de membres d’un ensemble trié dont les scores sont compris dans une plage.
[En savoir plus](https://valkey.io/commands/zcount/)
+ `ZDIFF`
Renvoie la différence entre plusieurs ensembles triés.
[En savoir plus](https://valkey.io/commands/zdiff/)
+ `ZDIFFSTORE`
Stocke dans une clé la différence entre plusieurs ensembles triés.
[En savoir plus](https://valkey.io/commands/zdiffstore/)
+ `ZINCRBY`
Incrémente le score d’un membre dans un ensemble trié.
[En savoir plus](https://valkey.io/commands/zincrby/)
+ `ZINTER`
Renvoie l’intersection de plusieurs ensembles triés.
[En savoir plus](https://valkey.io/commands/zinter/)
+ `ZINTERCARD`
Renvoie le nombre de membres de l’intersection de plusieurs ensembles triés.
[En savoir plus](https://valkey.io/commands/zintercard/)
+ `ZINTERSTORE`
Stocke dans une clé l’intersection de plusieurs ensembles triés.
[En savoir plus](https://valkey.io/commands/zinterstore/)
+ `ZLEXCOUNT`
Renvoie le nombre de membres d’un ensemble trié compris dans une plage lexicographique.
[En savoir plus](https://valkey.io/commands/zlexcount/)
+ `ZMPOP`
Renvoie les membres ayant le score le plus élevé ou le plus faible d’un ou de plusieurs ensembles triés après les avoir retirés. Supprime l’ensemble trié si le dernier membre a été extrait.
[En savoir plus](https://valkey.io/commands/zmpop/)
+ `ZMSCORE`
Renvoie le score d’un ou de plusieurs membres d’un ensemble trié.
[En savoir plus](https://valkey.io/commands/zmscore/)
+ `ZPOPMAX`
Renvoie les membres ayant le score le plus élevé d’un ensemble trié après les avoir retirés. Supprime l’ensemble trié si le dernier membre a été extrait.
[En savoir plus](https://valkey.io/commands/zpopmax/)
+ `ZPOPMIN`
Renvoie les membres ayant le score le plus faible d’un ensemble trié après les avoir retirés. Supprime l’ensemble trié si le dernier membre a été extrait.
[En savoir plus](https://valkey.io/commands/zpopmin/)
+ `ZRANDMEMBER`
Renvoie un ou plusieurs membres aléatoires d’un ensemble trié.
[En savoir plus](https://valkey.io/commands/zrandmember/)
+ `ZRANGE`
Renvoie les membres d’un ensemble trié compris dans une plage d’index.
[En savoir plus](https://valkey.io/commands/zrange/)
+ `ZRANGEBYLEX`
Renvoie les membres d’un ensemble trié compris dans une plage lexicographique.
[En savoir plus](https://valkey.io/commands/zrangebylex/)
+ `ZRANGEBYSCORE`
Renvoie les membres d’un ensemble trié compris dans une plage de scores.
[En savoir plus](https://valkey.io/commands/zrangebyscore/)
+ `ZRANGESTORE`
Stocke dans une clé une plage de membres d’un ensemble trié.
[En savoir plus](https://valkey.io/commands/zrangestore/)
+ `ZRANK`
Renvoie l’index d’un membre d’un ensemble trié, classé par scores croissants.
[En savoir plus](https://valkey.io/commands/zrank/)
+ `ZREM`
Retire un ou plusieurs membres d’un ensemble trié. Supprime l’ensemble trié si tous les membres ont été retirés.
[En savoir plus](https://valkey.io/commands/zrem/)
+ `ZREMRANGEBYLEX`
Retire les membres d’un ensemble trié compris dans une plage lexicographique. Supprime l’ensemble trié si tous les membres ont été retirés.
[En savoir plus](https://valkey.io/commands/zremrangebylex/)
+ `ZREMRANGEBYRANK`
Retire les membres d’un ensemble trié compris dans une plage d’index. Supprime l’ensemble trié si tous les membres ont été retirés.
[En savoir plus](https://valkey.io/commands/zremrangebyrank/)
+ `ZREMRANGEBYSCORE`
Retire les membres d’un ensemble trié compris dans une plage de scores. Supprime l’ensemble trié si tous les membres ont été retirés.
[En savoir plus](https://valkey.io/commands/zremrangebyscore/)
+ `ZREVRANGE`
Renvoie les membres d’un ensemble trié compris dans une plage d’index, dans l’ordre inverse.
[En savoir plus](https://valkey.io/commands/zrevrange/)
+ `ZREVRANGEBYLEX`
Renvoie les membres d’un ensemble trié compris dans une plage lexicographique, dans l’ordre inverse.
[En savoir plus](https://valkey.io/commands/zrevrangebylex/)
+ `ZREVRANGEBYSCORE`
Renvoie les membres d’un ensemble trié compris dans une plage de scores, dans l’ordre inverse.
[En savoir plus](https://valkey.io/commands/zrevrangebyscore/)
+ `ZREVRANK`
Renvoie l’index d’un membre d’un ensemble trié, classé par scores décroissants.
[En savoir plus](https://valkey.io/commands/zrevrank/)
+ `ZSCAN`
Effectue une itération sur les membres et les scores d’un ensemble trié.
[En savoir plus](https://valkey.io/commands/zscan/)
+ `ZSCORE`
Renvoie le score d’un membre dans un ensemble trié.
[En savoir plus](https://valkey.io/commands/zscore/)
+ `ZUNION`
Renvoie l’union de plusieurs ensembles triés.
[En savoir plus](https://valkey.io/commands/zunion/)
+ `ZUNIONSTORE`
Stocke dans une clé l’union de plusieurs ensembles triés.
[En savoir plus](https://valkey.io/commands/zunionstore/)
**Commandes de flux**
+ `XACK`
Renvoie le nombre de messages qui ont été confirmés avec succès par le membre du groupe de consommateurs d’un flux.
[En savoir plus](https://valkey.io/commands/xack/)
+ `XADD`
Ajoute un nouveau message à un flux. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/xadd/)
+ `XAUTOCLAIM`
Change ou acquiert la propriété des messages d’un groupe de consommateurs, comme s’ils étaient remis en tant que membre du groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xautoclaim/)
+ `XCLAIM`
Change ou acquiert la propriété d’un message d’un groupe de consommateurs, comme s’il était remis en tant que membre du groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xclaim/)
+ `XDEL`
Renvoie le nombre de messages après les avoir retirés d’un flux.
[En savoir plus](https://valkey.io/commands/xdel/)
+ `XGROUP CREATE`
Crée un groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xgroup-create/)
+ `XGROUP CREATECONSUMER`
Crée un consommateur dans un groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xgroup-createconsumer/)
+ `XGROUP DELCONSUMER`
Supprime un consommateur d’un groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xgroup-delconsumer/)
+ `XGROUP DESTROY`
Détruit un groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xgroup-destroy/)
+ `XGROUP SETID`
Définit le dernier ID remis d’un groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xgroup-setid/)
+ `XINFO CONSUMERS`
Renvoie la liste des consommateurs d’un groupe de consommateurs.
[En savoir plus](https://valkey.io/commands/xinfo-consumers/)
+ `XINFO GROUPS`
Renvoie la liste des groupes de consommateurs d’un flux.
[En savoir plus](https://valkey.io/commands/xinfo-groups/)
+ `XINFO STREAM`
Renvoie des informations sur un flux.
[En savoir plus](https://valkey.io/commands/xinfo-stream/)
+ `XLEN`
Renvoie le nombre de messages dans un flux.
[En savoir plus](https://valkey.io/commands/xlen/)
+ `XPENDING`
Renvoie les informations et les entrées de la liste des entrées en attente d’un groupe de consommateurs de flux.
[En savoir plus](https://valkey.io/commands/xpending/)
+ `XRANGE`
Renvoie les messages d'un flux compris dans une plage de IDs.
[En savoir plus](https://valkey.io/commands/xrange/)
+ `XREAD`
Renvoie des messages provenant de plusieurs flux dont le contenu est IDs supérieur à celui demandé. Bloque jusqu’à ce qu’un message soit disponible autrement.
[En savoir plus](https://valkey.io/commands/xread/)
+ `XREADGROUP`
Renvoie les messages nouveaux ou historiques d’un flux pour un consommateur d’un groupe. Bloque jusqu’à ce qu’un message soit disponible autrement.
[En savoir plus](https://valkey.io/commands/xreadgroup/)
+ `XREVRANGE`
Renvoie les messages d'un flux compris dans un intervalle de valeurs IDs dans l'ordre inverse.
[En savoir plus](https://valkey.io/commands/xrevrange/)
+ `XTRIM`
Supprime les messages depuis le début d’un flux.
[En savoir plus](https://valkey.io/commands/xtrim/)
**Commandes de chaîne**
+ `APPEND`
Ajoute une chaîne à la valeur d’une clé. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/append/)
+ `DECR`
Décrémente de un la valeur entière d’une clé. Utilise 0 comme valeur initiale si la clé n’existe pas.
[En savoir plus](https://valkey.io/commands/decr/)
+ `DECRBY`
Décrémente d’un nombre la valeur entière d’une clé. Utilise 0 comme valeur initiale si la clé n’existe pas.
[En savoir plus](https://valkey.io/commands/decrby/)
+ `GET`
Renvoie la valeur de chaîne d’une clé.
[En savoir plus](https://valkey.io/commands/get/)
+ `GETDEL`
Renvoie la valeur de chaîne d’une clé après avoir supprimé la clé.
[En savoir plus](https://valkey.io/commands/getdel/)
+ `GETEX`
Renvoie la valeur de chaîne d’une clé après avoir défini son délai d’expiration.
[En savoir plus](https://valkey.io/commands/getex/)
+ `GETRANGE`
Renvoie une sous-chaîne de la chaîne stockée dans une clé.
[En savoir plus](https://valkey.io/commands/getrange/)
+ `GETSET`
Renvoie la valeur de chaîne précédente d’une clé après l’avoir définie sur une nouvelle valeur.
[En savoir plus](https://valkey.io/commands/getset/)
+ `INCR`
Incrémente de un la valeur entière d’une clé. Utilise 0 comme valeur initiale si la clé n’existe pas.
[En savoir plus](https://valkey.io/commands/incr/)
+ `INCRBY`
Incrémente d’un nombre la valeur entière d’une clé. Utilise 0 comme valeur initiale si la clé n’existe pas.
[En savoir plus](https://valkey.io/commands/incrby/)
+ `INCRBYFLOAT`
Incrémente d’un nombre la valeur à virgule flottante d’une clé. Utilise 0 comme valeur initiale si la clé n’existe pas.
[En savoir plus](https://valkey.io/commands/incrbyfloat/)
+ `LCS`
Recherche la sous-chaîne commune la plus longue.
[En savoir plus](https://valkey.io/commands/lcs/)
+ `MGET`
Renvoie de manière atomique les valeurs de chaîne d’une ou de plusieurs clés.
[En savoir plus](https://valkey.io/commands/mget/)
+ `MSET`
Crée ou modifie de manière atomique les valeurs de chaîne d’une ou de plusieurs clés.
[En savoir plus](https://valkey.io/commands/mset/)
+ `MSETNX`
Modifie de manière atomique les valeurs de chaîne d’une ou de plusieurs clés uniquement lorsque toutes les clés n’existent pas.
[En savoir plus](https://valkey.io/commands/msetnx/)
+ `PSETEX`
Définit la valeur de chaîne et le délai d’expiration d’une clé en millisecondes. La clé est créée si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/psetex/)
+ `SET`
Définit la valeur de chaîne d’une clé, en ignorant son type. La clé est créée si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/set/)
+ `SETEX`
Définit la valeur de chaîne et le délai d’expiration d’une clé. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/setex/)
+ `SETNX`
Définit la valeur de chaîne d’une clé uniquement lorsque la clé n’existe pas.
[En savoir plus](https://valkey.io/commands/setnx/)
+ `SETRANGE`
Remplace une partie d’une valeur de chaîne par une autre selon un décalage. Crée la clé si elle n’existe pas.
[En savoir plus](https://valkey.io/commands/setrange/)
+ `STRLEN`
Renvoie la longueur d’une valeur de chaîne.
[En savoir plus](https://valkey.io/commands/strlen/)
+ `SUBSTR`
Renvoie une sous-chaîne d’une valeur de chaîne.
[En savoir plus](https://valkey.io/commands/substr/)
**Commandes de transaction**
+ `DISCARD`
Supprime une transaction.
[En savoir plus](https://valkey.io/commands/discard/)
+ `EXEC`
Exécute toutes les commandes d’une transaction.
[En savoir plus](https://valkey.io/commands/exec/)
+ `MULTI`
Démarre une transaction.
[En savoir plus](https://valkey.io/commands/multi/)
## Commandes Valkey et Redis OSS restreintes
Pour offrir une expérience de service géré, ElastiCache restreint l'accès à certaines commandes spécifiques au moteur de cache qui nécessitent des privilèges avancés. Pour les caches exécutant Redis OSS, les commandes suivantes ne sont pas disponibles :
+ `acl setuser`
+ `acl load`
+ `acl save`
+ `acl deluser`
+ `bgrewriteaof`
+ `bgsave`
+ `cluster addslot`
+ `cluster addslotsrange`
+ `cluster bumpepoch`
+ `cluster delslot`
+ `cluster delslotsrange `
+ `cluster failover `
+ `cluster flushslots `
+ `cluster forget `
+ `cluster links`
+ `cluster meet`
+ `cluster setslot`
+ `config`
+ `debug`
+ `migrate`
+ `psync`
+ `replicaof`
+ `save`
+ `slaveof`
+ `shutdown`
+ `sync`
De plus, les commandes suivantes ne sont pas disponibles pour les caches sans serveur :
+ `acl log`
+ `client caching`
+ `client getredir`
+ `client id`
+ `client info`
+ `client kill`
+ `client list`
+ `client no-evict`
+ `client pause`
+ `client tracking`
+ `client trackinginfo`
+ `client unblock`
+ `client unpause`
+ `cluster count-failure-reports`
+ `commandlog`
+ `commandlog get`
+ `commandlog help`
+ `commandlog len`
+ `commandlog reset`
+ `fcall`
+ `fcall_ro`
+ `function`
+ `function delete`
+ `function dump`
+ `function flush`
+ `function help`
+ `function kill`
+ `function list`
+ `function load`
+ `function restore`
+ `function stats`
+ `keys`
+ `lastsave`
+ `latency`
+ `latency doctor`
+ `latency graph`
+ `latency help`
+ `latency histogram`
+ `latency history`
+ `latency latest`
+ `latency reset`
+ `memory`
+ `memory doctor`
+ `memory help`
+ `memory malloc-stats`
+ `memory purge`
+ `memory stats`
+ `memory usage`
+ `monitor`
+ `move`
+ `object`
+ `object encoding`
+ `object freq`
+ `object help`
+ `object idletime`
+ `object refcount`
+ `pfdebug`
+ `pfselftest`
+ `psubscribe`
+ `pubsub numpat`
+ `punsubscribe`
+ `script kill`
+ `slowlog`
+ `slowlog get`
+ `slowlog help`
+ `slowlog len`
+ `slowlog reset`
+ `swapdb`
+ `wait`
## Commandes Memcached prises en charge
ElastiCache Serverless pour Memcached prend en charge toutes les [commandes](https://github.com/memcached/memcached/wiki/Commands) memcached de la version open source memcached 1.6, à l'exception des suivantes :
+ Les connexions client nécessitent le protocole TLS ; par conséquent, le protocole UDP n’est pas pris en charge.
+ Le protocole binaire n’est pas pris en charge, car il est officiellement [obsolète](https://github.com/memcached/memcached/wiki/ReleaseNotes160) dans Memcached 1.6.
+ Les commandes `GET/GETS` sont limitées à 16 Ko afin d’éviter toute attaque DoS potentielle sur le serveur lors de l’extraction d’un grand nombre de clés.
+ La commande `flush_all` différée sera rejetée avec `CLIENT_ERROR`.
+ Les commandes qui configurent le moteur ou qui révèlent des informations internes sur l’état du moteur ou les journaux ne sont pas prises en charge. Par exemple :
+ Pour la commande `STATS`, seules `stats` et `stats reset` sont prises en charge. Les autres variantes renverront `ERROR`.
+ `lru / lru_crawler` : modification des paramètres LRU et Crawler LRU
+ `watch` : surveille les journaux du serveur Memcached
+ `verbosity` : configure le niveau de journalisation du serveur
+ `me`- la commande meta debug (me) n'est pas prise en charge
# Configuration et limites de Valkey et Redis OSS
Les moteurs Valkey et Redis OSS fournissent chacun un certain nombre de paramètres de configuration, dont certains sont modifiables dans Redis OSS et d'autres non modifiables ElastiCache pour garantir des performances et une fiabilité stables.
## Caches sans serveur
Pour les caches sans serveur, les groupes de paramètres ne sont pas utilisés et toutes les configurations de Valkey ou Redis OSS ne sont pas modifiables. Les paramètres Valkey ou Redis OSS suivants sont en place :
****
| Name | Détails | Description |
| --- | --- | --- |
| acl-pubsub-default | `allchannels` | Autorisations de canal pubsub par défaut pour les utilisateurs ACL sur le cache. |
| client-output-buffer-limit | `normal 0 0 0` `pubsub 32mb 8mb 60` | Les clients normaux n'ont aucune limite de mémoire tampon. PUB/SUB les clients seront déconnectés s'ils franchissent un backlog de 32 Mo ou s'ils franchissent un backlog de 8 Mo pendant 60 minutes. |
| client-query-buffer-limit | 1 Gio | Taille maximale d’un seul tampon de requête client. En outre, les clients ne peuvent pas émettre de demande comportant plus de 3 999 arguments. |
| cluster-allow-pubsubshard-when-down | yes | Cela permet au cache d’assurer le trafic pubsub lorsqu’il est partiellement indisponible. |
| cluster-allow-reads-when-down | yes | Cela permet au cache d’assurer le trafic de lecture lorsqu’il est partiellement indisponible. |
| cluster-enabled | yes | Tous les caches sans serveur sont en mode cluster activé, ce qui leur permet de partitionner leurs données de manière transparente sur plusieurs partitions de backend. Tous les emplacements sont présentés aux clients comme appartenant à un seul nœud virtuel. |
| cluster-require-full-coverage | no | Lorsque l’espace de clés est partiellement indisponible (c’est-à-dire qu’au moins un emplacement de hachage est inaccessible), le cache continue à accepter les requêtes pour la partie de l’espace de clés qui est encore couverte. L’ensemble de l’espace de clés sera toujours « couvert » par un seul nœud virtuel dans cluster slots. |
| lua-time-limit | 5000 | Durée maximale d'exécution d'un script Lua, en millisecondes, avant qu'une action ne soit entreprise pour ElastiCache arrêter le script. *En cas `lua-time-limit` de dépassement, toutes les commandes Valkey ou Redis OSS peuvent renvoyer une erreur de la forme \$1\$1\$1\$1-BUSY.* Étant donné que cet état peut interférer avec de nombreuses opérations essentielles de Valkey ou Redis OSS, ElastiCache il émettra d'abord une commande *SCRIPT KILL*. En cas d'échec, ElastiCache il redémarrera de force Valkey ou Redis OSS. |
| maxclients | 65000 | Nombre maximal de clients pouvant être connectés au cache simultanément. Les connexions établies par la suite peuvent réussir ou non. |
| maxmemory-policy | volatile-lru | Les éléments dont le TTL est défini sont expulsés après une estimation least-recently-used (LRU) lorsque la limite de mémoire d'un cache est atteinte. |
| notify-keyspace-events | (chaîne vide) | Les événements de l’espace de clés ne sont actuellement pas pris en charge sur les caches sans serveur. |
| port | Port principal : 6379 Port de lecture : 6380 | Les caches sans serveur publient deux ports portant le même nom d’hôte. Le port principal autorise les écritures et les lectures, tandis que le port de lecture autorise les lectures éventuellement cohérentes à faible latence à l’aide de la commande READONLY. |
| proto-max-bulk-len | 512 Mio | Taille maximale d’une seule demande d’élément. |
| timeout | 0 | Les clients ne sont pas déconnectés de force après une période d’inactivité spécifique, mais ils peuvent être déconnectés en état stable à des fins d’équilibrage de charge. |
Les limites suivantes s’appliquent également :
****
| Name | Détails | Description |
| --- | --- | --- |
| Taille par cache | 5 000 GiB | Quantité maximale de données pouvant être stockées par cache sans serveur. |
| Taille par emplacement | 32 GiO | Taille maximale d'un seul emplacement de hachage Valkey ou Redis OSS. Les clients qui essaient de définir plus de données que cela sur un seul emplacement Valkey ou Redis OSS déclencheront la politique d'expulsion sur cet emplacement et, si aucune clé ne peut être expulsée, recevront une erreur de mémoire insuffisante (). OOM |
| ECPU par cache | 15 000 000 ECPU/seconde | ElastiCache Unités de traitement (ECPU) métriques. Le nombre de données ECPUs consommées par vos requêtes dépend du temps nécessaire au vCPU et de la quantité de données transférées. |
| ECPU par slot | 30 000 à 90 000 ECPU/seconde | Maximum de 30 000 ECPUs/second par emplacement ou de 90 000 ECPUs/second si vous utilisez Read from Replica à l'aide de connexions READONLY. |
| Arguments par demande | 3 999 | Nombre maximum d'arguments par demande. Les clients qui envoient plus d'arguments par demande recevront un message d'erreur. |
| Longueur du nom de clé | 4 Kio | La taille maximale d'une seule clé Valkey ou Redis OSS ou d'un seul nom de canal. Les clients faisant référence à des clés dont la taille est supérieure à cette valeur recevront une erreur. |
| Taille de script Lua | 4 Mio | Taille maximale d'un seul script Lua Valkey ou Redis OSS. Les tentatives de chargement d’un script Lua dont la taille est supérieure à cette valeur provoqueront un message d’erreur. |
## Clusters basés sur des nœuds
Pour les clusters basés sur des nœuds, consultez [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis) les valeurs par défaut des paramètres de configuration et celles qui sont configurables. Les valeurs par défaut sont généralement recommandées, sauf si vous devez les remplacer dans un cas d’utilisation spécifique.
# IPv6 exemples de clients pour Valkey, Memcached et Redis OSS
ElastiCache est compatible avec Valkey, Memcached et Redis OSS. Cela signifie que les clients qui prennent en charge IPv6 les connexions devraient pouvoir se connecter à des clusters IPv6 activés ElastiCache pour Memcached. Certaines mises en garde méritent d'être prises en compte lors de l'interaction avec des ressources IPv6 activées.
Vous pouvez consulter le billet de blog [consacré aux meilleures pratiques pour les clients Valkey et Redis](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) sur le blog de AWS base de données pour obtenir des recommandations sur la configuration des clients Valkey et Redis OSS pour les ressources. ElastiCache
Vous trouverez ci-dessous les meilleures pratiques pour interagir avec les ElastiCache ressources IPv6 activées dans les bibliothèques clientes open source couramment utilisées.
## Clients validés avec Valkey et Redis OSS
ElastiCache est compatible avec Valkey et Redis OSS open source. Cela signifie que les clients Valkey et Redis OSS open source qui prennent en charge IPv6 les connexions devraient pouvoir se connecter aux clusters Redis OSS IPv6 activés ElastiCache . En outre, plusieurs des clients Python et Java les plus populaires ont été spécifiquement testés et validés pour fonctionner avec toutes les configurations de type réseau prises en charge (IPv4 uniquement, IPv6 uniquement et Dual Stack)
Les clients suivants ont été spécifiquement validés pour fonctionner avec toutes les configurations de type de réseau prises en charge pour Valkey et Redis OSS.
Clients validés :
+ [Redis Py ()](https://github.com/redis/redis-py) : [4,1.2](https://github.com/redis/redis-py/tree/v4.1.2)
+ [Lettuce](https://lettuce.io/) : [version : 6.1.6.RELEASE](https://github.com/lettuce-io/lettuce-core/tree/6.1.6.RELEASE)
+ [Jedis](https://github.com/redis/jedis) : [version : 3.6.0](https://github.com/redis/jedis/tree/jedis-3.6.0)
# Bonnes pratiques pour les clients (Valkey et Redis OSS)
Découvrez les meilleures pratiques pour les scénarios courants et suivez les exemples de code de certaines des bibliothèques clientes open source Valkey et Redis OSS les plus populaires (redis-py et Lettuce) PHPRedis, ainsi que les meilleures pratiques pour interagir avec les ElastiCache ressources des bibliothèques clientes Memcached open source couramment utilisées.
**Topics**
+ [Grand nombre de connexions (Valkey et Redis OSS)](BestPractices.Clients.Redis.Connections.md)
+ [Découverte des clients du cluster et ralentissement exponentiel (Valkey et Redis OSS)](BestPractices.Clients.Redis.Discovery.md)
+ [Configurer un délai d'expiration côté client (Valkey et Redis OSS)](BestPractices.Clients.Redis.ClientTimeout.md)
+ [Configurer un délai d'inactivité côté serveur (Valkey et Redis OSS)](BestPractices.Clients.Redis.ServerTimeout.md)
+ [Scripts Lua](BestPractices.Clients.Redis.LuaScripts.md)
+ [Stockage d'objets composites de grande taille (Valkey et Redis OSS)](BestPractices.Clients.Redis.LargeItems.md)
+ [Configuration du client Lettuce (Valkey et Redis OSS)](BestPractices.Clients-lettuce.md)
+ [Configuration d'un protocole préféré pour les clusters à double pile (Valkey et Redis OSS)](#network-type-configuring-dual-stack-redis)
# Grand nombre de connexions (Valkey et Redis OSS)
Les caches sans serveur et individuels ElastiCache pour les nœuds Redis OSS prennent en charge jusqu'à 65 000 connexions client simultanées. Toutefois, pour optimiser les performances, nous recommandons que les applications client ne fonctionnent pas constamment à ce niveau de connexions. Valkey et Redis OSS ont chacun un processus à thread unique basé sur une boucle d'événements dans laquelle les demandes des clients entrantes sont traitées de manière séquentielle. Cela signifie que le temps de réponse d’un client donné s’allonge à mesure que le nombre de clients connectés augmente.
Vous pouvez prendre les mesures suivantes pour éviter de rencontrer un goulot d'étranglement de connexion sur un serveur Valkey ou Redis OSS :
+ Effectuez des opérations de lecture à partir de réplicas en lecture. Cela peut être fait en désactivant les points de terminaison du ElastiCache lecteur en mode cluster ou en utilisant des répliques pour les lectures en mode cluster activé, y compris un cache sans serveur.
+ Répartissez le trafic d’écriture sur plusieurs nœuds primaires. Vous pouvez effectuer cette opération de deux façons. Vous pouvez utiliser un cluster Valkey ou Redis OSS multipartitionné avec un client compatible avec le mode cluster. Vous pouvez également écrire sur plusieurs nœuds primaires en mode cluster désactivé avec le partitionnement côté client. Ce processus est automatique dans un cache sans serveur.
+ Utilisez un groupe de connexions lorsqu’il est disponible dans votre bibliothèque client.
En général, la création d'une connexion TCP est une opération coûteuse en termes de calcul par rapport aux commandes classiques de Valkey ou Redis OSS. Par exemple, le traitement d'une SET/GET demande est d'un ordre de grandeur plus rapide lors de la réutilisation d'une connexion existante. L’utilisation d’un groupe de connexions client de taille limitée réduit les frais de gestion des connexions. Elle limite également le nombre de connexions entrantes simultanées provenant de l’application client.
L'exemple de code suivant PHPRedis montre qu'une nouvelle connexion est créée pour chaque nouvelle demande utilisateur :
```
$redis = new Redis();
if ($redis->connect($HOST, $PORT) != TRUE) {
//ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Nous avons comparé ce code en boucle sur une instance Amazon Elastic Compute Cloud (Amazon EC2) connectée à un nœud Graviton2 (m6g.2xlarge) pour Redis OSS. ElastiCache Nous avons placé le client et le serveur dans la même zone de disponibilité. La latence moyenne de l’ensemble de l’opération était de 2,82 millisecondes.
Lorsque nous avons mis à jour le code et utilisé des connexions persistantes et un groupe de connexions, la latence moyenne de l’ensemble de l’opération était de 0,21 milliseconde :
```
$redis = new Redis();
if ($redis->pconnect($HOST, $PORT) != TRUE) {
// ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Configurations redis.ini requises :
+ `redis.pconnect.pooling_enabled=1`
+ `redis.pconnect.connection_limit=10`
Le code suivant est un exemple de [groupe de connexions Redis-py](https://redis.readthedocs.io/en/stable/) :
```
conn = Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
conn.set(key, value)
```
Le code suivant est un exemple de [groupe de connexions Lettuce](https://lettuce.io/core/release/reference/#_connection_pooling) :
```
RedisClient client = RedisClient.create(RedisURI.create(HOST, PORT));
GenericObjectPool pool = ConnectionPoolSupport.createGenericObjectPool(() -> client.connect(), new GenericObjectPoolConfig());
pool.setMaxTotal(10); // Configure max connections to 10
try (StatefulRedisConnection connection = pool.borrowObject()) {
RedisCommands syncCommands = connection.sync();
syncCommands.set(key, value);
}
```
# Découverte des clients du cluster et ralentissement exponentiel (Valkey et Redis OSS)
Lorsque vous vous connectez à un cluster ElastiCache Valkey ou Redis OSS en mode cluster activé, la bibliothèque cliente correspondante doit être consciente du cluster. Les clients doivent obtenir une carte des emplacements de hachage sur les nœuds correspondants du cluster afin d’envoyer des demandes aux nœuds appropriés et d’éviter la surcharge de performances liée à la gestion des redirections du cluster. Par conséquent, le client doit découvrir la liste complète des emplacements et des nœuds mappés dans deux cas différents :
+ Le client est initialisé et doit renseigner la configuration initiale des emplacements.
+ Une redirection MOVED est reçue du serveur, par exemple en cas de basculement lorsque tous les emplacements desservis par l’ancien nœud primaire sont contrôlés par le réplica, ou en cas de repartitionnement lorsque les emplacements sont déplacés du nœud primaire source vers le nœud primaire cible.
La découverte du client se fait généralement en émettant une commande CLUSTER SLOT ou CLUSTER NODE au serveur Valkey ou Redis OSS. Nous recommandons la méthode CLUSTER SLOT, car elle renvoie au client l’ensemble des plages d’emplacements ainsi que les nœuds primaires et de réplica associés. Cette méthode ne nécessite pas d’analyse supplémentaire de la part du client. Elle est également plus efficace.
En fonction de la topologie du cluster, la taille de la réponse à la commande CLUSTER SLOT peut varier en fonction de la taille du cluster. Les clusters de plus grande taille dotés d’un plus grand nombre de nœuds produisent une réponse plus longue. Par conséquent, il est important de veiller à ce que le nombre de clients qui effectuent la découverte de la topologie du cluster n’augmente pas de manière illimitée. Par exemple, lorsque l’application client démarre ou perd la connexion avec le serveur et doit effectuer une découverte de clusters, une erreur courante est qu’elle lance plusieurs demandes de reconnexion et de découverte sans ajouter de backoff exponentiel lors d’une nouvelle tentative. Cela peut empêcher le serveur Valkey ou Redis OSS de répondre pendant une période prolongée, avec une utilisation du processeur à 100 %. La panne est prolongée si chaque commande CLUSTER SLOT doit traiter un grand nombre de nœuds dans le bus du cluster. Nous avons observé plusieurs pannes de clients dans le passé en raison de ce comportement dans différents langages, notamment Python (redis-py-cluster) et Java (Lettuce et Redisson).
Dans un cache sans serveur, de nombreux problèmes sont automatiquement atténués, car la topologie du cluster annoncée est statique et comprend deux entrées : un point de terminaison d’écriture et un point de terminaison de lecture. De plus, la découverte de clusters est automatiquement répartie sur plusieurs nœuds lors de l’utilisation du point de terminaison du cache. Les recommandations suivantes restent toutefois utiles.
Pour atténuer l’impact provoqué par un afflux soudain de demandes de connexion et de découverte, nous recommandons ce qui suit :
+ Implémentez un groupe de connexions client de taille limitée pour limiter le nombre de connexions entrantes simultanées en provenance de l’application client.
+ Lorsque le client se déconnecte du serveur en raison d’un délai d’expiration, réessayez en ajoutant un backoff exponentiel avec instabilité. Cela permet d’éviter que plusieurs clients ne surchargent le serveur en même temps.
+ Consultez [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md) pour trouver le point de terminaison de cluster afin d’effectuer la découverte de clusters. En agissant ainsi, vous répartissez la charge de découverte sur tous les nœuds du cluster (jusqu’à 90) au lieu de toucher quelques nœuds de départ codés en dur du cluster.
Voici quelques exemples de code pour la logique de réessai exponentielle dans redis-py,, et Lettuce. PHPRedis
**Exemple de logique avec backoff 1 : redis-py**
redis-py possède un mécanisme de nouvelle tentative intégré qui permet d’effectuer une nouvelle tentative immédiatement après un échec. Ce mécanisme peut être activé via l'`retry_on_timeout`argument fourni lors de la création d'un objet [Redis OSS](https://redis.readthedocs.io/en/stable/examples/connection_examples.html#redis.Redis). L’exemple ci-dessous illustre un mécanisme de nouvelle tentative personnalisé avec backoff exponentiel et instabilité. Nous avons soumis une demande d’extraction pour implémenter de manière native le backoff exponentiel dans [redis-py (\$11494)](https://github.com/andymccurdy/redis-py/pull/1494). À l’avenir, il ne sera peut-être plus nécessaire de procéder à une implémentation manuelle.
```
def run_with_backoff(function, retries=5):
base_backoff = 0.1 # base 100ms backoff
max_backoff = 10 # sleep for maximum 10 seconds
tries = 0
while True:
try:
return function()
except (ConnectionError, TimeoutError):
if tries >= retries:
raise
backoff = min(max_backoff, base_backoff * (pow(2, tries) + random.random()))
print(f"sleeping for {backoff:.2f}s")
sleep(backoff)
tries += 1
```
Vous pouvez ensuite utiliser le code suivant pour définir une valeur :
```
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
res = run_with_backoff(lambda: client.set("key", "value"))
print(res)
```
En fonction de votre charge de travail, vous souhaiterez peut-être modifier la valeur de backoff de base de 1 seconde à quelques dizaines ou centaines de millisecondes pour les charges de travail sensibles à la latence.
**Exemple de logique de rétrogradation 2 : PHPRedis**
PHPRedis possède un mécanisme intégré qui permet de réessayer 10 fois (non configurable) au maximum. Il est possible de configurer un délai entre les tentatives (avec une instabilité à partir de la deuxième tentative). Pour plus d’informations, consultez l’[exemple de code](https://github.com/phpredis/phpredis/blob/b0b9dd78ef7c15af936144c1b17df1a9273d72ab/library.c#L335-L368) ci-après. [Nous avons soumis une pull request pour implémenter nativement le backoff exponentiel dans [PHPredis (\$11986)](https://github.com/phpredis/phpredis/pull/1986) qui a depuis été fusionnée et documentée.](https://github.com/phpredis/phpredis/blob/develop/README.md#retry-and-backoff) Pour ceux qui utilisent la dernière version de PHPRedis, il ne sera pas nécessaire de l'implémenter manuellement, mais nous avons inclus ici la référence pour ceux des versions précédentes. L’exemple de code suivant permet de configurer le délai du mécanisme de nouvelle tentative :
```
$timeout = 0.1; // 100 millisecond connection timeout
$retry_interval = 100; // 100 millisecond retry interval
$client = new Redis();
if($client->pconnect($HOST, $PORT, $timeout, NULL, $retry_interval) != TRUE) {
return; // ERROR: connection failed
}
$client->set($key, $value);
```
**Exemple de logique avec backoff 3 : Lettuce**
Lettuce possède des mécanismes de nouvelle tentative intégrés basés sur les stratégies de backoff exponentiel décrites dans l’article [Backoff exponentiel et instabilité](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) (langue française non garantie). Voici un extrait de code qui illustre l’approche avec instabilité complète :
```
public static void main(String[] args)
{
ClientResources resources = null;
RedisClient client = null;
try {
resources = DefaultClientResources.builder()
.reconnectDelay(Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(5), // maximum 5 second delay
100, TimeUnit.MILLISECONDS) // 100 millisecond base
).build();
client = RedisClient.create(resources, RedisURI.create(HOST, PORT));
client.setOptions(ClientOptions.builder()
.socketOptions(SocketOptions.builder().connectTimeout(Duration.ofMillis(100)).build()) // 100 millisecond connection timeout
.timeoutOptions(TimeoutOptions.builder().fixedTimeout(Duration.ofSeconds(5)).build()) // 5 second command timeout
.build());
// use the connection pool from above example
} finally {
if (connection != null) {
connection.close();
}
if (client != null){
client.shutdown();
}
if (resources != null){
resources.shutdown();
}
}
}
```
# Configurer un délai d'expiration côté client (Valkey et Redis OSS)
**Configuration du délai d'expiration côté client**
Configurez le délai d’expiration côté client de manière appropriée pour laisser au serveur suffisamment de temps pour traiter la demande et générer la réponse. Il pourra également procéder à une interruption immédiate si la connexion au serveur ne peut pas être établie. Certaines commandes Valkey ou Redis OSS peuvent être plus coûteuses en termes de calcul que d'autres. Par exemple, les scripts Lua ou MULTI/EXEC les transactions contenant plusieurs commandes qui doivent être exécutées de manière atomique. En général, il est recommandé d’augmenter le délai d’expiration côté client pour éviter que le client n’expire avant de recevoir la réponse du serveur, notamment dans les cas suivants :
+ Exécution de commandes sur plusieurs clés
+ Exécution de MULTI/EXEC transactions ou de scripts Lua composés de plusieurs commandes Valkey ou Redis OSS individuelles
+ Lecture de valeurs élevées
+ Exécution d’opérations de blocage telles que BLPOP
Dans le cas d’une opération de blocage telle que BLPOP, la bonne pratique consiste à régler le délai d’expiration de la commande sur un nombre inférieur au délai d’expiration du socket.
Voici des exemples de code pour implémenter un délai d'attente côté client dans redis-py et Lettuce. PHPRedis
**Exemple de configuration du délai d’expiration 1 : redis-py**
Voici un exemple de code avec redis-py :
```
# connect to Redis server with a 100 millisecond timeout
# give every Redis command a 2 second timeout
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10,socket_connect_timeout=0.1,socket_timeout=2))
res = client.set("key", "value") # will timeout after 2 seconds
print(res) # if there is a connection error
res = client.blpop("list", timeout=1) # will timeout after 1 second
# less than the 2 second socket timeout
print(res)
```
**Exemple de configuration de temporisation 2 : PHPRedis**
Voici un exemple de code avec PHPRedis :
```
// connect to Redis server with a 100ms timeout
// give every Redis command a 2s timeout
$client = new Redis();
$timeout = 0.1; // 100 millisecond connection timeout
$retry_interval = 100; // 100 millisecond retry interval
$client = new Redis();
if($client->pconnect($HOST, $PORT, 0.1, NULL, 100, $read_timeout=2) != TRUE){
return; // ERROR: connection failed
}
$client->set($key, $value);
$res = $client->set("key", "value"); // will timeout after 2 seconds
print "$res\n"; // if there is a connection error
$res = $client->blpop("list", 1); // will timeout after 1 second
print "$res\n"; // less than the 2 second socket timeout
```
**Exemple de configuration du délai d’expiration 3 : Lettuce**
Voici un exemple de code avec Lettuce :
```
// connect to Redis server and give every command a 2 second timeout
public static void main(String[] args)
{
RedisClient client = null;
StatefulRedisConnection connection = null;
try {
client = RedisClient.create(RedisURI.create(HOST, PORT));
client.setOptions(ClientOptions.builder()
.socketOptions(SocketOptions.builder().connectTimeout(Duration.ofMillis(100)).build()) // 100 millisecond connection timeout
.timeoutOptions(TimeoutOptions.builder().fixedTimeout(Duration.ofSeconds(2)).build()) // 2 second command timeout
.build());
// use the connection pool from above example
commands.set("key", "value"); // will timeout after 2 seconds
commands.blpop(1, "list"); // BLPOP with 1 second timeout
} finally {
if (connection != null) {
connection.close();
}
if (client != null){
client.shutdown();
}
}
}
```
# Configurer un délai d'inactivité côté serveur (Valkey et Redis OSS)
Nous avons observé des cas où l’application d’un client compte un grand nombre de clients inactifs connectés, mais n’envoie pas activement de commandes. Dans de tels scénarios, vous pouvez épuiser les 65 000 connexions avec un nombre élevé de clients inactifs. Pour éviter de tels scénarios, configurez le paramètre de délai d’expiration de manière appropriée sur le serveur via [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis). Cela garantit que le serveur déconnecte activement les clients inactifs afin d’éviter une augmentation du nombre de connexions. Ce paramètre n’est pas disponible sur les caches sans serveur.
# Scripts Lua
Valkey et Redis OSS prennent en charge plus de 200 commandes, y compris celles permettant d'exécuter des scripts Lua. Cependant, en ce qui concerne les scripts Lua, plusieurs pièges peuvent affecter la mémoire et la disponibilité de Valkey ou Redis OSS.
**Scripts Lua non paramétrés**
Chaque script Lua est mis en cache sur le serveur Valkey ou Redis OSS avant son exécution. Les scripts Lua non paramétrés sont uniques, ce qui peut amener le serveur Valkey ou Redis OSS à stocker un grand nombre de scripts Lua et à consommer davantage de mémoire. Pour atténuer ce problème, assurez-vous que tous les scripts Lua sont paramétrés et exécutez régulièrement la commande SCRIPT FLUSH pour nettoyer les scripts Lua mis en cache, si nécessaire.
Sachez également que les clés doivent être fournies. Si aucune valeur n'est fournie pour le paramètre KEY, le script échouera. Par exemple, cela ne fonctionnera pas :
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return "Hello World"' 0
(error) ERR Lua scripts without any input keys are not supported.
```
Cela fonctionnera :
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return redis.call("get", KEYS[1])' 1 mykey-2
"myvalue-2"
```
L’exemple suivant illustre l’utilisation des scripts paramétrés. Le premier exemple d’approche non paramétrée, qui n’est pas recommandée, donne lieu à trois scripts Lua mis en cache différents :
```
eval "return redis.call('set','key1','1')" 0
eval "return redis.call('set','key2','2')" 0
eval "return redis.call('set','key3','3')" 0
```
Utilisez plutôt le modèle suivant pour créer un script unique capable d’accepter les paramètres transmis :
```
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key1 1
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key2 2
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key3 3
```
**Scripts Lua de longue durée**
Les scripts Lua peuvent exécuter plusieurs commandes de manière atomique. Leur exécution peut donc prendre plus de temps qu'une commande Valkey ou Redis OSS normale. Si le script Lua exécute uniquement des opérations en lecture seule, vous pouvez l’arrêter en plein milieu. Cependant, dès que le script Lua exécute une opération d’écriture, il devient impossible de l’arrêter et il doit être s’exécuter jusqu’à la fin. Un script Lua de longue durée qui est en train de muter peut empêcher le serveur Valkey ou Redis OSS de répondre pendant une longue période. Pour atténuer ce problème, évitez les scripts Lua de longue durée et testez le script dans un environnement de pré-production.
**Script Lua avec écritures en mode furtif**
Un script Lua peut continuer à écrire de nouvelles données dans Valkey ou Redis OSS de plusieurs manières, même lorsque Valkey ou Redis OSS est terminé : `maxmemory`
+ Le script démarre lorsque le serveur Valkey ou Redis OSS se trouve en dessous et contient plusieurs `maxmemory` opérations d'écriture à l'intérieur
+ La première commande d’écriture du script ne consomme pas de mémoire (comme DEL), puis les autres opérations d’écriture consomment de la mémoire
+ Vous pouvez atténuer ce problème en configurant une politique d'expulsion appropriée dans le serveur Valkey ou Redis OSS autre que. `noeviction` Cela permet à Redis OSS d'expulser des éléments et de libérer de la mémoire entre les scripts Lua.
# Stockage d'objets composites de grande taille (Valkey et Redis OSS)
Dans certains scénarios, une application peut stocker de gros éléments composites dans Valkey ou Redis OSS (comme un jeu de données de hachage de plusieurs Go). Cette pratique n'est pas recommandée car elle entraîne souvent des problèmes de performance dans Valkey ou Redis OSS. Par exemple, le client peut exécuter une commande HGETALL pour récupérer l’intégralité de la collection de hachage de plusieurs Go. Cela peut générer une pression de mémoire importante sur le serveur Valkey ou Redis OSS qui met en mémoire tampon le gros élément dans la mémoire tampon de sortie du client. En outre, pour la migration d'emplacements en mode cluster, les emplacements contenant des éléments dont la taille sérialisée est supérieure à 256 Mo ElastiCache ne sont pas migrés.
Pour résoudre les problèmes liés aux éléments de grande taille, suivez les recommandations ci-dessous :
+ Divisez l’élément composite de grande taille en plusieurs éléments de plus petite taille. Par exemple, divisez une collection de hachage de grande taille en champs clé-valeur individuels avec un schéma de nom de clé qui reflète la collection de manière appropriée, en utilisant par exemple un préfixe commun dans le nom de clé pour identifier la collection d’éléments. Si vous devez accéder à plusieurs champs de la même collection de manière atomique, vous pouvez utiliser la commande MGET pour récupérer plusieurs valeurs-clés dans la même commande.
+ Si vous avez évalué toutes les options et que vous ne parvenez toujours pas à diviser le jeu de données de la collection de grande taille, essayez d’utiliser des commandes qui fonctionnent sur un sous-ensemble des données de la collection plutôt que sur l’ensemble de la collection. Évitez les cas d’utilisation qui vous obligent à récupérer de manière atomique l’intégralité de la collection de plusieurs Go dans la même commande. L’utilisation de commandes HGET ou HMGET au lieu de HGETALL sur les collections de hachage en est un exemple.
# Configuration du client Lettuce (Valkey et Redis OSS)
Cette section décrit les options de configuration recommandées pour Java et Lettuce, ainsi que leur application aux ElastiCache clusters.
Les recommandations de cette section ont été testées avec la version 6.2.2 de Lettuce.
**Topics**
+ [Exemple : configuration de laitue pour le mode cluster, TLS activé](BestPractices.Clients-lettuce-cme.md)
+ [Exemple : configuration de laitue pour le mode cluster désactivée, TLS activé](BestPractices.Clients-lettuce-cmd.md)
**TTL du cache DNS de Java**
La machine virtuelle Java (JVM) met en cache les recherches de nom DNS. Lorsque la JVM convertit un nom d'hôte en adresse IP, elle met l'adresse IP en cache pendant une période spécifiée, connue sous le nom de *time-to-live*(TTL).
Le choix d'une valeur TTL est un compromis entre la latence et la réactivité au changement. En TTLs raccourcissant, les résolveurs DNS détectent plus rapidement les mises à jour du DNS du cluster. Cela peut permettre à votre application de réagir plus rapidement aux remplacements ou à d'autres flux de travail auxquels votre cluster est soumis. Toutefois, si la TTL est trop faible, le volume de requêtes augmente, ce qui peut accentuer la latence de votre application. Bien qu'il n'y ait pas de valeur TTL correcte, lorsque vous la configurez, vous pouvez déterminer le délai d'attente maximal avant qu'une modification prenne effet.
Comme ElastiCache les nœuds utilisent des entrées de nom DNS susceptibles de changer, nous vous recommandons de configurer votre JVM avec un TTL faible de 5 à 10 secondes. Ainsi, lorsque l’adresse IP d’un nœud change, votre application peut recevoir et utiliser la nouvelle adresse IP de la ressource en interrogeant l’entrée DNS.
Dans certaines configurations Java, la durée de vie par défaut de la JVM est définie de façon à ce que la JVM n'actualise jamais les entrées DNS tant qu'elle n'est pas redémarrée.
Pour plus de détails sur la façon de définir la durée de vie de votre JVM, consultez [Comment définir la durée de vie de la JVM](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html#how-to-set-the-jvm-ttl).
**Version de Lettuce**
Nous recommandons Lettuce version 6.2.2 ou ultérieure.
**Points de terminaison**
Lorsque vous utilisez des clusters activés en mode cluster, définissez `redisUri` sur le point de terminaison de configuration du cluster. La recherche DNS pour cet URI renvoie une liste de tous les nœuds disponibles dans le cluster et est résolue de manière aléatoire vers l'un d'entre eux lors de l'initialisation du cluster. Pour plus de détails sur le fonctionnement de l'actualisation topologique, reportez-vous à la section *dynamicRefreshResources*suivante de cette rubrique.
**SocketOption**
Activez [KeepAlive](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.KeepAliveOptions.html). L'activation de cette option réduit la nécessité de gérer les échecs de connexion lors de l'exécution des commandes.
Assurez-vous de définir le [Délai de connexion](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.Builder.html#connectTimeout-java.time.Duration-) en fonction des exigences de votre application et de votre charge de travail. Pour plus d'informations, consultez la section Délais plus loin dans cette rubrique.
**ClusterClientOption: options client activées en mode cluster**
Activez [AutoReconnect](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#autoReconnect-boolean-)en cas de perte de connexion.
Configurez [CommandTimeout](https://lettuce.io/core/release/api/io/lettuPrce/core/RedisURI.html#getTimeout--). Pour plus de détails, consultez la section Délais plus loin dans cette rubrique.
Définissez [nodeFilter](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#nodeFilter-java.util.function.Predicate-) pour exclure les nœuds défaillants de la topologie. Lettuce enregistre tous les nœuds présents dans la sortie « nœuds de cluster » (y compris les nœuds ayant le statut PFAIL/FAIL) dans les « partitions » du client. Au cours du processus de création de la topologie du cluster, celle-ci tente de se connecter à tous les nœuds de partition. Ce comportement de Lettuce qui consiste à ajouter des nœuds défaillants peut provoquer des erreurs de connexion (ou des avertissements) lorsque des nœuds sont remplacés pour une raison quelconque.
Par exemple, une fois qu'un basculement est terminé et que le cluster démarre le processus de restauration, alors que la topologie du cluster est actualisée, la carte des nœuds de bus du cluster indique brièvement que le nœud inférieur est listé en tant que nœud FAIL, avant qu'il ne soit entièrement supprimé de la topologie. Pendant cette période, le client Lettuce considère qu'il s'agit d'un nœud sain et s'y connecte en permanence. Cela provoque un échec une fois que les nouvelles tentatives sont épuisées.
Par exemple :
```
final ClusterClientOptions clusterClientOptions =
ClusterClientOptions.builder()
... // other options
.nodeFilter(it ->
! (it.is(RedisClusterNode.NodeFlag.FAIL)
|| it.is(RedisClusterNode.NodeFlag.EVENTUAL_FAIL)
|| it.is(RedisClusterNode.NodeFlag.HANDSHAKE)
|| it.is(RedisClusterNode.NodeFlag.NOADDR)))
.validateClusterNodeMembership(false)
.build();
redisClusterClient.setOptions(clusterClientOptions);
```
**Note**
Il est préférable d'utiliser le filtrage des nœuds lorsqu'il est DynamicRefreshSources défini sur true. Sinon, si la vue topologique provient d'un seul nœud source problématique, qui constate la défaillance d'un nœud primaire d'une partition, elle filtrera ce nœud primaire et les emplacements ne seront donc pas couverts. Le fait d'avoir plusieurs nœuds de départ (lorsque DynamicRefreshSources c'est vrai) réduit le risque de ce problème, car au moins certains nœuds de départ devraient avoir une vue topologique mise à jour après un basculement avec le nœud principal récemment promu.
**ClusterTopologyRefreshOptions: Options permettant de contrôler l'actualisation de la topologie du cluster du client activé en mode cluster**
**Note**
Les clusters en mode cluster désactivé ne prennent pas en charge les commandes de découverte de clusters et ne sont pas compatibles avec toutes les fonctionnalités de découverte de topologie dynamique de clients.
Le mode cluster désactivé ElastiCache n'est pas compatible avec Lettuce`MasterSlaveTopologyRefresh`. Au lieu de cela, pour le mode cluster désactivé, vous pouvez configurer un `StaticMasterReplicaTopologyProvider` et fournir les points de terminaison de lecture et d'écriture du cluster.
Pour plus d'informations sur la connexion à des clusters en mode cluster désactivé, veuillez consulter [Trouver les points de terminaison d'un cluster Valkey ou Redis OSS (mode cluster désactivé) (console)](Endpoints.md#Endpoints.Find.Redis).
Si vous souhaitez utiliser la fonctionnalité de découverte de topologie dynamique de Lettuce, vous pouvez créer un cluster en mode cluster activé avec la même configuration de partitions que votre cluster existant. Toutefois, pour les clusters en mode cluster activé, nous vous recommandons de configurer au moins 3 partitions avec au moins 1 réplica pour prendre en charge un basculement rapide.
Activez [enablePeriodicRefresh](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enablePeriodicRefresh-java.time.Duration-). Cela active les mises à jour périodiques de la topologie du cluster, afin que le client puisse mettre à jour la topologie du cluster dans les intervalles de refreshPeriod (par défaut : 60 secondes). Lorsqu'il est désactivé, le client met à jour la topologie du cluster uniquement lorsque des erreurs se produisent s'il tente d'exécuter des commandes sur le cluster.
Lorsque cette option est activée, vous pouvez réduire la latence associée à l'actualisation de la topologie du cluster en ajoutant cette tâche à une tâche en arrière-plan. Bien que l'actualisation de la topologie soit effectuée en arrière-plan, elle peut être quelque peu lente pour les clusters comportant de nombreux nœuds. Cela est dû au fait que tous les nœuds sont interrogés afin de connaître leurs vues et d'obtenir la vue de cluster la plus récente. Si vous gérez un cluster de grande taille, vous souhaiterez peut-être augmenter la période.
Activez [enableAllAdaptiveRefreshTriggers](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enableAllAdaptiveRefreshTriggers--). Cela active une actualisation adaptative de la topologie qui utilise tous les [déclencheurs](https://lettuce.io/core/6.1.6.RELEASE/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.RefreshTrigger.html) : MOVED\$1REDIRECT, ASK\$1REDIRECT, PERSISTENT\$1RECONNECTS, UNCOVERED\$1SLOT, UNKNOWN\$1NODE. Les déclencheurs d'actualisation adaptatifs initient les mises à jour de la vue topologique en fonction des événements qui se produisent lors des opérations du cluster Valkey ou Redis OSS. L'activation de cette option entraîne une actualisation immédiate de la topologie lorsque l'un des déclencheurs précédents s'active. La fréquence des actualisations déclenchées adaptatives est limitée grâce à un délai d'attente, car les événements peuvent se produire à grande échelle (délai d'attente par défaut entre les mises à jour : 30).
Activez [closeStaleConnections](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#closeStaleConnections-boolean-). Cela permet de fermer les connexions obsolètes lors de l'actualisation de la topologie du cluster. Il n'entre en vigueur que si [ClusterTopologyRefreshOptions. isPeriodicRefreshEnabled ()](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.html#isPeriodicRefreshEnabled--) est vrai. Lorsqu'elle est activée, le client peut fermer les connexions obsolètes et en créer d'autres en arrière-plan. L'activation de cette option réduit la nécessité de gérer les échecs de connexion lors de l'exécution des commandes.
Activez [dynamicRefreshResources](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#dynamicRefreshSources-boolean-). Nous recommandons de l'activer dynamicRefreshResources pour les petits clusters et de la désactiver pour les grands clusters. dynamicRefreshResourcespermet de découvrir les nœuds de cluster à partir du nœud d'origine fourni (par exemple, point de terminaison de configuration du cluster). Il utilise tous les nœuds détectés en tant que sources pour actualiser la topologie du cluster.
L'actualisation dynamique interroge tous les nœuds détectés pour la topologie du cluster et tente de choisir la vue de cluster la plus précise. S'il est défini sur false, seuls les nœuds de départ initiaux sont utilisés comme sources pour la détection de la topologie, et le nombre de clients est obtenu uniquement pour les nœuds de départ initiaux. Lorsqu'il est désactivé, si le point de terminaison de la configuration du cluster est résolu en un nœud défaillant, la tentative d'actualisation de la vue du cluster échoue et entraîne des exceptions. Ce scénario peut se produire, car il faut un certain temps pour que l’entrée d’un nœud défaillant soit supprimée du point de terminaison de configuration du cluster. Par conséquent, le point de terminaison de la configuration peut toujours être résolu de manière aléatoire et brève en un nœud défaillant.
Cependant, lorsqu'il est activé, nous utilisons tous les nœuds de cluster reçus depuis la vue du cluster pour demander leur vue actuelle. Étant donné que nous éliminons les nœuds défaillants de cette vue, l'actualisation de la topologie sera réussie. Toutefois, lorsque dynamicRefreshSources c'est vrai, Lettuce interroge tous les nœuds pour obtenir la vue du cluster, puis compare les résultats. L'opération peut donc être coûteuse pour les clusters comportant un grand nombre de nœuds. Nous vous suggérons de désactiver cette fonctionnalité pour les clusters comportant de nombreux nœuds.
```
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
```
**ClientResources**
Configurez [DnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#dnsResolver-io.lettuce.core.resource.DnsResolver-) avec [DirContextDnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DirContextDnsResolver.html). Le résolveur DNS est basé sur com.sun.jndi.dns de Java. DnsContextFactory.
Configurez [reconnectDelay](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#reconnectDelay-io.lettuce.core.resource.Delay-) avec un backoff exponentiel et une instabilité complète. Lettuce possède des mécanismes de relance intégrés basés sur des stratégies de backoff exponentiel. Pour plus de détails, consultez [Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter) sur le AWS blog d'architecture. Pour plus d'informations sur l'importance d'adopter une nouvelle stratégie d'interruption, consultez les sections sur la logique d'interruption du billet de blog consacré aux [meilleures pratiques sur le AWS blog](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) de base de données.
```
ClientResources clientResources = DefaultClientResources.builder()
.dnsResolver(new DirContextDnsResolver())
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100, TimeUnit.MILLISECONDS)) // 100 millisecond base
.build();
```
**Délais **
Utilisez une valeur de délai de connexion inférieure à celle de votre commande. Lettuce utilise l'établissement d'une connexion différée. Ainsi, si le délai d'expiration de la connexion est supérieur à celui de la commande, vous pouvez connaître des échecs persistants après une actualisation de la topologie, si Lettuce essaie de se connecter à un nœud défectueux et si le délai de la commande est toujours dépassé.
Utilisez un délai de commande dynamique pour différentes commandes. Nous vous recommandons de définir le délai de commande en fonction de la durée attendue de la commande. Par exemple, utilisez un délai plus long pour les commandes qui itèrent sur plusieurs clés, comme les scripts FLUSHDB, FLUSHALL, KEYS, SMEMBERS ou Lua. Utilisez des délais plus courts pour les commandes à clé unique, telles que SET, GET et HSET.
**Note**
Les délais configurés dans l'exemple suivant concernent les tests qui ont exécuté des commandes SET/GET avec des clés et des valeurs d'une longueur maximale de 20 octets. Le temps de traitement peut être supérieur lorsque les commandes sont complexes ou que les clés et les valeurs sont plus grandes. Vous devez définir les délais en fonction du cas d'utilisation de votre application.
```
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
SocketOptions socketOptions = SocketOptions.builder()
.connectTimeout(CONNECT_TIMEOUT)
.build();
class DynamicClusterTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.CLUSTER)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration defaultCommandTimeout;
private final Duration metaCommandTimeout;
DynamicClusterTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
// Use a dynamic timeout for commands, to avoid timeouts during
// cluster management and slow operations.
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(
new DynamicClusterTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
```
# Exemple : configuration de laitue pour le mode cluster, TLS activé
**Note**
Dans l'exemple suivant, les délais d'attente concernent les tests qui ont exécuté des SET/GET commandes avec des clés et des valeurs d'une longueur maximale de 20 octets. Le temps de traitement peut être supérieur lorsque les commandes sont complexes ou que les clés et les valeurs sont plus grandes. Vous devez définir les délais en fonction du cas d'utilisation de votre application.
```
// Set DNS cache TTL
public void setJVMProperties() {
java.security.Security.setProperty("networkaddress.cache.ttl", "10");
}
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
// Create RedisURI from the cluster configuration endpoint
clusterConfigurationEndpoint = // TODO: add your cluster configuration endpoint
final RedisURI redisUriCluster =
RedisURI.Builder.redis(clusterConfigurationEndpoint)
.withPort(6379)
.withSsl(true)
.build();
// Configure the client's resources
ClientResources clientResources = DefaultClientResources.builder()
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100, TimeUnit.MILLISECONDS)) // 100 millisecond base
.dnsResolver(new DirContextDnsResolver())
.build();
// Create a cluster client instance with the URI and resources
RedisClusterClient redisClusterClient =
RedisClusterClient.create(clientResources, redisUriCluster);
// Use a dynamic timeout for commands, to avoid timeouts during
// cluster management and slow operations.
class DynamicClusterTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.CLUSTER)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration metaCommandTimeout;
private final Duration defaultCommandTimeout;
DynamicClusterTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(new DynamicClusterTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
// Configure the topology refreshment options
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
// Configure the socket options
final SocketOptions socketOptions =
SocketOptions.builder()
.connectTimeout(CONNECT_TIMEOUT)
.keepAlive(true)
.build();
// Configure the client's options
final ClusterClientOptions clusterClientOptions =
ClusterClientOptions.builder()
.topologyRefreshOptions(topologyOptions)
.socketOptions(socketOptions)
.autoReconnect(true)
.timeoutOptions(timeoutOptions)
.nodeFilter(it ->
! (it.is(RedisClusterNode.NodeFlag.FAIL)
|| it.is(RedisClusterNode.NodeFlag.EVENTUAL_FAIL)
|| it.is(RedisClusterNode.NodeFlag.NOADDR)))
.validateClusterNodeMembership(false)
.build();
redisClusterClient.setOptions(clusterClientOptions);
// Get a connection
final StatefulRedisClusterConnection connection =
redisClusterClient.connect();
// Get cluster sync/async commands
RedisAdvancedClusterCommands sync = connection.sync();
RedisAdvancedClusterAsyncCommands async = connection.async();
```
# Exemple : configuration de laitue pour le mode cluster désactivée, TLS activé
**Note**
Dans l'exemple suivant, les délais d'attente concernent les tests qui ont exécuté des SET/GET commandes avec des clés et des valeurs d'une longueur maximale de 20 octets. Le temps de traitement peut être supérieur lorsque les commandes sont complexes ou que les clés et les valeurs sont plus grandes. Vous devez définir les délais en fonction du cas d'utilisation de votre application.
```
// Set DNS cache TTL
public void setJVMProperties() {
java.security.Security.setProperty("networkaddress.cache.ttl", "10");
}
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
// Create RedisURI from the primary/reader endpoint
clusterEndpoint = // TODO: add your node endpoint
RedisURI redisUriStandalone =
RedisURI.Builder.redis(clusterEndpoint).withPort(6379).withSsl(true).withDatabase(0).build();
ClientResources clientResources =
DefaultClientResources.builder()
.dnsResolver(new DirContextDnsResolver())
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100,
TimeUnit.MILLISECONDS)) // 100 millisecond base
.build();
// Use a dynamic timeout for commands, to avoid timeouts during
// slow operations.
class DynamicTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration metaCommandTimeout;
private final Duration defaultCommandTimeout;
DynamicTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(new DynamicTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
final SocketOptions socketOptions =
SocketOptions.builder().connectTimeout(CONNECT_TIMEOUT).keepAlive(true).build();
ClientOptions clientOptions =
ClientOptions.builder().timeoutOptions(timeoutOptions).socketOptions(socketOptions).build();
RedisClient redisClient = RedisClient.create(clientResources, redisUriStandalone);
redisClient.setOptions(clientOptions);
```
## Configuration d'un protocole préféré pour les clusters à double pile (Valkey et Redis OSS)
Pour les clusters Valkey ou Redis OSS activés en mode cluster, vous pouvez contrôler le protocole que les clients utiliseront pour se connecter aux nœuds du cluster avec le paramètre IP Discovery. Le paramètre IP Discovery peut être défini sur IPv4 ou IPv6.
Pour les clusters Valkey ou Redis OSS, le paramètre de découverte IP définit le protocole IP utilisé dans les sorties des [slots ()](https://valkey.io/commands/cluster-slots/), des [clusters shards ()](https://valkey.io/commands/cluster-shards/) et des [nœuds de cluster (](https://valkey.io/commands/cluster-nodes/)). Ces commandes sont utilisées par les clients pour découvrir la topologie du cluster. Les clients utilisent les commandes IPs in these pour se connecter aux autres nœuds du cluster.
La modification de la découverte d'adresses IP n'entraînera aucune interruption de service pour les clients connectés. Cependant, la propagation des modifications prendra un certain temps. Pour déterminer à quel moment les modifications se sont complètement propagées pour un cluster Valkey ou Redis OSS, surveillez la sortie de. `cluster slots` Une fois que tous les nœuds renvoyés par la commande cluster slots ont pris IPs connaissance du nouveau protocole, les modifications ont fini de se propager.
Exemple avec Redis-Py :
```
cluster = RedisCluster(host="xxxx", port=6379)
target_type = IPv6Address # Or IPv4Address if changing to IPv4
nodes = set()
while len(nodes) == 0 or not all((type(ip_address(host)) is target_type) for host in nodes):
nodes = set()
# This refreshes the cluster topology and will discovery any node updates.
# Under the hood it calls cluster slots
cluster.nodes_manager.initialize()
for node in cluster.get_nodes():
nodes.add(node.host)
self.logger.info(nodes)
time.sleep(1)
```
Exemple avec Lettuce :
```
RedisClusterClient clusterClient = RedisClusterClient.create(RedisURI.create("xxxx", 6379));
Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4
Set nodes;
do {
// Check for any changes in the cluster topology.
// Under the hood this calls cluster slots
clusterClient.refreshPartitions();
Set nodes = new HashSet<>();
for (RedisClusterNode node : clusterClient.getPartitions().getPartitions()) {
nodes.add(node.getUri().getHost());
}
Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
try {
return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
} catch (UnknownHostException ignored) {}
return false;
}));
```
# Bonnes pratiques pour les clients (Memcached)
Découvrez les meilleures pratiques pour les scénarios courants liés ElastiCache aux clusters Memcached.
**Topics**
+ [Configuration de votre ElastiCache client pour un équilibrage de charge efficace (Memcached)](BestPractices.LoadBalancing.md)
+ [Clients validés avec Memcached](network-type-validated-clients-memcached.md)
+ [Configuration d'un protocole préféré pour les clusters à double pile (Memcached)](network-type-configuring-dual-stack-memcached.md)
# Configuration de votre ElastiCache client pour un équilibrage de charge efficace (Memcached)
**Note**
Cette section s'applique aux clusters Memcached à nœuds multiples basés sur des nœuds.
Pour utiliser efficacement plusieurs nœuds ElastiCache Memcached, vous devez être en mesure de répartir vos clés de cache entre les nœuds. Un moyen simple d'équilibrer la charge d'un cluster à *n* nœuds consiste à calculer le hachage de la clé de l'objet et à modifier le résultat par *n :`hash(key) mod n`.* La valeur résultante (0 à *n*–1) est le numéro du nœud où vous placez l'objet.
Cette approche est simple et fonctionne bien tant que le nombre de nœuds (*n*) est constant. Cependant, chaque fois que vous ajoutez ou supprimez un nœud du cluster, le nombre de clés qui doivent être déplacées est *(n - 1) / n* (où *n* correspond au nouveau nombre de nœuds). Ainsi, cette approche génère le déplacement d'un grand nombre de clés, ce qui se traduit par un grand nombre d'échecs de l'accès aux données du cache initial, surtout quand le nombre de nœuds devient important. La mise à l'échelle de 1 à 2 nœuds entraîne le déplacement de (2-1) / 2 (50 %) des clés, dans le meilleur des cas. La mise à l'échelle de 9 à 10 nœuds entraîne le déplacement de (10-1) / 10 (90 %) des clés. Si vous augmentez à cause d'un pic de trafic, vous ne voulez pas avoir un nombre important d'échecs de l'accès aux données du cache. Un grand nombre d'échecs de l'accès aux données du cache génère des requêtes dans la base de données, qui est déjà surchargée en raison du pic de trafic.
Un hachage cohérent est la solution à ce problème. Un hachage cohérent utilise un algorithme de façon à ce que chaque fois qu'un nœud est ajouté ou supprimé d'un cluster, le nombre de clés qui doivent être déplacées est d'environ *1 / n* (où *n* correspond au nouveau nombre de nœuds). Passer de 1 à 2 nœuds revient à ce que 1/2 (50 %) des clés soient déplacées, le pire des cas. Passer de 9 à 10 nœuds revient à ce que (10-1) / 10 (10 %) des clés soient déplacées.
En tant que l'utilisateur, vous contrôlez les l'algorithme de hachage qui est utilisé pour les clusters à plusieurs nœuds. Nous vous recommandons de configurer vos clients pour appliquer un hachage cohérent. Heureusement, il existe de nombreuses bibliothèques client Memcached dans les langages les plus utilisés qui mettent en œuvre un hachage cohérent. Consultez la documentation de la bibliothèque que vous utilisez pour voir si elle prend en charge le hachage cohérent et comment le mettre en œuvre.
Si vous travaillez en Java, PHP ou .NET, nous vous recommandons d'utiliser l'une des bibliothèques ElastiCache clientes Amazon.
## Hachage cohérent utilisant la technologie Java
Le client Java ElastiCache Memcached est basé sur le client Java open-source spymemcached, qui intègre des fonctionnalités de hachage cohérentes. La bibliothèque inclut une KetamaConnectionFactory classe qui implémente un hachage cohérent. Par défaut, le hachage cohérent est désactivé dans spymemcached.
Pour plus d'informations, consultez la KetamaConnectionFactory documentation à l'adresse [KetamaConnectionFactory](https://github.com/RTBHOUSE/spymemcached/blob/master/src/main/java/net/spy/memcached/KetamaConnectionFactory.java).
## Hachage cohérent à l'aide de PHP avec Memcached
Le client PHP ElastiCache Memcached est un wrapper autour de la bibliothèque PHP Memcached intégrée. Par défaut, la bibliothèque PHP Memcached désactive le hachage cohérent.
Utilisez le code suivant pour activer le hachage cohérent.
```
$m = new Memcached();
$m->setOption(Memcached::OPT_DISTRIBUTION, Memcached::DISTRIBUTION_CONSISTENT);
```
En plus du code précédent, nous vous conseillons d'activer également `memcached.sess_consistent_hash` dans votre fichier php.ini.
[Pour plus d'informations, consultez la documentation de configuration d'exécution pour Memcached PHP à l'adresse http://php. net/manual/en/memcached.configuration.php](http://php.net/manual/en/memcached.configuration.php). Notez spécifiquement le paramètre `memcached.sess_consistent_hash`.
## Hachage cohérent à l'aide de .NET avec Memcached
Le client .NET ElastiCache Memcached est un wrapper autour d'Enyim Memcached. Par défaut, le hachage cohérent est activé par le client Enyim Memcached.
Pour plus d'informations, consultez la `memcached/locator` documentation sur [https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration\$1 user-content-memcachedlocator](https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration#user-content-memcachedlocator).
# Clients validés avec Memcached
Les clients suivants ont été spécifiquement validés pour fonctionner avec toutes les configurations de type de réseau prises en charge pour Memcached.
Clients validés :
+ [AWS ElastiCache Client de cluster Memcached pour Php](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php) [— Version \$13.6.2](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php/tree/v3.2.0)
+ [AWS ElastiCache Cluster Client Memcached pour Java](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-java) — Le dernier master sur Github
# Configuration d'un protocole préféré pour les clusters à double pile (Memcached)
Pour les clusters Memcached, vous pouvez contrôler le protocole que les clients utiliseront pour se connecter aux nœuds du cluster à l'aide du paramètre de découverte d'adresses IP. Le paramètre IP Discovery peut être défini sur IPv4 ou IPv6.
Le paramètre de découverte d'adresses IP contrôle le protocole IP utilisé dans la sortie de cluster config get. Ce qui déterminera à son tour le protocole IP utilisé par les clients qui prennent en charge la découverte automatique ElastiCache pour les clusters Memcached.
La modification de la découverte d'adresses IP n'entraînera aucune interruption de service pour les clients connectés. Cependant, la propagation des modifications prendra un certain temps.
Surveillez la sortie de `getAvailableNodeEndPoints` pour Java, et pour Php, surveillez la sortie de `getServerList`. Une fois que la sortie de ces fonctions indique tous IPs les nœuds du cluster qui utilisent le protocole mis à jour, les modifications ont fini de se propager.
Exemple Java :
```
MemcachedClient client = new MemcachedClient(new InetSocketAddress("xxxx", 11211));
Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4
Set nodes;
do {
nodes = client.getAvailableNodeEndPoints().stream().map(NodeEndPoint::getIpAddress).collect(Collectors.toSet());
Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
try {
return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
} catch (UnknownHostException ignored) {}
return false;
}));
```
Exemple Php :
```
$client = new Memcached;
$client->setOption(Memcached::OPT_CLIENT_MODE, Memcached::DYNAMIC_CLIENT_MODE);
$client->addServer("xxxx", 11211);
$nodes = [];
$target_ips_count = 0;
do {
# The PHP memcached client only updates the server list if the polling interval has expired and a
# command is sent
$client->get('test');
$nodes = $client->getServerList();
sleep(1);
$target_ips_count = 0;
// For IPv4 use FILTER_FLAG_IPV4
$target_ips_count = count(array_filter($nodes, function($node) { return filter_var($node["ipaddress"], FILTER_VALIDATE_IP, FILTER_FLAG_IPV6); }));
} while (count($nodes) !== $target_ips_count);
```
Toutes les connexions client existantes qui ont été créées avant la mise à jour de la découverte d'adresses IP seront toujours connectées à l'aide de l'ancien protocole. Tous les clients validés se reconnecteront automatiquement au cluster à l'aide du nouveau protocole IP une fois que les modifications seront détectées dans la sortie des commandes de découverte du cluster. Cependant, cela dépend de la mise en œuvre du client.
## Clusters à double pile ElastiCache compatibles TLS
Lorsque TLS est activé pour les ElastiCache clusters, les fonctions de découverte de clusters (`cluster slots`,`cluster shards`, et `cluster nodes` pour Redis) ou `config get cluster` pour Memcached renvoient des noms d'hôte au lieu de. IPs Les noms d'hôtes sont ensuite utilisés au lieu de se IPs connecter au ElastiCache cluster et d'effectuer une poignée de main TLS. Cela signifie que les clients ne seront pas affectés par le paramètre de découverte d’adresses IP. Pour les clusters prenant en charge TLS, le paramètre de découverte d'adresses IP n'a aucun effet sur le protocole IP préféré. Au lieu de cela, le protocole IP utilisé sera déterminé par le protocole IP que le client préfère lors de la résolution des noms d'hôtes DNS.
**Clients Java**
Lorsque vous vous connectez à partir d'un environnement Java qui prend en charge IPv4 les deux IPv6, Java IPv4 privilégiera par défaut IPv6 la rétrocompatibilité. Toutefois, les arguments JVM permettent de configurer la préférence de protocole IP. Pour préférer IPv4, la JVM accepte `-Djava.net.preferIPv4Stack=true` et pour préférer, IPv6 définir`-Djava.net.preferIPv6Stack=true`. Le réglage `-Djava.net.preferIPv4Stack=true` signifie que la JVM n'établira plus aucune IPv6 connexion. **Pour Valkey ou Redis OSS, cela inclut ceux destinés à d'autres applications non-Valkey et non-Redis OSS.**
**Préférences au niveau de l'hôte**
En général, si le client ou l’environnement d’exécution du client ne fournit pas d’options de configuration permettant de définir une préférence de protocole IP, lors de la résolution DNS, le protocole IP dépendra de la configuration de l’hôte. Par défaut, la plupart des hôtes IPv6 préfèrent, IPv4 mais cette préférence peut être configurée au niveau de l'hôte. Cela affectera toutes les demandes DNS de cet hôte, et pas seulement celles adressées aux ElastiCache clusters.
**Hôtes Linux**
Pour Linux, une préférence de protocole IP peut être configurée en modifiant le fichier `gai.conf`. Le fichier `gai.conf` se trouve sous `/etc/gai.conf`. Si `gai.conf` n'est pas spécifié, un exemple doit être disponible sous `/usr/share/doc/glibc-common-x.xx/gai.conf`. Vous pouvez le copier sur `/etc/gai.conf` et la configuration par défaut doit être sans commentaire. Pour mettre à jour la configuration à privilégier IPv4 lors de la connexion à un ElastiCache cluster, mettez à jour la priorité de la plage d'adresses CIDR englobant le cluster IPs afin qu'elle soit supérieure à la priorité des connexions par défaut. IPv6 Par défaut, IPv6 les connexions ont une priorité de 40. Par exemple, en supposant que le cluster se trouve dans un sous-réseau dont le CIDR est 172.31.0. 0:0 /16, la configuration ci-dessous incitera les clients à préférer les connexions à ce cluster. IPv4
```
label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label fec0::/10 5
label fc00::/7 6
label 2001:0::/32 7
label ::ffff:172.31.0.0/112 8
#
# This default differs from the tables given in RFC 3484 by handling
# (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
# The reason for this difference is that these addresses are never
# NATed while IPv4 site-local addresses most probably are. Given
# the precedence of IPv6 over IPv4 (see below) on machines having only
# site-local IPv4 and IPv6 addresses a lookup for a global address would
# see the IPv6 be preferred. The result is a long delay because the
# site-local IPv6 addresses cannot be used while the IPv4 address is
# (at least for the foreseeable future) NATed. We also treat Teredo
# tunnels special.
#
# precedence
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#
precedence ::1/128 50
precedence ::/0 40
precedence 2002::/16 30
precedence ::/96 20
precedence ::ffff:0:0/96 10
precedence ::ffff:172.31.0.0/112 100
```
Plus de détails `gai.conf` sont disponibles sur la [page de manuel Linux](https://man7.org/linux/man-pages/man5/gai.conf.5.html)
**Hôtes Windows**
Le processus pour les hôtes Windows est similaire. Pour les hôtes Windows, vous pouvez exécuter `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL`. Cela a le même effet que la modification du fichier `gai.conf` sur les hôtes Linux.
Cela mettra à jour les politiques de préférence afin de préférer IPv4 les connexions aux IPv6 connexions pour la plage d'adresses CIDR spécifiée. Par exemple, en supposant que le cluster se trouve dans un sous-réseau avec le CIDR 172.31.0. 0:0 /16 en cours d'exécution, le tableau de priorité suivant `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15` s'affichera, ce qui incitera les clients à préférer se connecter au cluster. IPv4
```
C:\Users\Administrator>netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- --------------------------------
100 15 ::ffff:172.31.0.0:0/112
20 4 ::ffff:0:0/96
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
```
# Gestion de la mémoire réservée pour Valkey et Redis OSS
La mémoire réservée est mise de côté pour être utilisée à des fins autres que le traitement des données. Lors d'une sauvegarde ou d'un basculement, Valkey et Redis OSS utilisent la mémoire disponible pour enregistrer les opérations d'écriture sur votre cluster pendant que les données du cluster sont écrites dans le fichier .rdb. Si vous ne disposez pas de suffisamment de mémoire pour toutes les écritures, le processus échouera. Vous trouverez ci-dessous des informations sur les options de gestion de la mémoire réservée ElastiCache pour Redis OSS et sur la façon d'appliquer ces options.
**Topics**
+ [De quelle quantité de mémoire réservée avez-vous besoin ?](#redis-memory-management-need)
+ [Paramètres de gestion de la mémoire réservée](#redis-memory-management-parameters)
+ [Spécification de votre paramètre de gestion de la mémoire réservée](#redis-reserved-memory-management-change)
## De quelle quantité de mémoire réservée avez-vous besoin ?
Si vous utilisez une version de Redis OSS antérieure à la version 2.8.22, réservez plus de mémoire pour les sauvegardes et les basculements que si vous exécutez Redis OSS 2.8.22 ou version ultérieure. Cette exigence est due aux différentes manières dont ElastiCache Redis OSS implémente le processus de sauvegarde. La règle générale est de réserver la moitié de la `maxmemory` valeur d'un type de nœud pour la surcharge de Redis OSS pour les versions antérieures à 2.8.22, et un quart pour les versions 2.8.22 et ultérieures de Redis OSS.
En raison des différentes manières de ElastiCache mettre en œuvre le processus de sauvegarde et de réplication, la règle générale consiste à réserver 25 % de la `maxmemory` valeur d'un type de nœud en utilisant le `reserved-memory-percent` paramètre. Il s'agit de la valeur par défaut recommandée dans la plupart des cas.
Lorsque les microinstances et les petites instances burstables fonctionnent à un niveau proche de leurs `maxmemory` limites, il est possible qu'ils soient soumis à une utilisation du swap. Pour améliorer la fiabilité opérationnelle de ces types d'instances lors de la sauvegarde, de la réplication et d'un trafic élevé, nous recommandons d'augmenter la valeur du `reserved-memory-percent` paramètre jusqu'à 30 % pour les types d'instances de petite taille et jusqu'à 50 % pour les types de micro-instances.
Pour les charges de travail intensives en écriture sur des ElastiCache clusters avec hiérarchisation des données, nous recommandons d'augmenter jusqu'`reserved-memory-percent`à 50 % de la mémoire disponible du nœud.
Pour plus d’informations, consultez les ressources suivantes :
+ [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md)
+ [Implémentation de la sauvegarde et de la synchronisation](Replication.Redis.Versions.md)
+ [Hiérarchisation des données ElastiCache](data-tiering.md)
## Paramètres de gestion de la mémoire réservée
Depuis le 16 mars 2017, Amazon ElastiCache fournit deux paramètres mutuellement exclusifs pour gérer votre mémoire Valkey ou Redis OSS, et`reserved-memory`. `reserved-memory-percent` Aucun de ces paramètres ne fait partie de la distribution Valkey ou Redis OSS.
Selon le moment où vous êtes devenu ElastiCache client, l'un ou l'autre de ces paramètres est le paramètre de gestion de la mémoire par défaut. Ce paramètre s'applique lorsque vous créez un nouveau cluster ou groupe de réplication Valkey ou Redis OSS et que vous utilisez un groupe de paramètres par défaut.
+ Pour les clients qui ont commencé avant le 16 mars 2017 : lorsque vous créez un cluster Redis OSS ou un groupe de réplication à l'aide du groupe de paramètres par défaut, votre paramètre de gestion de la mémoire est `reserved-memory` Dans ce cas, zéro (0) octets de mémoire sont réservés.
+ Pour les clients qui ont commencé le 16 mars 2017 ou après cette date : lorsque vous créez un cluster ou un groupe de réplication Valkey ou Redis OSS à l'aide du groupe de paramètres par défaut, votre paramètre de gestion de la mémoire est `reserved-memory-percent` Dans ce cas, 25 % de la valeur `maxmemory` de votre nœud est réservée à des fins non liées aux données.
Après avoir pris connaissance des deux paramètres de gestion de la mémoire Valkey ou Redis OSS, vous préférerez peut-être utiliser celui qui n'est pas votre paramètre par défaut ou avec des valeurs autres que celles par défaut. Dans ce cas, vous pouvez passer à l'autre paramètre de gestion de la mémoire réservée.
Pour modifier la valeur de ce paramètre, vous pouvez créer un groupe de paramètres personnalisé et le modifier pour utiliser le paramètre et la valeur de gestion de la mémoire préférés. Vous pouvez ensuite utiliser le groupe de paramètres personnalisé chaque fois que vous créez un nouveau cluster Valkey ou Redis OSS ou un nouveau groupe de réplication. Pour les clusters ou les groupes de réplication existants, vous pouvez les modifier afin d'utiliser votre groupe de paramètres personnalisés.
Pour plus d'informations, veuillez consulter les ressources suivantes :
+ [Spécification de votre paramètre de gestion de la mémoire réservée](#redis-reserved-memory-management-change)
+ [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md)
+ [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md)
+ [Modification d'un ElastiCache cluster](Clusters.Modify.md)
+ [Modification d'un groupe de réplication](Replication.Modify.md)
### Paramètre reserved-memory
Avant le 16 mars 2017, toute la gestion de ElastiCache la mémoire réservée à Redis OSS était effectuée à l'aide du paramètre`reserved-memory`. La valeur par défaut de `reserved-memory` est 0. Cette valeur par défaut ne réserve aucune mémoire pour la surcharge de Valkey ou Redis OSS et permet à Valkey ou Redis OSS de consommer toute la mémoire d'un nœud en données.
Pour pouvoir modifier `reserved-memory` afin de disposer d'une quantité de mémoire suffisante pour les sauvegardes et les basculements, vous devez créer un groupe de paramètres personnalisé. Dans ce groupe de paramètres personnalisés, vous définissez une valeur adaptée `reserved-memory` à la version de Valkey ou Redis OSS exécutée sur votre cluster et au type de nœud du cluster. Pour de plus amples informations, consultez [De quelle quantité de mémoire réservée avez-vous besoin ?](#redis-memory-management-need).
Le paramètre `reserved-memory` est spécifique à la distribution générale de Redis OSS ElastiCache et ne fait pas partie de celle-ci.
La procédure suivante montre comment gérer la mémoire `reserved-memory` de votre cluster Valkey ou Redis OSS.
**Pour réserver de la mémoire à l'aide de la mémoire réservée**
1. Créez un groupe de paramètres personnalisé spécifiant la famille de groupe de paramètres correspondant à la version de moteur exécutée par exemple, la famille de groupe de paramètres `redis2.8`. Pour de plus amples informations, veuillez consulter [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md).
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name redis6x-m3xl \
--description "Redis OSS 2.8.x for m3.xlarge node type" \
--cache-parameter-group-family redis6.x
```
1. Calculez le nombre d'octets de mémoire à réserver pour la surcharge de Valkey ou Redis OSS. Vous pouvez trouver la valeur de `maxmemory` du type de nœud dans [Paramètres spécifiques au type de nœud Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
1. Modifiez le groupe de paramètres personnalisé de façon à ce que le paramètre `reserved-memory` corresponde au nombre d'octets calculé au cours de la première étape. L' AWS CLI exemple suivant suppose que vous exécutez une version de Redis OSS antérieure à la version 2.8.22 et que vous devez réserver la moitié de celle du nœud. `maxmemory` Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=7130316800"
```
Notez que vous avez besoin d'un groupe de paramètres personnalisé distinct pour chaque nœud utilisé dans la mesure où chaque type de nœud a une valeur `maxmemory` différente. Par conséquent, chaque type de nœud a besoin d'une valeur différente pour `reserved-memory`.
1. Modifiez votre cluster Redis OSS ou votre groupe de réplication pour utiliser votre groupe de paramètres personnalisé.
L'exemple de la CLI suivant modifie le cluster ` my-redis-cluster` afin qu'il utilise le groupe de paramètres personnalisé `redis28-m3xl` immédiatement. Pour de plus amples informations, veuillez consulter [Modification d'un ElastiCache cluster](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
L'exemple de la CLI suivant modifie le groupe de réplication `my-redis-repl-grp` afin qu'il utilise le groupe de paramètres personnalisé `redis28-m3xl` immédiatement. Pour plus d’informations, consultez [Modification d'un groupe de réplication](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
### Paramètre reserved-memory-percent
Le 16 mars 2017, Amazon ElastiCache a introduit le paramètre `reserved-memory-percent` et l'a rendu disponible sur toutes les versions de ElastiCache pour Redis OSS. L'objectif de `reserved-memory-percent` est de simplifier la gestion de la mémoire réservée sur tous vos clusters. Vous avez ainsi la possibilité d'avoir un seul groupe de paramètres pour chaque famille de groupe de paramètres (par exemple, `redis2.8`) afin de gérer la mémoire réservée de votre cluster, quel que soit le type de nœud. La valeur par défaut de `reserved-memory-percent` est 25 (25 %).
Le paramètre `reserved-memory-percent` est spécifique à la distribution générale de Redis OSS ElastiCache et ne fait pas partie de celle-ci.
Si votre cluster utilise un type de nœud de la famille r6gd et que votre utilisation de la mémoire atteint 75 %, la hiérarchisation des données sera automatiquement déclenchée. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
**Pour réserver de la mémoire en utilisant reserved-memory-percent**
`reserved-memory-percent`Pour gérer la mémoire de votre ElastiCache cluster Redis OSS, effectuez l'une des opérations suivantes :
+ Si vous utilisez Redis OSS 2.8.22 ou version ultérieure, attribuez le groupe de paramètres par défaut à votre cluster. Les 25 % par défaut devraient convenir. Si tel n'est pas le cas, procédez comme suit pour modifier la valeur.
+ Si vous utilisez une version de Redis OSS antérieure à la version 2.8.22, vous devrez probablement réserver plus de mémoire que la valeur par défaut `reserved-memory-percent` de 25 %. Pour cela, procédez comme suit.
**Pour modifier la valeur en pourcentage de reserved-memory-percent**
1. Créez un groupe de paramètres personnalisé spécifiant la famille de groupe de paramètres correspondant à la version de moteur exécutée par exemple, la famille de groupe de paramètres `redis2.8`. Un groupe de paramètres personnalisé est nécessaire car vous ne pouvez pas modifier un groupe de paramètres par défaut. Pour de plus amples informations, veuillez consulter [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md).
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name redis28-50 \
--description "Redis OSS 2.8.x 50% reserved" \
--cache-parameter-group-family redis2.8
```
Dans la mesure où `reserved-memory-percent` réserve de la mémoire sous forme de pourcentage du paramètre `maxmemory` d'un nœud, vous n'avez pas besoin d'un groupe de paramètres personnalisé pour chaque type de nœud.
1. Modifiez le groupe de paramètres personnalisé afin que le paramètre `reserved-memory-percent` soit défini sur 50 (50 %). Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-50 \
--parameter-name-values "ParameterName=reserved-memory-percent, ParameterValue=50"
```
1. Utilisez ce groupe de paramètres personnalisé pour tous les clusters ou groupes de réplication Redis OSS exécutant une version de Redis OSS antérieure à 2.8.22.
L'exemple de CLI suivant modifie le cluster Redis OSS `my-redis-cluster` pour utiliser le groupe de paramètres personnalisés `redis28-50` commençant immédiatement. Pour de plus amples informations, veuillez consulter [Modification d'un ElastiCache cluster](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
L'exemple de CLI suivant modifie le groupe de réplication Redis OSS `my-redis-repl-grp` pour utiliser le groupe de paramètres personnalisés `redis28-50` commençant immédiatement. Pour de plus amples informations, veuillez consulter [Modification d'un groupe de réplication](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
## Spécification de votre paramètre de gestion de la mémoire réservée
Si vous étiez un ElastiCache client actuel le 16 mars 2017, votre paramètre de gestion de mémoire réservée par défaut est `reserved-memory` de zéro (0) octet de mémoire réservée. Si vous êtes devenu ElastiCache client après le 16 mars 2017, votre paramètre de gestion de la mémoire réservée par défaut est `reserved-memory-percent` de réserver 25 % de la mémoire du nœud. Cela est vrai quelle que soit la date à laquelle vous avez créé votre cluster ou groupe de réplication ElastiCache pour Redis OSS. Cependant, vous pouvez modifier le paramètre de gestion de la mémoire réservée à l'aide de l' ElastiCache API AWS CLI or.
Les paramètres `reserved-memory` et `reserved-memory-percent` sont mutuellement exclusifs. Un groupe de paramètres est toujours associé à un paramètre, mais jamais aux deux. Vous pouvez modifier le paramètre utilisé par un groupe de paramètres pour la gestion de la mémoire réservée en modifiant le groupe de paramètres. Le groupe de paramètres doit être un groupe de paramètres personnalisé, car vous ne pouvez pas modifier les groupes de paramètres par défaut. Pour de plus amples informations, veuillez consulter [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md).
**Pour spécifier reserved-memory-percent**
Pour utiliser `reserved-memory-percent` comme paramètre de gestion de la mémoire réservée, modifiez un groupe de paramètres personnalisés à l'aide de la commande `modify-cache-parameter-group`. Utilisez le paramètre `parameter-name-values` pour spécifier `reserved-memory-percent` et une valeur pour cela.
L'exemple de la CLI suivant modifie le groupe de paramètres personnalisé `redis32-cluster-on` afin qu'il utilise `reserved-memory-percent` pour gérer la mémoire réservée. Une valeur doit être affectée à `ParameterValue` pour que le groupe de paramètres utilise le paramètre `ParameterName` pour la gestion de la mémoire réservée. Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-cluster-on \
--parameter-name-values "ParameterName=reserved-memory-percent, ParameterValue=25"
```
**Pour spécifier reserved-memory**
Pour utiliser `reserved-memory` comme paramètre de gestion de la mémoire réservée, modifiez un groupe de paramètres personnalisés à l'aide de la commande `modify-cache-parameter-group`. Utilisez le paramètre `parameter-name-values` pour spécifier `reserved-memory` et une valeur pour cela.
L'exemple de la CLI suivant modifie le groupe de paramètres personnalisé `redis32-m3xl` afin qu'il utilise `reserved-memory` pour gérer la mémoire réservée. Une valeur doit être affectée à `ParameterValue` pour que le groupe de paramètres utilise le paramètre `ParameterName` pour la gestion de la mémoire réservée. Comme la version du moteur est plus récente que la version 2.8.22, nous définissons la valeur sur `3565158400`, soit 25 % de `maxmemory` du `cache.m3.xlarge`. Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=3565158400"
```
# Meilleures pratiques lors de l'utilisation de clusters basés sur des nœuds Valkey et Redis OSS
L'utilisation de plusieurs AZ, le fait de disposer d'une mémoire suffisante, le redimensionnement des clusters et la minimisation des temps d'arrêt sont autant de concepts utiles à garder à l'esprit lorsque vous travaillez avec des clusters basés sur des nœuds dans Valkey ou Redis OSS. Nous vous recommandons de consulter et de suivre les bonnes pratiques suivantes.
**Topics**
+ [Réduction des temps d'arrêt avec Multi-AZ](multi-az.md)
+ [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md)
+ [Redimensionnement de cluster en ligne](best-practices-online-resharding.md)
+ [Réduction au maximum des temps d’arrêt pendant la maintenance](BestPractices.MinimizeDowntime.md)
# Réduction des temps d'arrêt avec Multi-AZ
Dans un certain nombre de cas, ElastiCache Valkey ou Redis OSS peuvent avoir besoin de remplacer un nœud principal ; il s'agit notamment de certains types de maintenance planifiée et de l'éventualité peu probable d'une défaillance d'un nœud principal ou d'une zone de disponibilité.
Ce remplacement entraîne un certain temps d'arrêt pour le cluster, mais si Multi-AZ est activé, le temps d'arrêt est réduit. Le rôle du nœud primaire bascule automatiquement sur l'un des réplicas en lecture. Il n'est pas nécessaire de créer et de provisionner un nouveau nœud principal, car il ElastiCache gérera cela de manière transparente. Ce basculement et la promotion d'un réplica vous permettent de recommencer à écrire dans le nouveau nœud principal dès que la promotion est terminée.
Consultez[Minimiser les temps d'arrêt en ElastiCache utilisant le multi-AZ avec Valkey et Redis OSS](AutoFailover.md), pour en savoir plus sur le multi-AZ et la réduction des temps d'arrêt.
# S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS
**Instantanés et synchronisations dans Valkey 7.2 et versions ultérieures, et Redis OSS version 2.8.22 et versions ultérieures**
Valkey prend en charge par défaut les instantanés et les synchronisations. Redis OSS 2.8.22 introduit un processus de sauvegarde sans fourche qui vous permet d'allouer une plus grande partie de votre mémoire à l'utilisation de votre application sans augmenter l'utilisation des swap lors des synchronisations et des sauvegardes. Pour de plus amples informations, veuillez consulter [Implémentation de la sauvegarde et de la synchronisation](Replication.Redis.Versions.md).
**Instantanés et synchronisations Redis OSS antérieurs à la version 2.8.22**
Lorsque vous travaillez avec ElastiCache Redis OSS, Redis OSS appelle une commande d'écriture en arrière-plan dans un certain nombre de cas :
+ Lorsque de la création d'un instantané pour une sauvegarde.
+ Lors de la synchronisation de réplicas avec le réplica principal dans un groupe de réplication.
+ Lorsque vous activez la fonctionnalité d'ajout de fichier uniquement (AOF) pour Redis OSS.
+ Lors la promotion d'un réplica en tant que maître (qui entraîne une synchronisation du réplica principal/réplica).
Chaque fois que Redis OSS exécute un processus d'écriture en arrière-plan, vous devez disposer de suffisamment de mémoire disponible pour faire face à la surcharge du processus. Si vous ne disposez pas de suffisamment de mémoire, le processus échoue. Pour cette raison, il est important de choisir un type d'instance de nœud disposant de suffisamment de mémoire lors de la création de votre cluster Redis OSS.
## Processus d'écriture en arrière-plan et utilisation de la mémoire avec Valkey et Redis OSS
Chaque fois qu'un processus d'écriture en arrière-plan est appelé, Valkey et Redis OSS modifient son processus (n'oubliez pas que ces moteurs sont à thread unique). Un fork conserve vos données sur le disque dans un fichier instantané Redis OSS .rdb. L'autre fork traite toutes les opérations de lecture et d'écriture. Pour garantir que votre instantané est un point-in-time instantané, toutes les mises à jour et tous les ajouts de données sont écrits dans une zone de mémoire disponible distincte de la zone de données.
Tant que vous disposez de suffisamment de mémoire pour enregistrer toutes les opérations d'écriture pendant le stockage des données sur le disque, vous n'aurez pas de problème de mémoire insuffisante. Vous risquez d'avoir des problèmes de mémoire insuffisante si l'une des affirmations suivantes est vraie :
+ Votre application effectue de nombreuses opérations d'écriture, nécessitant une grande quantité de mémoire disponible pour accepter les données mises à jour ou nouvelles.
+ Vous disposez de très peu de mémoire disponible pour pouvoir écrire de nouvelles données ou mettre à jour des données.
+ Stocker durablement sur le disque votre jeu de données volumineux prend du temps car cela nécessite un grand nombre d'opérations d'écriture.
Le schéma suivant représente l'utilisation de la mémoire lors de l'exécution d'un processus d'écriture en arrière-plan.
![\[Image : Schéma d'utilisation de la mémoire lors d'un processus d'écriture en arrière-plan.\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-bgsaveMemoryUseage.png)
Pour obtenir des informations sur l'impact d'une sauvegarde sur les performances, consultez [Impact sur les performances des sauvegardes de clusters basés sur des nœuds](backups.md#backups-performance).
[Pour plus d'informations sur la façon dont Valkey et Redis OSS exécutent les snapshots, consultez http://valkey.io.](http://valkey.io)
Pour plus d'informations sur les régions et les zones de disponibilité, consultez [Choix des régions et des zones de disponibilité pour ElastiCache](RegionsAndAZs.md).
## Eviter tout dépassement de mémoire lors de l'exécution d'un processus d'écriture en arrière-plan
Chaque fois qu'un processus d'écriture en arrière-plan tel que `BGSAVE` ou `BGREWRITEAOF` est appelé, pour éviter l'échec du processus, vous devez disposer de plus de mémoire disponible que celle qui sera consommée par les opérations d'écriture pendant le processus. Dans le pire des cas, pendant l'opération d'écriture en arrière-plan, chaque enregistrement est mis à jour et de nouveaux enregistrements sont ajoutés au cache. `reserved-memory-percent`Pour cette raison, nous vous recommandons de définir la valeur 50 (50 %) pour les versions de Redis OSS antérieures à la version 2.8.22, ou 25 (25 %) pour Valkey et toutes les versions de Redis OSS 2.8.22 et ultérieures.
La valeur `maxmemory` indique que la mémoire dont vous disposez pour le traitement des données et la surcharge opérationnelle. Etant donné que vous ne pouvez pas modifier le paramètre `reserved-memory` dans le groupe de paramètres par défaut, vous devez créer un groupe de paramètres personnalisés pour le cluster. La valeur par défaut `reserved-memory` est 0, ce qui permet à Redis OSS de consommer toute la *mémoire maximale associée* aux données, laissant potentiellement trop peu de mémoire pour d'autres utilisations, telles qu'un processus d'écriture en arrière-plan. Pour les valeurs `maxmemory` par type d'instance de nœud, consultez [Paramètres spécifiques au type de nœud Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
Vous pouvez également utiliser le `reserved-memory` paramètre pour réduire la quantité de mémoire utilisée sur le boîtier.
Pour plus d'informations sur les paramètres spécifiques à Valkey et Redis dans, consultez. ElastiCache [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis)
Pour plus d'informations sur la création et la modification des groupes de paramètres, consultez [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md) et [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
# Redimensionnement de cluster en ligne
Le *repartitionnement * implique l'ajout de partitions ou de nœuds à votre cluster, ou leur suppression, et la redistribution des espaces clés. En conséquence, plusieurs aspects peuvent avoir un impact sur l'opération de repartitionnement, tels que la charge sur le cluster, l'utilisation de la mémoire et la taille globale des données. Pour bénéficier de la meilleure expérience possible, il est recommandé de suivre les bonnes pratiques générales relatives au cluster en vue d'une distribution uniforme des modèles de charge de travail. En outre, il est recommandé de respecter les étapes suivantes.
Avant de lancer le repartitionnement, procédez comme suit :
+ **Testez votre application** – Testez le comportement de votre application lors du repartitionnement dans un environnement intermédiaire si possible.
+ **Obtenez une notification anticipée pour les problèmes de mise à l'échelle** – Le repartitionnement est une opération gourmande en calculs. C'est pourquoi nous recommandons de maintenir l'utilisation du processeur en dessous de 80 % sur les instances multicœurs et à moins de 50 % sur les instances monocœurs lors du repartage. Surveillez ElastiCache les métriques Redis OSS et initiez le repartage avant que votre application ne commence à détecter des problèmes de dimensionnement. Les métriques qu'il est utile de suivre sont `CPUUtilization`, `NetworkBytesIn`, `NetworkBytesOut`, `CurrConnections`, `NewConnections`, `FreeableMemory`, `SwapUsage` et `BytesUsedForCacheItems`.
+ **Assurez-vous qu'une mémoire suffisante est disponible avant de procéder à une diminution d'échelle** – Si vous procédez à une diminution d'échelle, assurez-vous que cette mémoire disponible sur les partitions à conserver est au moins égale à une fois et demi la mémoire utilisée sur les partitions que vous prévoyez de supprimer.
+ **Initiez le repartitionnement pendant les heures creuses** – Cette pratique permet de réduire l'impact de la latence et du débit sur le client pendant l'opération de repartitionnement. Elle permet aussi d'exécuter le repartitionnement plus rapidement, car un plus grand nombre de ressources peut être utilisé pour la redistribution des emplacements.
+ **Vérifiez le comportement hors délai du client** – Certains clients peuvent observer une latence plus élevée lors d'un redimensionnement des clusters en ligne. La configuration de votre bibliothèque client avec un délai d'expiration supérieur peut être une aide en offrant au système le temps de se connecter même en cas de conditions de charge plus importantes sur le serveur. Dans certains cas, vous pouvez ouvrir un grand nombre de connexions sur le serveur. Dans ces cas, pensez à ajouter un backoff exponentiel à la logique de reconnexion. Cela peut empêcher qu'une rafale de nouvelles connexions atteignent le serveur simultanément.
+ **Chargez vos fonctions sur chaque partition** : lorsque vous agrandissez votre cluster, les fonctions chargées dans l'un des nœuds existants (sélectionnées au hasard) ElastiCache seront automatiquement répliquées sur le ou les nouveaux nœuds. Si votre cluster possède Valkey 7.2 ou une version ultérieure, ou Redis OSS 7.0 ou une version ultérieure, et que votre application utilise [Functions](https://valkey.io/topics/functions-intro/), nous vous recommandons de charger toutes vos fonctions sur toutes les partitions avant de les redimensionner afin que votre cluster ne se retrouve pas avec des fonctions différentes sur différentes partitions.
Après le repartitionnement, notez ce qui suit :
+ La diminution d'échelle peut être partiellement réussie si la mémoire sur les partitions cibles est insuffisante. Si un tel résultat se produit, vérifiez la mémoire disponible et réessayez l'opération, si nécessaire. Les données des partitions cibles ne seront pas supprimées.
+ Les commandes `FLUSHALL` et `FLUSHDB` ne sont pas prises en charge dans les scripts Lua lors d’une opération de repartitionnement. Avant Redis OSS 6, la `BRPOPLPUSH` commande n'est pas prise en charge si elle fonctionne sur le slot en cours de migration.
# Réduction au maximum des temps d’arrêt pendant la maintenance
La configuration en mode cluster présente la meilleure disponibilité pendant les opérations gérées ou non gérées. Nous vous recommandons d'utiliser un client pris en charge en mode cluster qui se connecte au point de terminaison de détection des clusters. Pour le mode cluster désactivé, nous vous recommandons d'utiliser le point de terminaison principal pour toutes les opérations d'écriture.
Pour l'activité de lecture, les applications peuvent également se connecter à n'importe quel nœud du cluster. Contrairement au point de terminaison principal, les points de terminaison des nœuds sont résolus dans des points de terminaison spécifiques. En cas de modification dans votre cluster, comme l'ajout ou la suppression d'un réplica, vous devez mettre à jour les points de terminaison des nœuds de votre application. C’est la raison pour laquelle, en mode cluster désactivé, nous vous recommandons d’utiliser le point de terminaison du lecteur pour les activités de lecture.
S' AutoFailover il est activé dans le cluster, le nœud principal peut changer. Ainsi, l'application doit confirmer le rôle du nœud et mettre à jour tous les points de terminaison en lecture. Cette étape permet de garantir qu'une charge majeure n'est pas imposée sur le nœud principal. Lorsque AutoFailover cette option est désactivée, le rôle du nœud ne change pas. Cependant, le temps d'arrêt des opérations gérées ou non gérées est plus élevé que celui des clusters AutoFailover activés.
Évitez de diriger les demandes de lecture vers un seul nœud de réplica en lecture, car son indisponibilité pourrait entraîner une interruption de lecture. Revenez à la lecture depuis le nœud primaire ou assurez-vous de disposer d’au moins deux réplicas en lecture pour éviter toute interruption de lecture pendant la maintenance.
# Stratégies de mise en cache pour Memcached
Dans la rubrique suivante, vous trouverez des stratégies pour remplir et gérer votre cache Memcached.
La ou les stratégies que vous souhaitez mettre en œuvre pour remplir et assurer la maintenance de votre cache dépendent des données vous avez mises en cache et des modèles d'accès aux données. Par exemple, vous ne souhaiterez sans doute pas utiliser la même stratégie pour le top 10 d'un jeu sur Internet ou pour des sujets d'actualité. Dans le reste de cette section, nous aborderons les stratégies de maintenance de cache courantes, leurs avantages et leurs inconvénients.
**Topics**
+ [Réplicas en lecture](#Strategies.ReadReplicas)
+ [Chargement différé](#Strategies.LazyLoading)
+ [Écriture simultanée](#Strategies.WriteThrough)
+ [Ajout d'une durée de vie](#Strategies.WithTTL)
+ [Rubriques en relation](#Strategies.SeeAlso)
## Réplicas en lecture
Vous pouvez souvent améliorer de manière significative les performances des caches ElastiCache sans serveur en créant des répliques et en les lisant au lieu du nœud de cache principal. Pour de plus amples informations, veuillez consulter [Bonnes pratiques d'utilisation des répliques de lecture](ReadReplicas.md).
## Chargement différé
Comme le nom l'indique, un *chargement différé* correspond à une stratégie de mise en cache qui charge des données dans la mémoire cache uniquement lorsque c'est nécessaire. Cela fonctionne comme décrit ci-dessous.
Amazon ElastiCache est un magasin clé-valeur en mémoire situé entre votre application et le magasin de données (base de données) auquel elle accède. Chaque fois que votre application demande des données, elle les envoie d'abord au ElastiCache cache. Si les données existent dans le cache et sont à jour, ElastiCache renvoie les données dans votre application. Si les données n'existent pas dans le cache ou ont expiré, votre application demande les données à partir de votre magasin de données. Votre magasin de données renvoie ensuite les données à votre application. Votre application enregistre les données reçues du magasin dans le cache. De cette façon, elles peuvent être récupérées plus rapidement la prochaine fois qu'elles sont demandées.
Une *correspondance avec le cache* se produit lorsque les données sont dans le cache et n'ont pas expiré :
1. L'application demande des données dans le cache.
1. Le cache retourne les données à l'application.
Une *absence de données dans le cache* se produit lorsque les données ne sont pas dans le cache ou ont expiré :
1. L'application demande des données dans le cache.
1. Le cache n'a pas les données demandées, un code `null` est donc retourné.
1. L'application demande et reçoit les données à partir de la base de données.
1. L'application met à jour le cache avec les nouvelles données.
### Avantages et inconvénients du chargement différé
Les avantages du chargement différé sont les suivants :
+ Seules les données demandées sont mises en cache.
Dans la mesure où la plupart des données ne sont jamais demandées, le chargement différé évite de remplir le cache avec des données qui ne sont pas nécessaires.
+ Les défaillances de nœud ne sont pas fatales pour votre application.
Lorsqu'un nœud échoue et qu'il est remplacé par un nœud vide, l'application continue à fonctionner, mais avec une latence accrue. Lorsque les requêtes sont effectuées vers le nouveau nœud, chaque échec de cache entraîne une requête dans la base de données. En même temps, la copie de données est ajoutée au cache afin que les requêtes suivantes soient récupérées à partir du cache.
Les inconvénients du chargement différé sont les suivants :
+ Il y a une pénalité pour les échecs de cache. Chaque échec de cache génère 3 sorties :
1. Une demande initiale de données à partir du cache
1. Une requête pour les données dans la base de données
1. L'enregistrement des données dans le cache
Ce qui peut générer un retard notable dans l'acheminement des données vers l'application.
+ Données obsolètes.
Si les données sont écrites dans le cas d'un échec de cache, les données du cache deviennent périmées. Ce résultat se produit car il n'y a pas de mise à jour dans le cache quand les données sont modifiées dans la base de données. Pour résoudre ce problème, vous pouvez utiliser les stratégies [Écriture simultanée](#Strategies.WriteThrough) et [Ajout d'une durée de vie](#Strategies.WithTTL).
### Exemple de pseudocode de chargement différé
Le code suivant est un exemple de pseudo-code de la logique d'un chargement différé.
```
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
// retrieved from the database,
// added to the cache, and
// returned to the application
// *****************************************
get_customer(customer_id)
customer_record = cache.get(customer_id)
if (customer_record == null)
customer_record = db.query("SELECT * FROM Customers WHERE id = {0}", customer_id)
cache.set(customer_id, customer_record)
return customer_record
```
Dans cet exemple, le code d'application qui obtient les données est le suivant.
```
customer_record = get_customer(12345)
```
## Écriture simultanée
La stratégie d'écriture simultanée permet d'ajouter des données et de mettre à jour les données du cache dès que des données sont enregistrées dans la base de données.
### Avantages et les inconvénients de l'écriture simultanée
Les avantages de l'écriture simultanée sont les suivants :
+ Les données dans le cache ne se périment jamais.
Dans la mesure où les données dans le cache sont mises à jour à chaque enregistrement dans la base de données, les données dans le cache sont toujours actuelles.
+ Pénalité d'écriture vs pénalité de lecture.
Chaque écriture implique deux sorties :
1. Une écriture dans le cache
1. Une écriture dans la base de données
Ce qui ajoute une latence pour le processus. Cela dit, les utilisateurs finaux acceptent généralement plus facilement la latence lors de l'actualisation que lors de la récupération des données. On sait communément que les mises à jour demandent plus de travail et donc prennent plus de temps.
Les inconvénients de l'écriture simultanée sont les suivants :
+ Données manquantes.
Si vous mettez en service un nouveau nœud, que ce soit en raison d'une panne de nœud ou d'une mise à l'échelle, il y a des données manquantes. Ces données restent manquantes jusqu'à ce qu'elles soient ajoutées ou mises à jour dans la base de données. Vous pouvez minimiser cela en implémentant le [chargement différé](#Strategies.LazyLoading) avec l'écriture simultanée.
+ Evolution du cache.
La plupart des données ne sont jamais lues, ce qui est un gaspillage de ressources. En [ajoutant une valeur de time to live (TTL)](#Strategies.WithTTL), vous pouvez minimiser l'espace perdu.
### Exemple de pseudocode d'écriture simultanée
Le code suivant est un exemple de pseudo-code de logique d'écriture simultanée.
```
// *****************************************
// function that saves a customer's record.
// *****************************************
save_customer(customer_id, values)
customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
cache.set(customer_id, customer_record)
return success
```
Dans cet exemple, le code d'application qui obtient les données est le suivant.
```
save_customer(12345,{"address":"123 Main"})
```
## Ajout d'une durée de vie
Le chargement différé permet l'existence de données obsolètes, mais n'échouera pas sur les nœuds vides. L'écriture simultanée garantit que les données sont toujours parfaitement à jour, mais peuvent échouer sur des nœuds vides et remplir le cache de données superflues. En ajoutant une time to live (TTL) à chaque écriture, vous pouvez avoir les avantages de chaque stratégie. En même temps, vous pouvez et en grande partie éviter d'encombrer le cache avec des données supplémentaires.
*Le temps de vie (TTL)* est une valeur entière qui indique le nombre de secondes avant l'expiration de la clé. Valkey ou Redis OSS peuvent spécifier des secondes ou des millisecondes pour cette valeur. Memcached spécifie cette valeur en secondes. Lorsqu'une application tente de lire une clé expirée, c'est comme si la clé était introuvable. La base de données est interrogée pour la clé et le cache est mis à jour. Cette approche ne garantit pas qu'une valeur n'est pas obsolète. Cependant, il empêche les données de devenir trop anciennes et exige que les valeurs du cache soient occasionnellement rafraîchies à partir de la base de données.
Pour plus d'informations, consultez les commandes [Valkey et Redis OSS ou les commandes `set`](https://valkey.io/commands) [Memcached](https://www.tutorialspoint.com/memcached/memcached_set_data.htm).
### Exemples de pseudocode TTL
Le code suivant est un exemple de pseudo-code de logique d'écriture simultanée comportant un un time to live.
```
// *****************************************
// function that saves a customer's record.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and future reads will have to query the database.
// *****************************************
save_customer(customer_id, values)
customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
cache.set(customer_id, customer_record, 300)
return success
```
Le code suivant est un exemple de pseudo-code de logique de chargement différé comportant un time to live.
```
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
// retrieved from the database,
// added to the cache, and
// returned to the application.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and subsequent reads will have to query the database.
// *****************************************
get_customer(customer_id)
customer_record = cache.get(customer_id)
if (customer_record != null)
if (customer_record.TTL < 300)
return customer_record // return the record and exit function
// do this only if the record did not exist in the cache OR
// the TTL was >= 300, i.e., the record in the cache had expired.
customer_record = db.query("SELECT * FROM Customers WHERE id = {0}", customer_id)
cache.set(customer_id, customer_record, 300) // update the cache
return customer_record // return the newly retrieved record and exit function
```
Dans cet exemple, le code d'application qui obtient les données est le suivant.
```
save_customer(12345,{"address":"123 Main"})
```
```
customer_record = get_customer(12345)
```
## Rubriques en relation
+ [Stockage de données en mémoire](elasticache-use-cases.md#elasticache-use-cases-data-store)
+ [Choix d’un moteur et d’une version](SelectEngine.md)
+ [Dimensionnement ElastiCache](Scaling.md)
# Gestion de votre cluster basé sur des nœuds dans ElastiCache
ElastiCache propose deux options de déploiement, des caches sans serveur et des clusters basés sur des nœuds. Chacun a ses propres capacités et exigences.
Cette section contient des rubriques qui vous aideront à gérer vos clusters basés sur des nœuds.
**Note**
Ces rubriques ne s'appliquent pas à ElastiCache Serverless.
**Topics**
+ [Clusters Auto Scaling Valkey et Redis OSS](AutoScaling.md)
+ [Modification du mode cluster](modify-cluster-mode.md)
+ [Réplication entre AWS régions à l'aide de banques de données mondiales](Redis-Global-Datastore.md)
+ [Haute disponibilité avec les groupes de réplication](Replication.md)
+ [Gestion de la maintenance des ElastiCache clusters](maintenance-window.md)
+ [Configuration des paramètres du moteur à l'aide de groupes de ElastiCache paramètres](ParameterGroups.md)
# Clusters Auto Scaling Valkey et Redis OSS
## Conditions préalables
ElastiCache Auto Scaling se limite aux éléments suivants :
+ Clusters Valkey ou Redis OSS (mode cluster activé) exécutant Valkey 7.2 et versions ultérieures, ou Redis OSS 6.0 et versions ultérieures
+ Hiérarchisation des données (mode cluster activé) clusters exécutant Valkey 7.2 ou version ultérieure de Redis OSS 7.0.7
+ Tailles d'instance : grande XLarge, 2 XLarge
+ Familles de types d’instances : R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn
+ Auto Scaling in n' ElastiCache est pas pris en charge pour les clusters exécutés dans des banques de données mondiales, des Outposts ou des Zones Locales.
## Gestion automatique de la capacité avec ElastiCache Auto Scaling avec Valkey ou Redis OSS
ElastiCache la mise à l'échelle automatique avec Valkey ou Redis OSS permet d'augmenter ou de diminuer automatiquement les partitions ou les répliques souhaitées dans votre service. ElastiCache ElastiCache utilise le service Application Auto Scaling pour fournir cette fonctionnalité. Pour en savoir plus, veuillez consulter [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Pour utiliser le dimensionnement automatique, vous définissez et appliquez une politique de dimensionnement qui utilise CloudWatch les métriques et les valeurs cibles que vous attribuez. ElastiCache Auto Scaling utilise la politique pour augmenter ou diminuer le nombre d'instances en réponse aux charges de travail réelles.
Vous pouvez utiliser le AWS Management Console pour appliquer une politique de dimensionnement basée sur une métrique prédéfinie. Une métrique `predefined metric` est définie dans une énumération de telle sorte que vous pouvez la spécifier par son nom dans le code ou l'utiliser dans la AWS Management Console. Les métriques personnalisées ne sont pas disponibles pour la sélection à l'aide de la AWS Management Console. Vous pouvez également utiliser l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling pour appliquer une politique de dimensionnement basée sur une métrique prédéfinie ou personnalisée.
ElastiCache pour Valkey et Redis, OSS prend en charge le dimensionnement pour les dimensions suivantes :
+ **Partitions** – Ajouter/supprime automatiquement des partitions dans le cluster de manière similaire au repartitionnement manuel en ligne. Dans ce cas, le dimensionnement ElastiCache automatique déclenche le dimensionnement en votre nom.
+ **Répliques** — add/remove replicas in the cluster similar to manual Increase/Decrease replica operations. ElastiCache auto scaling for Valkey and Redis OSS adds/removes Réplique automatiquement et de manière uniforme sur toutes les partitions du cluster.
ElastiCache pour Valkey et Redis OSS prend en charge les types de politiques de dimensionnement automatique suivants :
+ [Politiques de dimensionnement Suivi de la cible](AutoScaling-Scaling-Policies-Target.md)— Augmentez ou diminuez le nombre shards/replicas d'exécutions de votre service en fonction d'une valeur cible pour une métrique spécifique. Cette option est similaire à la façon dont votre thermostat maintient la température de votre domicile. Vous sélectionnez une température et le thermostat se charge du reste.
+ [Dimensionnement planifié pour votre application.](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) — ElastiCache pour Valkey et Redis OSS, le dimensionnement automatique peut augmenter ou diminuer le nombre d'exécutions de shards/replicas votre service en fonction de la date et de l'heure.
![\[Image de la mise à l'échelle automatique ElastiCache pour Valkey et Redis OSS\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/Auto-scaling.png)
Les étapes suivantes résument le processus de mise à l'échelle automatique ElastiCache pour Valkey et Redis OSS, comme indiqué dans le schéma précédent :
1. Vous créez une politique de dimensionnement ElastiCache automatique pour votre groupe de réplication.
1. ElastiCache Auto Scaling crée une paire d' CloudWatch alarmes en votre nom. Chaque paire représente vos limites supérieure et inférieure pour les métriques. Ces CloudWatch alarmes sont déclenchées lorsque l'utilisation réelle du cluster s'écarte de votre utilisation cible pendant une période prolongée. Vous pouvez afficher les alarmes dans la console.
1. Si la valeur de mesure configurée dépasse votre objectif d'utilisation (ou tombe en dessous de l'objectif) pendant une période donnée, CloudWatch déclenche une alarme qui déclenche le dimensionnement automatique pour évaluer votre politique de dimensionnement.
1. ElastiCache Auto Scaling émet une demande de modification pour ajuster la capacité de votre cluster.
1. ElastiCache traite la demande de modification en augmentant (ou en diminuant) dynamiquement la Shards/Replicas capacité du cluster afin qu'elle se rapproche de votre objectif d'utilisation.
Pour comprendre le fonctionnement d' ElastiCache Auto Scaling, supposons que vous ayez un cluster nommé`UsersCluster`. En surveillant les CloudWatch métriques`UsersCluster`, vous déterminez le nombre maximum de partitions dont le cluster a besoin lorsque le trafic est à son maximum et le nombre minimal de partitions lorsque le trafic est à son point le plus bas. Vous définissez également une valeur cible pour l'utilisation du processeur pour le `UsersCluster` cluster. ElastiCache auto scaling utilise son algorithme de suivi des cibles pour s'assurer que les partitions provisionnées `UsersCluster` sont ajustées selon les besoins afin que l'utilisation reste égale ou proche de la valeur cible.
**Note**
La mise à l'échelle peut prendre un certain temps et nécessitera des ressources de cluster supplémentaires pour que les partitions puissent être rééquilibrées. ElastiCache Auto Scaling modifie les paramètres des ressources uniquement lorsque la charge de travail réelle reste élevée (ou diminuée) pendant une période prolongée de plusieurs minutes. L'algorithme de suivi des cibles à mise à l'échelle automatique vise à maintenir l'utilisation de la cible à la valeur que vous avez choisie ou à un niveau proche de celle-ci sur le long terme.
# Politiques Auto Scaling
Une politique de mise à l'échelle comporte les éléments suivants :
+ Une métrique cible : métrique utilisée par Valkey et Redis OSS Auto Scaling ElastiCache pour déterminer à quel moment et dans quelle CloudWatch mesure il convient de procéder à une mise à l'échelle.
+ Capacités maximale et minimale – Le nombre minimal et maximal de partitions ou de réplicas à utiliser pour la mise à l'échelle.
**Important**
Lors de la création de la politique de dimensionnement automatique, si la capacité actuelle est supérieure à la capacité maximale configurée, nous l'adaptons MaxCapacity lors de la création de la politique. De même, si la capacité actuelle est inférieure à la capacité minimale configurée, nous augmentons jusqu'à. MinCapacity
+ Un temps de stabilisation – La durée, en secondes, entre la fin d'une activité de mise à l'échelle horizontale montante ou descendante et le début d'une autre activité de mise à l'échelle horizontale.
+ Rôle lié à un service : rôle AWS Identity and Access Management (IAM) lié à un service spécifique. AWS Un rôle lié à un service inclut toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom. ElastiCache Auto Scaling génère automatiquement ce `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG` rôle pour vous.
+ Activer ou désactiver les activités de dimensionnement en charge – Capacité d'activer ou désactiver les activités de dimensionnement en charge pour une politique.
**Topics**
+ [Métrique cible pour Auto Scaling](#AutoScaling-TargetMetric)
+ [Capacité minimale et maximale](#AutoScaling-MinMax)
+ [Temps de stabilisation](#AutoScaling-Cooldown)
+ [Activation ou désactivation d'activités de diminution en charge](#AutoScaling-enable-disable-scale-in)
## Métrique cible pour Auto Scaling
Dans ce type de stratégie, une métrique prédéfinie ou personnalisée et une valeur cible pour la métrique sont spécifiées dans une configuration de politique de dimensionnement du suivi des cibles. ElastiCache pour Valkey et Redis OSS Auto Scaling crée et gère les CloudWatch alarmes qui déclenchent la politique de dimensionnement et calcule l'ajustement de mise à l'échelle en fonction de la métrique et de la valeur cible. La politique de dimensionnement ajoute ou supprime shards/replicas selon les besoins pour maintenir la métrique à la valeur cible spécifiée ou proche de celle-ci. En plus de maintenir la métrique proche de la valeur cible, une politique de dimensionnement Suivi de la cible s'ajuste également aux fluctuations de la métrique dues à l'évolution de la charge de travail. Une telle politique minimise également les fluctuations rapides du nombre de produits disponibles shards/replicas pour votre cluster.
Par exemple, examinons une politique de mise à l'échelle qui utilise la métrique prédéfinie d'utilisation moyenne de `ElastiCachePrimaryEngineCPUUtilization`. Ce type de politique peut maintenir l'utilisation du CPU au pourcentage d'utilisation indiqué, tel que 70 %, ou proche de celui-ci.
**Note**
Pour chaque cluster, vous ne pouvez créer qu'une seule politique Auto Scaling pour chaque métrique cible.
## Capacité minimale et maximale
**Partitions**
Vous pouvez spécifier le nombre maximum de partitions pouvant être redimensionnées ElastiCache pour le dimensionnement automatique de Valkey et Redis OSS. Cette valeur doit être comprise entre 1 et 250, inclus. Vous pouvez également spécifier le nombre minimum de partitions à gérer par le biais de la mise à l'échelle automatique. Cette valeur doit être au moins égale à 1, et égale ou inférieure à la valeur spécifiée pour le maximum de partitions, soit 250.
**Réplicas**
Vous pouvez spécifier le nombre maximum de répliques à gérer pour le dimensionnement automatique de ElastiCache Valkey et Redis OSS. Cette valeur doit être inférieure ou égale à 5. Vous pouvez également spécifier le nombre minimum de répliques à gérer par le biais du dimensionnement automatique. Cette valeur doit être au moins égale à 1, et égale ou inférieure à la valeur spécifiée pour le maximum de réplicas, soit 5.
Pour déterminer le nombre minimum et maximum shards/replicas dont vous avez besoin pour le trafic type, testez votre configuration Auto Scaling avec le taux de trafic attendu vers votre modèle.
**Note**
ElastiCache les politiques de dimensionnement automatique augmentent la capacité du cluster jusqu'à ce qu'il atteigne la taille maximale que vous avez définie ou jusqu'à ce que des limites de service s'appliquent. Pour demander une augmentation de cette limite, veuillez consulter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et sélectionnez le type de limite **Nœuds par cluster par type d'instance**.
**Important**
Dimensionnement en l'absence de trafic. Si le trafic d'une variante devient nul, il est ElastiCache automatiquement ajusté au nombre minimum d'instances spécifié.
## Temps de stabilisation
Vous pouvez affiner la réactivité d'une politique de suivi de cible et d'échelonnement en ajoutant des temps de stabilisation qui affectent le dimensionnement de votre cluster. Un temps de stabilisation bloque les demandes de montée ou de diminution en charge ultérieures jusqu'à l'expiration de la période. Cela ralentit les suppressions de shards/replicas votre cluster ElastiCache for Valkey et Redis OSS pour les requêtes scale-in, et la création de requêtes scale-out. shards/replicas Vous pouvez spécifier les temps de stabilisation suivants :
+ Une activité de scale-in réduit le nombre de membres de votre shards/replicas cluster. Un temps de stabilisation de diminution en charge spécifie la durée, en secondes, devant s'écouler entre la fin d'une activité de diminution et le début d'une autre.
+ Une activité de scale-out augmente le nombre de membres de votre shards/replicas cluster. Un temps de stabilisation de montée en charge spécifie la durée, en secondes, devant s'écouler entre la fin d'une activité de montée en charge et le début d'une autre.
Lorsqu'aucun temps de stabilisation de diminution ou de montée en charge n'est pas spécifié, la valeur par défaut est 600 secondes pour l'augmentation et de 900 secondes pour la diminution.
## Activation ou désactivation d'activités de diminution en charge
Vous pouvez activer ou désactiver des activités de diminution en charge pour une politique. L'activation des activités d'extension permet de supprimer la politique de dimensionnement. shards/replicas. When scale-in activities are enabled, the scale-in cooldown period in the scaling policy applies to scale-in activities. Disabling scale-in activities prevents the scaling policy from deleting shards/replicas
**Note**
Les activités de scale-out sont toujours activées afin que la politique de dimensionnement puisse créer des ElastiCache partitions ou des répliques selon les besoins.
## Autorisations IAM requises pour Auto Scaling
ElastiCache pour Valkey et Redis OSS Auto Scaling est rendu possible par une combinaison de ElastiCache CloudWatch, et Application Auto Scaling. APIs Les clusters sont créés et mis à jour avec ElastiCache, les alarmes sont créées avec CloudWatch et les politiques de dimensionnement sont créées avec Application Auto Scaling. Outre les autorisations IAM standard pour créer et mettre à jour des clusters, l'utilisateur IAM qui accède aux paramètres d' ElastiCache Auto Scaling doit disposer des autorisations appropriées pour les services qui prennent en charge le dimensionnement dynamique. Dans cette politique la plus récente, nous avons ajouté la prise en charge de la mise à l'échelle verticale de Memcached, avec l'action. `elasticache:ModifyCacheCluster` Les utilisateurs IAM doivent disposer des autorisations nécessaires pour utiliser les actions indiquées dans l’exemple de politique suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-autoscaling:*",
"elasticache:DescribeReplicationGroups",
"elasticache:ModifyReplicationGroupShardConfiguration",
"elasticache:IncreaseReplicaCount",
"elasticache:DecreaseReplicaCount",
"elasticache:DescribeCacheClusters",
"elasticache:DescribeCacheParameters",
"cloudwatch:DeleteAlarms",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics",
"cloudwatch:PutMetricAlarm",
"cloudwatch:DisableAlarmActions",
"cloudwatch:EnableAlarmActions",
"iam:CreateServiceLinkedRole",
"sns:CreateTopic",
"sns:Subscribe",
"sns:Get*",
"sns:List*"
],
"Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster"
}
]
}
```
------
## Rôle lié à un service
Le service de dimensionnement automatique ElastiCache pour Valkey et Redis OSS a également besoin d'une autorisation pour décrire vos clusters et vos CloudWatch alarmes, ainsi que d'autorisations pour modifier votre capacité ElastiCache cible en votre nom. Si vous activez Auto Scaling pour votre cluster, il crée un rôle lié à un service nommé. `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG` Ce rôle lié au service accorde à ElastiCache Auto Scaling l'autorisation de décrire les alarmes correspondant à vos politiques, de surveiller la capacité actuelle de la flotte et de modifier la capacité de la flotte. Le rôle lié au service est le rôle par défaut pour le dimensionnement ElastiCache automatique. Pour plus d'informations, consultez la section [Rôles liés à un service ElastiCache pour Redis OSS Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) dans le Guide de l'utilisateur d'Application Auto Scaling.
## Bonnes pratiques pour Auto Scaling
Avant de vous inscrire à Auto Scaling, nous vous recommandons de procéder comme suit :
1. **Utiliser une seule métrique de suivi** : identifiez si votre cluster a des charges de travail gourmandes en processeur ou en données et utilisez une métrique prédéfinie correspondante pour définir la politique de mise à l'échelle.
+ Processeur du moteur : `ElastiCachePrimaryEngineCPUUtilization` (dimension de la partition) ou `ElastiCacheReplicaEngineCPUUtilization` (dimension du réplica)
+ Utilisation de la base de données : `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage`. Cette politique de mise à l'échelle fonctionne de manière optimale lorsque maxmemory-policy est définie sur noeviction sur le cluster.
Nous vous recommandons d'éviter d'appliquer plusieurs politiques par dimension sur le cluster. ElastiCache pour Valkey et Redis OSS Auto Scaling augmentera la taille de la cible évolutive si des politiques de suivi des cibles sont prêtes à être étendues, mais elle ne sera étendue que si toutes les politiques de suivi des cibles (avec la partie scale-in activée) sont prêtes à être étendues. Si plusieurs politiques indiquent simultanément à la cible évolutive de procéder à une montée en puissance ou à une diminution de charge, elle effectue la mise à l'échelle en fonction de la politique qui fournit la plus grande capacité à la fois pour la montée et la diminution en charge.
1. **Métriques personnalisées pour le suivi de cibles** : soyez prudent lorsque vous utilisez des métriques personnalisées pour le suivi de cibles, car la fonction Auto Scaling est mieux adaptée à la montée en puissance/la mise à l'échelle horizontale proportionnelle aux changements dans les métriques choisies pour la politique. Si ces métriques ne changent pas de manière proportionnelle pour les actions de mise à l'échelle utilisées pour la création de politiques, cela peut entraîner des actions de montée en puissance et de mise à l'échelle horizontale continues pouvant affecter la disponibilité ou le coût.
Pour les clusters avec hiérarchisation des données (types d'instances de la famille r6gd), évitez d'utiliser des métriques basées sur la mémoire pour la mise à l'échelle.
1. **Dimensionnement planifié** : si vous constatez que votre charge de travail est déterministe ( high/low atteinte à un moment précis), nous vous recommandons d'utiliser le dimensionnement planifié et de configurer votre capacité cible en fonction des besoins. Le suivi de cible est mieux adapté aux charges de travail non déterministes et au cluster pour fonctionner à la métrique cible requise en augmentant la capacité lorsque vous avez besoin de plus de ressources et en la diminuant lorsque vous en avez besoin de moins.
1. **Désactiver la mise à l'échelle interne : le dimensionnement automatique sur Target Tracking convient parfaitement aux clusters dont les charges increase/decrease de travail sont progressives, car les indicateurs peuvent déclencher des oscillations de spikes/dip scale-out/in** consécutives. Afin d'éviter de telles oscillations, vous pouvez commencer par désactiver la mise à l'échelle horizontale et, par la suite, vous pouvez toujours adapter manuellement à vos besoins.
1. **Testez votre application** : nous vous recommandons de tester votre application avec vos Min/Max charges de travail estimées afin de déterminer les valeurs minimales et maximales absolues shards/replicas requises pour le cluster, tout en créant des politiques de dimensionnement pour éviter les problèmes de disponibilité. La scalabilité automatique peut monter en puissance la capacité jusqu'au seuil Max et mettre à l'échelle horizontale la capacité jusqu'au seuil Min configuré pour la cible.
1. **Définition de la valeur cible** : vous pouvez analyser les CloudWatch mesures correspondantes relatives à l'utilisation du cluster sur une période de quatre semaines afin de déterminer le seuil de valeur cible. Si vous n'êtes toujours pas sûr de la valeur à choisir, nous vous recommandons de commencer par une valeur de métrique prédéfinie minimale prise en charge.
1. AutoScaling sur Target Tracking convient parfaitement aux clusters dotés d'une répartition uniforme des charges de travail entre les shards/replicas dimensions. Une distribution non uniforme peut conduire à :
+ Mise à l'échelle lorsque cela n'est pas nécessaire en raison de spike/dip la charge de travail sur quelques hot shards/répliques.
+ L'absence de mise à l'échelle lorsque cela est nécessaire en raison d'une moyenne globale proche de l'objectif, même si l'on dispose de partitions/réplicas chauds.
**Note**
Lorsque vous agrandissez votre cluster, les fonctions chargées dans l'un des nœuds existants (sélectionnées au hasard) ElastiCache seront automatiquement répliquées sur le ou les nouveaux nœuds. Si votre cluster utilise Valkey ou Redis OSS 7.0 ou une version ultérieure et que votre application utilise [Functions](https://valkey.io/topics/functions-intro/), nous vous recommandons de charger toutes vos fonctions sur toutes les partitions avant de les redimensionner afin que votre cluster ne se retrouve pas avec des fonctions différentes sur différentes partitions.
Après vous être inscrit auprès de AutoScaling, notez ce qui suit :
+ Il existe des limitations sur les configurations de scalabilité automatique prises en charge, nous vous recommandons donc de ne pas modifier la configuration d'un groupe de réplication qui est inscrit pour la scalabilité automatique. Voici quelques exemples :
+ Modifier manuellement le type d'instance vers des types non pris en charge.
+ Association du groupe de réplication à un entrepôt de données global.
+ Modification du paramètre `ReservedMemoryPercent`.
+ increasing/decreasing shards/replicas beyond the Min/MaxCapacité configurée manuellement lors de la création de la politique.
# Utilisation de Auto Scaling avec des partitions
Avec ElastiCache's, AutoScaling vous pouvez utiliser les politiques de suivi et de planification avec votre moteur Valkey ou Redis OSS.
Vous trouverez ci-dessous des informations sur le suivi des cibles et les politiques planifiées, ainsi que sur la manière de les appliquer à l'aide du AWS Management Console AWS CLI et APIs.
**Topics**
+ [Politiques de dimensionnement Suivi de la cible](AutoScaling-Scaling-Policies-Target.md)
+ [Ajout d'une politique de mise à l'échelle](AutoScaling-Scaling-Adding-Policy-Shards.md)
+ [Enregistrement d'une cible évolutive](AutoScaling-Scaling-Registering-Policy-CLI.md)
+ [Définition d'une politique de mise à l'échelle](AutoScaling-Scaling-Defining-Policy-API.md)
+ [Désactivation de l'activité de diminution en charge](AutoScaling-Scaling-Disabling-Scale-in.md)
+ [Application d'une politique de mise à l'échelle](AutoScaling-Scaling-Applying-a-Scaling-Policy.md)
+ [Modification d'une politique de dimensionnement](AutoScaling-Scaling-Editing-a-Scaling-Policy.md)
+ [Suppression d'une politique de dimensionnement](AutoScaling-Scaling-Deleting-a-Scaling-Policy.md)
+ [Utilisation CloudFormation pour les politiques Auto Scaling](AutoScaling-with-Cloudformation-Shards.md)
+ [Mise à l’échelle planifiée](AutoScaling-with-Scheduled-Scaling-Shards.md)
# Politiques de dimensionnement Suivi de la cible
Avec les politiques de dimensionnement du suivi des cibles, vous sélectionnez une métrique et définissez une valeur cible. ElastiCache pour Valkey et Redis OSS Auto Scaling crée et gère les CloudWatch alarmes qui déclenchent la politique de dimensionnement et calcule l'ajustement de mise à l'échelle en fonction de la métrique et de la valeur cible. La politique de mise à l'échelle ajoute ou supprime des partitions si nécessaire pour maintenir la métrique à la valeur cible spécifiée ou proche de celle-ci. En plus de maintenir la métrique proche de la valeur cible, une politique de dimensionnement Suivi de la cible s'ajuste également aux fluctuations de la métrique dues à un modèle de charge fluctuant, et minimise les fluctuations rapides dans la capacité du parc.
Par exemple, examinons une politique de mise à l'échelle qui utilise la métrique prédéfinie d'utilisation moyenne de `ElastiCachePrimaryEngineCPUUtilization` avec une valeur cible configurée. Une telle politique peut maintenir l'utilisation du CPU à la valeur cible spécifiée ou proche de celle-ci.
## Métriques prédéfinies
Une métrique prédéfinie est une structure qui fait référence à un nom, à une dimension et à une statistique (`average`) spécifiques d'une CloudWatch métrique donnée. Votre politique Auto Scaling définit les métriques prédéfinies suivantes pour votre cluster :
****
| Nom de la métrique prédéfinie | CloudWatch Nom de la métrique | CloudWatch Dimension métrique | Types d'instances non éligibles |
| --- | --- | --- | --- |
| ElastiCachePrimaryEngineCPUUtilization | `EngineCPUUtilization` | ReplicationGroupId, Rôle = Principal | Aucun |
| ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage | `DatabaseCapacityUsageCountedForEvictPercentage` | Métriques du groupe de réplication Valkey ou Redis OSS | Aucun |
| ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage | `DatabaseMemoryUsageCountedForEvictPercentage` | Métriques du groupe de réplication Valkey ou Redis OSS | R6gd |
Les types d'instance avec hiérarchisation des données ne peuvent pas utiliser `ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage`, car ils stockent des données à la fois dans la mémoire et sur SSD. Le cas de figure attendu pour les instances avec hiérarchisation des données est d'utiliser 100 % de la mémoire et de remplir le SSD si nécessaire.
## Critères de Auto Scaling pour les partitions
Lorsque le service détecte que votre métrique prédéfinie est égale ou supérieure au paramètre Target, il augmente automatiquement la capacité de vos partitions. ElastiCache pour Valkey et Redis OSS redimensionne les partitions de votre cluster d'un nombre égal à la plus grande des deux valeurs suivantes : pourcentage de variation par rapport à Target et 20 % des partitions actuelles. Pour la mise à l'échelle, la mise à l'échelle automatique ElastiCache ne sera pas effectuée à moins que la valeur métrique globale ne soit inférieure à 75 % de la cible que vous avez définie.
Pour un exemple de mise à l'échelle, si vous avez 50 partitions et
+ si votre Target atteint 30 %, il ElastiCache augmente de 30 %, ce qui se traduit par 65 partitions par cluster.
+ si votre Target atteint 10 %, augmente ElastiCache par défaut d'au moins 20 %, ce qui se traduit par 60 partitions par cluster.
Par exemple, si vous avez sélectionné une valeur cible de 60 %, la mise à l'échelle automatique ElastiCache ne sera pas automatique tant que la métrique ne sera pas inférieure ou égale à 45 % (25 % en dessous de la cible de 60 %).
## Considérations relatives à Auto Scaling
Gardez les considérations suivantes à l'esprit :
+ Une politique de mise à l'échelle Suivi de la cible suppose qu'elle doit effectuer une montée en charge ; lorsque la métrique spécifiée est au-dessus de la valeur cible. Vous ne pouvez pas utiliser une politique de dimensionnement du suivi des cibles pour effectuer une mise à l'échelle lorsque la métrique spécifiée est inférieure à la valeur cible. ElastiCache pour Valkey et Redis OSS redimensionne les partitions d'un écart minimum de 20 % par rapport à la cible des partitions existantes dans le cluster.
+ Une politique de suivi des objectifs et d'échelonnement n'effectue pas de mise à l'échelle lorsque la métrique spécifiée a des données insuffisantes. Elle n'effectue pas de mise à l'échelle horizontale, car elle n'interprète pas des données insuffisantes comme une faible utilisation.
+ Vous pouvez constater des écarts entre la valeur cible et les points de données de métrique réels. En effet, ElastiCache Auto Scaling agit toujours de manière prudente en arrondissant à la hausse ou à la baisse lorsqu'il détermine la capacité à ajouter ou à supprimer. Cela l'empêche d'ajouter une capacité insuffisante ou de retirer trop de capacité.
+ Pour garantir la disponibilité de l'application, le service augmente proportionnellement aux métriques aussi rapidement que possible, mais diminue plus progressivement.
+ Vous pouvez avoir plusieurs politiques de dimensionnement du suivi des cibles ElastiCache pour un cluster Valkey et Redis OSS, à condition que chacune d'elles utilise une métrique différente. ElastiCache Auto Scaling a pour objectif de toujours prioriser la disponibilité. Son comportement varie donc selon que les politiques de suivi des cibles sont prêtes à être étendues ou intégrées. Il augmentera la taille du service si l'une des politiques Suivi de la cible est prête pour une augmentation de taille, mais la diminuera uniquement si toutes les politiques Suivi de la cible (avec la portion de diminution en charge activée) sont prêtes pour une diminution de taille.
+ Ne modifiez ni ne supprimez les CloudWatch alarmes gérées par ElastiCache Auto Scaling dans le cadre d'une politique de dimensionnement du suivi des cibles. ElastiCache Auto Scaling supprime automatiquement les alarmes lorsque vous supprimez la politique de dimensionnement.
+ ElastiCache Auto Scaling ne vous empêche pas de modifier manuellement les partitions de cluster. Ces ajustements manuels n'affectent pas les CloudWatch alarmes existantes associées à la politique de dimensionnement, mais peuvent avoir un impact sur les mesures susceptibles de déclencher ces CloudWatch alarmes.
+ Ces CloudWatch alarmes gérées par Auto Scaling sont définies sur la métrique AVG pour toutes les partitions du cluster. Ainsi, avoir des partitions chaudes peut entraîner l'un ou l'autre des scénarios suivants :
+ mise à l'échelle lorsqu'elle n'est pas nécessaire en raison de la charge sur quelques fragments chauds déclenchant une alarme CloudWatch
+ l'absence de mise à l'échelle lorsque cela est nécessaire en raison d'AVG agrégé sur toutes les partitions affectant l'alarme à ne pas briser.
+ ElastiCache les limites par défaut relatives aux nœuds par cluster s'appliquent toujours. Ainsi, lorsque vous optez pour Auto Scaling et si vous prévoyez que le nombre maximal de nœuds dépasse la limite par défaut, demandez une augmentation de limite à [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et choisissez le type de limite **Nodes per cluster per instance type (Nœuds par cluster par type d'instance)**.
+ Assurez-vous que votre VPC dispose d'un nombre suffisant d'interfaces réseau élastiques ENIs (Elastic Network Interfaces), nécessaires lors du scale-out. Pour de plus amples informations, veuillez consulter [Interfaces réseau Elastic](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Si la capacité disponible n'est pas suffisante EC2, ElastiCache Auto Scaling ne sera pas redimensionné et sera retardé jusqu'à ce que la capacité soit disponible.
+ ElastiCache pour Redis OSS, Auto Scaling ne supprimera pas les fragments contenant des emplacements dont la taille d'élément est supérieure à 256 Mo après la sérialisation lors de la scale-in.
+ Pendant la réduction de charge, il ne supprimera pas les partitions si la mémoire disponible sur la configuration des partitions résultante est insuffisante.
# Ajout d'une politique de mise à l'échelle
Vous pouvez ajouter une politique de dimensionnement à l'aide du AWS Management Console.
**Pour ajouter une politique Auto Scaling à un cluster ElastiCache pour Valkey et Redis OSS**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**.
1. Choisissez le cluster auquel vous voulez ajouter une stratégie (choisissez le nom du cluster et non pas le bouton situé à sa gauche).
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Choisissez **add dynamic scaling** (ajouter le dimensionnement dynamique).
1. Pour **Policy name (Nom de la politique)**, attribuez un nom de politique.
1. Pour **Scalable Dimension (Dimension évolutives)** choisir **shards (partitions)**.
1. Pour la métrique cible, choisissez l'une des actions suivantes :
+ **Primary CPU Utilization (Utilisation du CPU principal)** pour créer une politique basée sur l'utilisation moyenne du CPU.
+ **Memory (Mémoire)** pour créer une politique basée sur la mémoire de base de données moyenne.
+ **Capacité** pour créer une politique basée sur l'utilisation moyenne de la capacité de la base de données. La métrique Capacité inclut l'utilisation de la mémoire et du SSD pour les instances avec hiérarchisation des données, ainsi que l'utilisation de la mémoire pour tous les autres types d'instances.
1. Pour la valeur cible, choisissez une valeur supérieure ou égale à 35 et inférieure ou égale à 70. La mise à l'échelle automatique conservera cette valeur pour la métrique cible sélectionnée sur l'ensemble de vos ElastiCache partitions :
+ **Utilisation du processeur principal** : conserve la valeur cible pour la métrique `EngineCPUUtilization` sur les nœuds primaires.
+ **Mémoire** : conserve la valeur cible pour la métrique `DatabaseMemoryUsageCountedForEvictPercentage`
+ **Capacité** conserve la valeur cible pour la métrique `DatabaseCapacityUsageCountedForEvictPercentage`.
Des partitions de cluster sont ajoutées ou supprimées pour maintenir la métrique proche de la valeur spécifiée.
1. (Facultatif) Les périodes de stabilisation de diminution ou de montée en charge ne sont pas prises en charge à partir de la console. Utilisez le AWS CLI pour modifier les valeurs de recharge.
1. Pour **Capacité minimale**, saisissez le nombre minimum de partitions que la politique ElastiCache Auto Scaling doit maintenir.
1. Pour **Maximum capacity**, saisissez le nombre maximum de partitions que la politique ElastiCache Auto Scaling doit gérer. Cette valeur doit être inférieure ou égale à 250.
1. Choisissez **Créer**.
# Enregistrement d'une cible évolutive
Avant de pouvoir utiliser Auto Scaling avec un cluster ElastiCache pour Valkey et Redis OSS, vous devez enregistrer votre cluster avec ElastiCache Auto Scaling. Vous le faites pour définir la dimension de mise à l'échelle et les limites à appliquer à ce cluster. ElastiCache le dimensionnement automatique redimensionne dynamiquement le cluster selon la dimension `elasticache:replication-group:NodeGroups` évolutive, qui représente le nombre de partitions du cluster.
**En utilisant le AWS CLI**
Pour enregistrer votre cluster ElastiCache for Valkey et Redis OSS, utilisez la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande avec les paramètres suivants :
+ `--service-namespace` – Définissez cette valeur sur `elasticache`
+ `--resource-id`— L'identifiant de ressource du cluster. Pour ce paramètre, le type de ressource est `ReplicationGroup` et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ `--scalable-dimension` – Définissez cette valeur sur `elasticache:replication-group:NodeGroups`.
+ `--max-capacity `— Le nombre maximum de partitions à gérer par le dimensionnement ElastiCache automatique. Pour plus d'informations sur la relation entre `--min-capacity`, `--max-capacity` et le nombre de partitions dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
+ `--min-capacity `— Le nombre minimum de partitions à gérer par le dimensionnement ElastiCache automatique. Pour plus d'informations sur la relation entre `--min-capacity`, `--max-capacity` et le nombre de partitions dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Dans l'exemple suivant, vous enregistrez un ElastiCache cluster nommé`myscalablecluster`. L'enregistrement indique que le cluster doit être mis à l'échelle de façon dynamique pour contenir de une à huit partitions.
Pour Linux, macOS ou Unix :
```
aws application-autoscaling register-scalable-target \
--service-namespace elasticache \
--resource-id replication-group/myscalablecluster \
--scalable-dimension elasticache:replication-group:NodeGroups \
--min-capacity 1 \
--max-capacity 10 \
```
Pour Windows :
```
aws application-autoscaling register-scalable-target ^
--service-namespace elasticache ^
--resource-id replication-group/myscalablecluster ^
--scalable-dimension elasticache:replication-group:NodeGroups ^
--min-capacity 1 ^
--max-capacity 10 ^
```
**Utilisation de l'API**
Pour enregistrer votre ElastiCache cluster, utilisez la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande avec les paramètres suivants :
+ ServiceNamespace — Définissez cette valeur sur elasticache.
+ ResourceID — Identifiant de ressource pour le cluster. ElastiCache Pour ce paramètre, le type de ressource est ReplicationGroup et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ ScalableDimension — Définissez cette valeur sur`elasticache:replication-group:NodeGroups`.
+ MinCapacity — Le nombre minimum de partitions à gérer par le dimensionnement ElastiCache automatique. Pour plus d'informations sur la relation entre --min-capacity, --max-capacity et le nombre de réplicas dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity — Le nombre maximum de partitions à gérer par le dimensionnement ElastiCache automatique. Pour plus d'informations sur la relation entre --min-capacity, --max-capacity et le nombre de réplicas dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Dans l'exemple suivant, vous enregistrez un ElastiCache cluster nommé `myscalablecluster` avec l'API Application Auto Scaling. Cet enregistrement indique que le cluster doit être dimensionné de façon dynamique pour contenir de un à 5 réplicas.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"MinCapacity": 1,
"MaxCapacity": 5
}
```
# Définition d'une politique de mise à l'échelle
Une configuration de politique de dimensionnement Suivi de la cible est représentée par un bloc JSON dans lequel sont définies les métriques et valeurs cibles. Vous pouvez enregistrer une configuration de politique de dimensionnement sous forme de bloc JSON dans un fichier texte. Vous utilisez ce fichier texte lorsque vous appelez l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling. Pour plus d'informations sur la syntaxe de la configuration d'une politique, veuillez consulter [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) dans la Référence de l'API Application Auto Scaling.
Les options suivantes sont disponibles pour définir une configuration de politique de suivi de cible et d'échelonnement :
**Topics**
+ [Utilisation d'une métrique prédéfinie](#AutoScaling-Scaling-Predefined-Metric)
+ [Utilisation d'une métrique personnalisée](#AutoScaling-Scaling-Custom-Metric)
+ [Utilisation des temps de stabilisation](#AutoScaling-Scaling-Cooldown-periods)
## Utilisation d'une métrique prédéfinie
En utilisant des métriques prédéfinies, vous pouvez définir rapidement une politique de dimensionnement pour le suivi des cibles ElastiCache pour un cluster Valkey et Redis OSS qui fonctionne avec le suivi des cibles dans Auto Scaling. ElastiCache
Actuellement, ElastiCache prend en charge les métriques prédéfinies suivantes dans NodeGroup Auto Scaling :
+ **ElastiCachePrimaryEngineCPUUtilization**— La valeur moyenne de la `EngineCPUUtilization` métrique pour CloudWatch tous les nœuds principaux du cluster.
+ **ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage**— La valeur moyenne de la `DatabaseMemoryUsageCountedForEvictPercentage` métrique pour CloudWatch tous les nœuds principaux du cluster.
+ **ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage**— La valeur moyenne de la `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` métrique pour CloudWatch tous les nœuds principaux du cluster.
Pour plus d'informations sur les métriques `EngineCPUUtilization`, `DatabaseMemoryUsageCountedForEvictPercentage` et `DatabaseCapacityUsageCountedForEvictPercentage`, consultez [Surveillance de l'utilisation à l'aide de CloudWatch métriques](CacheMetrics.md). Pour utiliser une métrique prédéfinie dans votre politique de dimensionnement, créez une configuration de suivi de la cible pour votre politique de dimensionnement. Cette configuration doit inclure `PredefinedMetricSpecification` pour la métrique prédéfinie et TargetValue pour la valeur cible de cette métrique.
**Example**
L'exemple suivant décrit une configuration de politique typique pour le dimensionnement du suivi des cibles ElastiCache pour un cluster Valkey et Redis OSS. Dans cette configuration, la métrique `ElastiCachePrimaryEngineCPUUtilization` prédéfinie est utilisée pour ajuster le cluster en fonction d'une utilisation moyenne du processeur de 40 % sur tous les nœuds principaux du cluster.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
```
## Utilisation d'une métrique personnalisée
L'utilisation de métriques personnalisées vous permet de définir une politique de dimensionnement Suivi de la cible répondant à vos exigences personnelles. Vous pouvez définir une métrique personnalisée en fonction d'une métrique ElastiCache qui évolue proportionnellement à la mise à l'échelle. Toutes les ElastiCache mesures ne fonctionnent pas pour le suivi des cibles. La métrique doit être une métrique d'utilisation valide et décrire le degré d'occupation d'une instance. La valeur de la métrique doit augmenter ou diminuer proportionnellement au nombre de partitions dans le cluster. Cette augmentation ou diminution proportionnelle est nécessaire pour que les données de la métrique puissent être utilisées afin d'augmenter ou de réduire proportionnellement le nombre de partitions.
**Example**
L'exemple suivant décrit une configuration de suivi de la cible pour une politique de dimensionnement. Dans cette configuration, une métrique personnalisée ajuste un cluster ElastiCache pour Redis OSS en fonction d'une utilisation moyenne du processeur de 50 % sur toutes les partitions d'un cluster nommé. `my-db-cluster`
```
{
"TargetValue": 50,
"CustomizedMetricSpecification":
{
"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{
"Name": "ReplicationGroup","Value": "my-db-cluster"
},
{
"Name": "Role","Value": "PRIMARY"
}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
```
## Utilisation des temps de stabilisation
Vous pouvez spécifier une valeur, en secondes, pour que `ScaleOutCooldown` ajoute un temps de stabilisation à la montée en puissance de votre cluster. De la même manière, vous pouvez ajouter une valeur, en secondes, pour que `ScaleInCooldown` ajoute un temps de stabilisation pour la diminution de charge de votre cluster. Pour plus d'informations, reportez-vous [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)à la section Application Auto Scaling API Reference.
L'exemple suivant décrit une configuration de suivi de la cible pour une politique de dimensionnement. Dans cette configuration, la métrique `ElastiCachePrimaryEngineCPUUtilization` prédéfinie est utilisée ElastiCache pour ajuster un cluster Redis OSS en fonction d'une utilisation moyenne du processeur de 40 % sur tous les nœuds principaux de ce cluster. La configuration indique un temps de stabilisation de diminution en charge de 10 minutes et un temps de stabilisation de montée en charge de 5 minutes.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
# Désactivation de l'activité de diminution en charge
Vous pouvez empêcher la configuration de la politique de dimensionnement du suivi des cibles de s'étendre dans votre cluster en désactivant l'activité de dimensionnement. La désactivation de l'activité de diminution en charge empêche la politique de mise à l'échelle de supprimer des partitions, tout en l'autorisant encore à les créer si nécessaire.
Vous pouvez spécifier une valeur booléenne pour que `DisableScaleIn` active ou désactive l'activité de diminution en charge de votre cluster. Pour plus d'informations, reportez-vous [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)à la section Application Auto Scaling API Reference.
L'exemple suivant décrit une configuration de suivi de la cible pour une politique de dimensionnement. Dans cette configuration, la métrique `ElastiCachePrimaryEngineCPUUtilization` prédéfinie ajuste un cluster ElastiCache pour Valkey et Redis OSS en fonction d'une utilisation moyenne du processeur de 40 % sur tous les nœuds principaux de ce cluster. La configuration désactive l'activité de diminution en charge pour la politique de dimensionnement.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
# Application d'une politique de mise à l'échelle
Après avoir enregistré votre cluster auprès ElastiCache de Valkey et Redis OSS Auto Scaling et défini une politique de dimensionnement, vous appliquez la politique de dimensionnement au cluster enregistré. Pour appliquer une politique de dimensionnement à un ElastiCache cluster Redis OSS, vous pouvez utiliser l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling.
## Appliquer une politique de dimensionnement à l'aide du AWS CLI
Pour appliquer une politique de dimensionnement à votre cluster ElastiCache for Valkey et Redis OSS, utilisez la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)commande avec les paramètres suivants :
+ **--policy-name** – Nom de la politique de mise à l'échelle.
+ **--policy-type** – Définissez cette valeur à `TargetTrackingScaling`.
+ **--resource-id — L'identifiant** de la ressource. Pour ce paramètre, le type de ressource est `ReplicationGroup` et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ **--service-namespace** – Définissez cette valeur à `elasticache`.
+ **--scalable-dimension** – Définissez cette valeur à `elasticache:replication-group:NodeGroups`.
+ **-- target-tracking-scaling-policy -configuration — Configuration de** la politique de dimensionnement du suivi des cibles à utiliser pour le cluster.
Dans l'exemple suivant, vous appliquez une politique de dimensionnement de suivi des cibles nommée `myscalablepolicy` à un cluster ElastiCache pour Valkey et Redis OSS nommé auto scaling. `myscalablecluster` ElastiCache Pour ce faire, vous utilisez une configuration de politique enregistrée dans un fichier nommé `config.json`.
Pour Linux, macOS ou Unix :
```
aws application-autoscaling put-scaling-policy \
--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups \
--target-tracking-scaling-policy-configuration file://config.json
```
Pour Windows :
```
aws application-autoscaling put-scaling-policy ^
--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups ^
--target-tracking-scaling-policy-configuration file://config.json
```
## Application d'une politique de mise à l'échelle à l'aide de l'API
Pour appliquer une politique de dimensionnement à votre cluster ElastiCache for Valkey et Redis OSS, utilisez la [PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) AWS CLI commande avec les paramètres suivants :
+ **--policy-name** – Nom de la politique de mise à l'échelle.
+ **--resource-id — L'identifiant** de la ressource. Pour ce paramètre, le type de ressource est `ReplicationGroup` et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ **--service-namespace** – Définissez cette valeur à `elasticache`.
+ **--scalable-dimension** – Définissez cette valeur à `elasticache:replication-group:NodeGroups`.
+ **-- target-tracking-scaling-policy -configuration — Configuration de** la politique de dimensionnement du suivi des cibles à utiliser pour le cluster.
Dans l'exemple suivant, vous appliquez une politique de dimensionnement de suivi des cibles nommée `myscalablepolicy` à un ElastiCache cluster nommé avec mise à l'échelle `myscalablecluster` ElastiCache automatique. Vous utilisez une configuration de politique basée sur la métrique prédéfinie `ElastiCachePrimaryEngineCPUUtilization`.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
}
```
# Modification d'une politique de dimensionnement
Vous pouvez modifier une politique de dimensionnement à l'aide de l' AWS Management Console API Application Auto Scaling ou de l'API Application Auto Scaling. AWS CLI
## Modification d'une politique de dimensionnement à l'aide du AWS Management Console
**Pour modifier une politique Auto Scaling pour un cluster ElastiCache pour Valkey et Redis OSS**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez le moteur approprié.
1. Choisissez le cluster auquel vous voulez ajouter une stratégie (choisissez le nom du cluster et non pas le bouton situé à sa gauche).
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Sous **Scaling policies** (Stratégies de dimensionnement), choisissez le bouton à gauche de la stratégie Auto Scaling que vous voulez changer, puis choisissez **Modify** (Modifier).
1. Apportez les modifications nécessaires à la politique.
1. Sélectionnez **Modifier**.
## Modification d'une politique de dimensionnement à l'aide de l'API AWS CLI and
Vous pouvez utiliser l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling pour modifier une politique de dimensionnement de la même manière que vous appliquez une politique de dimensionnement :
+ Lorsque vous utilisez le AWS CLI, spécifiez le nom de la politique que vous souhaitez modifier dans le `--policy-name` paramètre. Spécifiez de nouvelles valeurs pour les paramètres que vous souhaitez modifier.
+ Lorsque vous utilisez l'API Application Auto Scaling, spécifiez le nom de la politique à modifier dans le paramètre `PolicyName`. Spécifiez de nouvelles valeurs pour les paramètres que vous souhaitez modifier.
Pour de plus amples informations, veuillez consulter [Application d'une politique de mise à l'échelle](AutoScaling-Scaling-Applying-a-Scaling-Policy.md).
# Suppression d'une politique de dimensionnement
Vous pouvez supprimer une politique de dimensionnement à l'aide de l' AWS Management Console API Application Auto Scaling ou de l'API Application Auto Scaling. AWS CLI
## Suppression d'une politique de dimensionnement à l'aide du AWS Management Console
**Pour supprimer une politique Auto Scaling ElastiCache pour un cluster Redis OSS**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**.
1. Choisissez le cluster dont vous voulez modifier la stratégie Auto Scaling (choisissez le nom du cluster et non pas le bouton situé à sa gauche).
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Sous **Scaling policies** (Stratégies de dimensionnement), choisissez la stratégie Auto Scaling, puis choisissez **Delete** (Supprimer).
## Suppression d'une politique de dimensionnement à l'aide du AWS CLI
Pour supprimer une politique de dimensionnement de votre cluster ElastiCache pour Valkey et Redis OSS, utilisez la [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI commande avec les paramètres suivants :
+ **--policy-name** – Nom de la politique de mise à l'échelle.
+ **--resource-id — L'identifiant** de la ressource. Pour ce paramètre, le type de ressource est `ReplicationGroup` et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ **--service-namespace** – Définissez cette valeur à `elasticache`.
+ **--scalable-dimension** – Définissez cette valeur à `elasticache:replication-group:NodeGroups`.
Dans l'exemple suivant, vous supprimez une politique de dimensionnement de suivi des cibles nommée à `myscalablepolicy` partir d'un cluster nommé. `myscalablecluster`
Pour Linux, macOS ou Unix :
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups
```
Pour Windows :
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups
```
## Suppression d'une politique de mise à l'échelle à l'aide de l'API
Pour supprimer une politique de dimensionnement de votre cluster ElastiCache pour Valkey et Redis OSS, utilisez la [DeleteScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI commande avec les paramètres suivants :
+ **--policy-name** – Nom de la politique de mise à l'échelle.
+ **--resource-id — L'identifiant** de la ressource. Pour ce paramètre, le type de ressource est `ReplicationGroup` et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ **--service-namespace** – Définissez cette valeur à `elasticache`.
+ **--scalable-dimension** – Définissez cette valeur à `elasticache:replication-group:NodeGroups`.
Dans l'exemple suivant, vous supprimez une politique de dimensionnement de suivi des cibles nommée à `myscalablepolicy` partir d'un cluster nommé. `myscalablecluster`
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups"
}
```
# Utilisation CloudFormation pour les politiques Auto Scaling
Cet extrait montre comment créer une politique de suivi cible et l'appliquer à une [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)ressource utilisant cette ressource. [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) Elle utilise les fonctions intrinsèques [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) et [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) pour construire la propriété `ResourceId` avec le nom logique de la ressource `AWS::ElastiCache::ReplicationGroup` qui est spécifiée dans le même modèle.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:NodeGroups'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:NodeGroups'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCachePrimaryEngineCPUUtilization
TargetValue: 40
```
# Mise à l’échelle planifiée
La mise à l’échelle en fonction d’une planification vous permet de mettre à l’échelle l’application en réponse aux changements de demande. Pour utiliser le dimensionnement planifié, vous créez des actions planifiées qui indiquent ElastiCache à Valkey et Redis OSS d'effectuer des activités de dimensionnement à des moments précis. Lorsque vous créez une action planifiée, vous spécifiez un cluster existant, le moment où l'activité de dimensionnement doit avoir lieu, la capacité minimale et la capacité maximale. Vous pouvez créer des actions planifiées pour une mise à l’échelle unique ou selon une planification récurrente.
Vous ne pouvez créer une action planifiée que pour les clusters déjà existants. Vous ne pouvez pas créer une action planifiée en même temps que vous créez un cluster.
Pour plus d'informations sur la terminologie relative à la création, à la gestion et à la suppression d'actions planifiées, veuillez consulter [Commandes généralement utilisées pour la création, la gestion et la suppression d'actions planifiées](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**Pour créer selon un calendrier récurrent :**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**.
1. Choisissez le cluster auquel vous souhaitez ajouter une politique.
1. Cliquez sur l'onglet **Manage Auto Scaling policies (Gestion des politiques Auto Scaling)** dans la liste déroulante des **Actions**.
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Dans **Auto Scaling policies (Politiques de scalabilité automatique)**, la boîte de dialogue **Add Scaling policy (Ajouter une politique de mise à l'échelle)** s'affiche. Choisissez **Scheduled scaling (Mise à l'échelle planifiée)**.
1. Pour **Policy name** (Nom de la politique), saisissez un nom de politique.
1. Pour **Scalable Dimension (Dimension évolutives)** choisir **shards (partitions)**.
1. Pour **Target Shards (Partitions cibles)**, choisissez la valeur.
1. Pour **Recurrence (Récurrence)**, choisissez**Recurring (Récurrents)**.
1. Pour **Frequency (Fréquence)**, choisissez la valeur respective.
1. Pour **Start Date (Date de début)** et **Start Time (Heure de début)**, choisissez l'heure à partir de laquelle la politique entrera en vigueur.
1. Choisissez **Add policy (Ajouter la politique)**.
**Pour créer une action planifiée unique :**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**.
1. Choisissez le cluster auquel vous souhaitez ajouter une politique.
1. Cliquez sur l'onglet **Manage Auto Scaling policies (Gestion des politiques Auto Scaling)** dans la liste déroulante des **Actions**.
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Dans **Auto Scaling policies (Politiques de scalabilité automatique)**, la boîte de dialogue **Add Scaling policy (Ajouter une politique de mise à l'échelle)** s'affiche. Choisissez **Scheduled scaling (Mise à l'échelle planifiée)**.
1. Pour **Policy name** (Nom de la politique), saisissez un nom de politique.
1. Pour **Scalable Dimension (Dimension évolutives)** choisir **shards (partitions)**.
1. Pour **Target Shards (Partitions cibles)**, choisissez la valeur.
1. Pour **Recurrence (Récurrence)**, choisissez **One Time (Une fois)**.
1. Pour **Start Date (Date de début)** et **Start Time (Heure de début)**, choisissez l'heure à partir de laquelle la politique entrera en vigueur.
1. Pour **End Date (Date de fin)** choisir la date jusqu'à laquelle la police sera en vigueur.
1. Choisissez **Add policy (Ajouter la politique)**.
**Pour supprimer une action planifiée**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**.
1. Choisissez le cluster auquel vous souhaitez ajouter une politique.
1. Cliquez sur l'onglet **Manage Auto Scaling policies (Gestion des politiques Auto Scaling)** dans la liste déroulante des **Actions**.
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Dans la section **Auto scaling policies (Politiques Auto Scaling)**, choisissez la politique Auto Scaling, puis **Delete (Supprimer)** depuis la fenêtre **Actions**.
**Pour gérer la mise à l'échelle planifiée à l'aide de la AWS CLI **
Utilisez la mise à l'échelle automatique des applications APIs suivante :
+ [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-action.html)
+ [describe-scheduled-actions](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-scheduled-actions.html)
+ [delete-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scheduled-action.html)
## Utiliser CloudFormation pour créer une action planifiée
Cet extrait montre comment créer une politique de suivi cible et l'appliquer à une [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)ressource utilisant cette ressource. [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) Elle utilise les fonctions intrinsèques [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) et [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) pour construire la propriété `ResourceId` avec le nom logique de la ressource `AWS::ElastiCache::ReplicationGroup` qui est spécifiée dans le même modèle.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:NodeGroups'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScheduledActions:
- EndTime: '2020-12-31T12:00:00.000Z'
ScalableTargetAction:
MaxCapacity: '5'
MinCapacity: '2'
ScheduledActionName: First
Schedule: 'cron(0 18 * * ? *)'
```
# Utilisation d'Auto Scaling avec des réplicas
Un groupe de ElastiCache réplication peut configurer un ou plusieurs caches pour qu'ils fonctionnent comme un seul nœud logique.
Vous trouverez ci-dessous des informations sur le suivi des cibles et les politiques planifiées, ainsi que sur la manière de les appliquer à l'aide du AWS Management Console AWS CLI et APIs.
# Politiques de dimensionnement Suivi de la cible
Avec les politiques de dimensionnement du suivi des cibles, vous sélectionnez une métrique et définissez une valeur cible. ElastiCache pour Valkey et Redis OSS AutoScaling crée et gère les CloudWatch alarmes qui déclenchent la politique de dimensionnement et calcule l'ajustement de mise à l'échelle en fonction de la métrique et de la valeur cible. La politique de mise à l'échelle ajoute ou supprime des partitions si nécessaire pour maintenir la métrique à la valeur cible spécifiée ou proche de celle-ci. En plus de maintenir la métrique proche de la valeur cible, une politique de dimensionnement Suivi de la cible s'ajuste également aux fluctuations de la métrique dues à un modèle de charge fluctuant, et minimise les fluctuations rapides dans la capacité du parc.
## Critères Auto Scaling pour les réplicas
Votre politique Auto Scaling définit la métrique prédéfinie suivante pour votre cluster :
`ElastiCacheReplicaEngineCPUUtilization`: le seuil d'utilisation du processeur AVG EngineCPU agrégé pour toutes les répliques utilisées ElastiCache pour déclencher une opération d'auto-scaling. Vous pouvez définir la cible d'utilisation entre 35 et 70 %.
Lorsque le service détecte que votre `ElastiCacheReplicaEngineCPUUtilization` métrique est égale ou supérieure au paramètre Target, il augmente automatiquement le nombre de répliques sur vos partitions. ElastiCache redimensionne les répliques de votre cluster d'un nombre égal à la plus grande des deux valeurs suivantes : variation en pourcentage par rapport à Target et une réplique. Pour la mise à l'échelle, la mise à l'échelle automatique ElastiCache ne sera pas effectuée à moins que la valeur métrique globale ne soit inférieure à 75 % de la cible que vous avez définie.
Pour un exemple de montée en puissance, si vous avez 5 partitions et 1 réplica chacun :
Si votre Target atteint 30 %, ElastiCache pour Valkey et Redis, OSS augmente d'une réplique (maximum (0,3, par défaut 1)) sur toutes les partitions, ce qui donne 5 partitions avec 2 répliques chacune,
Par exemple, si vous avez sélectionné une valeur cible de 60 %, ElastiCache pour Valkey et Redis, OSS ne procédera pas à une mise à l'échelle automatique tant que la métrique ne sera pas inférieure ou égale à 45 % (25 % en dessous de la cible de 60 %).
### Considérations relatives à Auto Scaling
Gardez les considérations suivantes à l'esprit :
+ Une politique de mise à l'échelle Suivi de la cible suppose qu'elle doit effectuer une montée en charge ; lorsque la métrique spécifiée est au-dessus de la valeur cible. Vous ne pouvez pas utiliser une politique de dimensionnement du suivi des cibles pour effectuer une mise à l'échelle lorsque la métrique spécifiée est inférieure à la valeur cible. ElastiCache pour Valkey et Redis OSS redimensionne les répliques au maximum (% d'écart arrondi par rapport à Target, 1 par défaut) des répliques existantes sur toutes les partitions du cluster.
+ Une politique de suivi des objectifs et d'échelonnement n'effectue pas de mise à l'échelle lorsque la métrique spécifiée a des données insuffisantes. Elle n'effectue pas de mise à l'échelle horizontale car elle n'interprète pas des données insuffisantes comme une faible utilisation.
+ Vous pouvez constater des écarts entre la valeur cible et les points de données de métrique réels. En effet, ElastiCache Auto Scaling agit toujours de manière prudente en arrondissant à la hausse ou à la baisse lorsqu'il détermine la capacité à ajouter ou à supprimer. Cela l'empêche d'ajouter une capacité insuffisante ou de retirer trop de capacité.
+ Pour garantir la disponibilité de l'application, le service augmente proportionnellement aux métriques aussi rapidement que possible, mais diminue plus progressivement avec une augmentation maximale d'un réplica sur toutes les partitions du cluster.
+ Vous pouvez avoir plusieurs politiques de dimensionnement du suivi des cibles ElastiCache pour un cluster Valkey et Redis OSS, à condition que chacune d'elles utilise une métrique différente. Auto Scaling a pour objectif de toujours prioriser la disponibilité. Son comportement varie donc selon que les politiques de suivi des cibles sont prêtes à être étendues ou intégrées. Il augmentera la taille du service si l'une des politiques Suivi de la cible est prête pour une augmentation de taille, mais la diminuera uniquement si toutes les politiques Suivi de la cible (avec la portion de diminution en charge activée) sont prêtes pour une diminution de taille.
+ Ne modifiez ni ne supprimez les CloudWatch alarmes gérées par ElastiCache Auto Scaling dans le cadre d'une politique de dimensionnement du suivi des cibles. Auto Scaling supprime automatiquement les alarmes lorsque vous supprimez la politique de dimensionnement ou lorsque vous supprimez le cluster.
+ ElastiCache Auto Scaling ne vous empêche pas de modifier manuellement les répliques entre les partitions. Ces ajustements manuels n'affectent pas les CloudWatch alarmes existantes associées à la politique de dimensionnement, mais peuvent avoir un impact sur les mesures susceptibles de déclencher ces CloudWatch alarmes.
+ Ces CloudWatch alarmes gérées par Auto Scaling sont définies sur la métrique AVG pour toutes les partitions du cluster. Ainsi, avoir des partitions chaudes peut entraîner l'un ou l'autre des scénarios suivants :
+ mise à l'échelle lorsqu'elle n'est pas nécessaire en raison de la charge sur quelques fragments chauds déclenchant une alarme CloudWatch
+ l'absence de mise à l'échelle lorsque cela est nécessaire en raison d'AVG agrégé sur toutes les partitions affectant l'alarme à ne pas briser.
+ ElastiCache les limites par défaut relatives aux nœuds par cluster s'appliquent toujours. Ainsi, lorsque vous optez pour Auto Scaling et si vous prévoyez que le nombre maximal de nœuds dépasse la limite par défaut, demandez une augmentation de limite à [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et choisissez le type de limite **Nodes per cluster per instance type (Nœuds par cluster par type d'instance)**.
+ Assurez-vous que votre VPC dispose d'un nombre suffisant d'interfaces réseau élastiques ENIs (Elastic Network Interfaces), nécessaires lors du scale-out. Pour de plus amples informations, veuillez consulter [Interfaces réseau Elastic](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Si la capacité disponible n'est pas suffisante EC2, ElastiCache Auto Scaling n'augmentera pas tant que la capacité ne sera pas disponible ou si vous modifiez manuellement le cluster en fonction des types d'instances dotés d'une capacité suffisante.
+ ElastiCache Auto Scaling ne prend pas en charge le dimensionnement des répliques avec un cluster contenant `ReservedMemoryPercent` moins de 25 %. Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
# Ajout d'une politique de mise à l'échelle
Vous pouvez ajouter une politique de dimensionnement à l'aide du AWS Management Console.
**Ajout d'une politique de dimensionnement à l'aide du AWS Management Console**
Pour ajouter une politique de dimensionnement automatique à ElastiCache Valkey et Redis OSS
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**.
1. Choisissez le cluster auquel vous voulez ajouter une stratégie (choisissez le nom du cluster et non pas le bouton situé à sa gauche).
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Choisissez **add dynamic scaling** (ajouter le dimensionnement dynamique).
1. Sous **Scaling policies** (Stratégies de dimensionnement), choisissez **Add dynamic scaling** (Ajouter le dimensionnement dynamique).
1. Pour **Policy name** (Nom de la politique), saisissez un nom de politique.
1. Pour **Scalable Dimension (Dimension évolutives)**, sélectionnez **Replicas (Réplicas)** dans la boîte de dialogue.
1. Pour la valeur cible, saisissez le pourcentage moyen d'utilisation du processeur que vous souhaitez conserver sur les ElastiCache répliques. Cette valeur doit être >=35 et <=70. Des réplicas de cluster sont ajoutés ou supprimés pour maintenir la métrique proche de la valeur spécifiée.
1. (Facultatif) les périodes de stabilisation de réduction ou de montée en charge ne sont pas prises en charge par la console. Utilisez le AWS CLI pour modifier les valeurs de refroidissement.
1. Pour **Capacité minimale**, saisissez le nombre minimum de répliques que la politique ElastiCache Auto Scaling doit maintenir.
1. Dans **Maximum capacity**, saisissez le nombre maximum de répliques que la politique ElastiCache Auto Scaling doit gérer. La valeur doit être >=5.
1. Choisissez **Créer**.
# Enregistrement d'une cible évolutive
Vous pouvez appliquer une politique de dimensionnement basée sur une métrique prédéfinie ou personnalisée. Pour ce faire, vous pouvez utiliser l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling. La première étape consiste à enregistrer votre groupe de réplication ElastiCache pour Valkey et Redis OSS auprès d'Auto Scaling.
Avant de pouvoir utiliser la mise à l'échelle ElastiCache automatique avec un cluster, vous devez enregistrer votre cluster auprès du dimensionnement ElastiCache automatique. Vous le faites pour définir la dimension de mise à l'échelle et les limites à appliquer à ce cluster. ElastiCache le dimensionnement automatique redimensionne dynamiquement le cluster selon la dimension `elasticache:replication-group:Replicas` évolutive, qui représente le nombre de répliques de cluster par partition.
**Utilisation de la CLI**
Pour enregistrer votre ElastiCache cluster, utilisez la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande avec les paramètres suivants :
+ --service-namespace : définissez cette valeur à elasticache.
+ --resource-id — Identifiant de ressource pour le cluster. ElastiCache Pour ce paramètre, le type de ressource est ReplicationGroup et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ --scalable-dimension : définit cette valeur à `elasticache:replication-group:Replicas`.
+ --min-capacity — Le nombre minimum de répliques à gérer par le dimensionnement automatique. ElastiCache Pour plus d'informations sur la relation entre --min-capacity, --max-capacity et le nombre de réplicas dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
+ --max-capacity — Le nombre maximum de répliques à gérer par le dimensionnement automatique. ElastiCache Pour plus d'informations sur la relation entre --min-capacity, --max-capacity et le nombre de réplicas dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Dans l'exemple suivant, vous enregistrez un ElastiCache cluster nommé`myscalablecluster`. L'enregistrement indique que le cluster doit être dimensionné de façon dynamique pour contenir de un à 5 réplicas.
Pour Linux, macOS ou Unix :
```
aws application-autoscaling register-scalable-target \
--service-namespace elasticache \
--resource-id replication-group/myscalablecluster \
--scalable-dimension elasticache:replication-group:Replicas \
--min-capacity 1 \
--max-capacity 5 \
```
Pour Windows :
```
aws application-autoscaling register-scalable-target ^
--service-namespace elasticache ^
--resource-id replication-group/myscalablecluster ^
--scalable-dimension elasticache:replication-group:Replicas ^
--min-capacity 1 ^
--max-capacity 5 ^
```
**Utilisation de l'API**
Pour enregistrer votre ElastiCache cluster, utilisez la [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)commande avec les paramètres suivants :
+ ServiceNamespace — Définissez cette valeur sur elasticache.
+ ResourceID — Identifiant de ressource pour le cluster. ElastiCache Pour ce paramètre, le type de ressource est ReplicationGroup et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ ScalableDimension — Définissez cette valeur sur`elasticache:replication-group:Replicas`.
+ MinCapacity — Le nombre minimum de répliques à gérer par le dimensionnement ElastiCache automatique. Pour plus d'informations sur la relation entre --min-capacity, --max-capacity et le nombre de réplicas dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity — Le nombre maximum de répliques à gérer par le dimensionnement ElastiCache automatique. Pour plus d'informations sur la relation entre --min-capacity, --max-capacity et le nombre de réplicas dans votre cluster, veuillez consulter [Capacité minimale et maximale](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Dans l'exemple suivant, vous enregistrez un cluster nommé `myscalablecluster` avec l'API Application Auto Scaling. Cet enregistrement indique que le cluster doit être dimensionné de façon dynamique pour contenir de un à 5 réplicas.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"MinCapacity": 1,
"MaxCapacity": 5
}
```
# Définition d'une politique de mise à l'échelle
Une configuration de politique de dimensionnement Suivi de la cible est représentée par un bloc JSON dans lequel sont définies les métriques et valeurs cibles. Vous pouvez enregistrer une configuration de politique de dimensionnement sous forme de bloc JSON dans un fichier texte. Vous utilisez ce fichier texte lorsque vous appelez l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling. Pour plus d'informations sur la syntaxe de la configuration d'une stratégie, consultez [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) dans le manuel *Référence d'API Application Auto Scaling*.
Les options suivantes sont disponibles pour définir une configuration de politique de suivi de cible et d'échelonnement :
**Topics**
+ [Utilisation d'une métrique prédéfinie](#AutoScaling-Predefined-Metric)
+ [Modification d'une politique de dimensionnement](AutoScaling-Editing-Policy.md)
+ [Suppression d'une politique de dimensionnement](AutoScaling-Deleting-Policy.md)
+ [Utilisation CloudFormation pour les politiques Auto Scaling](AutoScaling-with-Cloudformation.md)
+ [Mise à l’échelle planifiée](AutoScaling-with-Scheduled-Scaling-Replicas.md)
## Utilisation d'une métrique prédéfinie
Une configuration de politique de dimensionnement Suivi de la cible est représentée par un bloc JSON dans lequel sont définies les métriques et valeurs cibles. Vous pouvez enregistrer une configuration de politique de dimensionnement sous forme de bloc JSON dans un fichier texte. Vous utilisez ce fichier texte lorsque vous appelez l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling. Pour plus d'informations sur la syntaxe de la configuration d'une stratégie, consultez [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) dans le manuel *Référence d'API Application Auto Scaling*.
Les options suivantes sont disponibles pour définir une configuration de politique de suivi de cible et d'échelonnement :
**Topics**
+ [Utilisation d'une métrique prédéfinie](#AutoScaling-Predefined-Metric)
+ [Utilisation d'une métrique personnalisée](#AutoScaling-Custom-Metric)
+ [Utilisation des temps de stabilisation](#AutoScaling-Using-Cooldowns)
+ [Désactivation de l'activité de diminution en charge](#AutoScaling-Disabling-Scalein)
+ [Appliquer une politique de dimensionnement à un cluster ElastiCache pour Valkey et Redis OSS](#AutoScaling-Applying-Policy)
### Utilisation d'une métrique prédéfinie
En utilisant des métriques prédéfinies, vous pouvez définir rapidement une politique de dimensionnement pour le suivi des cibles ElastiCache pour un cluster Valkey et Redis OSS qui fonctionne avec le suivi des cibles dans Auto Scaling. ElastiCache Actuellement, ElastiCache prend en charge la métrique prédéfinie suivante dans ElastiCache Replicas Auto Scaling :
`ElastiCacheReplicaEngineCPUUtilization`— La valeur moyenne de la CPUUtilization métrique Engine pour CloudWatch toutes les répliques du cluster. Vous trouverez la valeur de la métrique agrégée ci-dessous ElastiCache `ReplicationGroupId, Role` pour CloudWatch Required ReplicationGroupId et Role Replica.
Pour utiliser une métrique prédéfinie dans votre politique de dimensionnement, créez une configuration de suivi de la cible pour votre politique de dimensionnement. Cette configuration doit inclure `PredefinedMetricSpecification` pour la métrique prédéfinie et `TargetValue` pour la valeur cible de cette métrique.
### Utilisation d'une métrique personnalisée
L'utilisation de métriques personnalisées vous permet de définir une stratégie de dimensionnement Suivi de la cible répondant à vos exigences personnelles. Vous pouvez définir une métrique personnalisée basée sur n'importe quelle métrique ElastiCache pour Valkey et Redis OSS qui change proportionnellement à la mise à l'échelle. Toutes les ElastiCache mesures ne fonctionnent pas pour le suivi des cibles. La métrique doit être une métrique d'utilisation valide et décrire le degré d'occupation d'une instance. La valeur de la métrique doit augmenter ou diminuer proportionnellement au nombre de réplicas dans le cluster. Cette augmentation ou diminution proportionnelle est nécessaire pour que les données de la métrique puissent être utilisées afin d'augmenter ou de réduire proportionnellement le nombre de réplicas .
**Example**
L'exemple suivant décrit une configuration de suivi de la cible pour une politique de dimensionnement. Dans cette configuration, une métrique personnalisée ajuste un cluster en fonction d'une utilisation moyenne du processeur de 50 % pour toutes les répliques d'un cluster nommé. `my-db-cluster`
```
{"TargetValue": 50,
"CustomizedMetricSpecification":
{"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{"Name": "ReplicationGroup","Value": "my-db-cluster"},
{"Name": "Role","Value": "REPLICA"}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
```
### Utilisation des temps de stabilisation
Vous pouvez spécifier une valeur, en secondes, pour que `ScaleOutCooldown` ajoute un temps de stabilisation à la montée en puissance de votre cluster. De la même manière, vous pouvez ajouter une valeur, en secondes, pour que `ScaleInCooldown` ajoute un temps de stabilisation pour la diminution de charge de votre cluster. Pour plus d'informations sur `ScaleInCooldown` et `ScaleOutCooldown`, consultez [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) dans le manuel *Référence d'API Application Auto Scaling*. L'exemple suivant décrit une configuration de suivi de la cible pour une politique de dimensionnement. Dans cette configuration, la métrique `ElastiCacheReplicaEngineCPUUtilization` prédéfinie est utilisée pour ajuster un cluster en fonction d'une utilisation moyenne du processeur de 40 % pour toutes les répliques de ce cluster. La configuration indique un temps de stabilisation de diminution en charge de 10 minutes et un temps de stabilisation de montée en charge de 5 minutes.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
### Désactivation de l'activité de diminution en charge
Vous pouvez empêcher la configuration de la politique de dimensionnement du suivi des cibles de s'adapter à votre cluster ElastiCache for Valkey et Redis OSS en désactivant l'activité de dimensionnement. La désactivation de l'activité de diminution en charge empêche la politique de mise à l'échelle de supprimer des réplicas, tout en l'autorisant encore à les créer si nécessaire.
Vous pouvez spécifier une valeur booléenne pour que `DisableScaleIn` active ou désactive l'activité de diminution en charge de votre cluster. Pour plus d'informations sur `DisableScaleIn`, consultez [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) dans le manuel *Référence d'API Application Auto Scaling*.
**Example**
L'exemple suivant décrit une configuration de suivi de la cible pour une politique de dimensionnement. Dans cette configuration, la métrique `ElastiCacheReplicaEngineCPUUtilization` prédéfinie ajuste un cluster en fonction d'une utilisation moyenne du processeur de 40 % pour toutes les répliques de ce cluster. La configuration désactive l'activité de diminution en charge pour la politique de dimensionnement.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
### Appliquer une politique de dimensionnement à un cluster ElastiCache pour Valkey et Redis OSS
Après avoir enregistré votre cluster auprès ElastiCache de Valkey et Redis OSS Auto Scaling et défini une politique de dimensionnement, vous appliquez la politique de dimensionnement au cluster enregistré. Pour appliquer une politique de dimensionnement à un cluster ElastiCache pour Valkey et Redis OSS, vous pouvez utiliser l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling.
**À l'aide du AWS CLI**
Pour appliquer une politique de dimensionnement à votre cluster ElastiCache for Valkey et Redis OSS, utilisez la [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)commande avec les paramètres suivants :
+ --policy-name : nom de la politique de mise à l'échelle.
+ --policy-type : définissez cette valeur à `TargetTrackingScaling`.
+ --resource-id — Identifiant de ressource pour le cluster. Pour ce paramètre, le type de ressource est ReplicationGroup et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ --service-namespace : définissez cette valeur à elasticache.
+ --scalable-dimension : définit cette valeur à `elasticache:replication-group:Replicas`.
+ -- target-tracking-scaling-policy -configuration — Configuration de la politique de dimensionnement du suivi des cibles à utiliser pour le cluster.
**Example**
Dans l'exemple suivant, vous appliquez une politique de dimensionnement de suivi des cibles nommée `myscalablepolicy` à un cluster nommé avec mise à l'échelle `myscalablecluster` ElastiCache automatique. Pour ce faire, vous utilisez une configuration de politique enregistrée dans un fichier nommé `config.json`.
Pour Linux, macOS ou Unix :
```
aws application-autoscaling put-scaling-policy \
--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
--target-tracking-scaling-policy-configuration file://config.json
```
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
Pour Windows :
```
aws application-autoscaling put-scaling-policy ^
--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:Replicas ^
--target-tracking-scaling-policy-configuration file://config.json
```
**Utilisation de l'API**
Pour appliquer une politique de dimensionnement à votre ElastiCache cluster avec l'API Application Auto Scaling, utilisez l'opération [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)Application Auto Scaling API avec les paramètres suivants :
+ PolicyName — Le nom de la politique de dimensionnement.
+ PolicyType — Définissez cette valeur sur`TargetTrackingScaling`.
+ ResourceID — Identifiant de ressource pour le cluster. Pour ce paramètre, le type de ressource est ReplicationGroup et l'identifiant unique est le nom du ElastiCache cluster Redis OSS, par exemple`replication-group/myscalablecluster`.
+ ServiceNamespace — Définissez cette valeur sur elasticache.
+ ScalableDimension — Définissez cette valeur sur`elasticache:replication-group:Replicas`.
+ TargetTrackingScalingPolicyConfiguration — La configuration de la politique de dimensionnement du suivi des cibles à utiliser pour le cluster.
**Example**
Dans l'exemple suivant, vous appliquez une politique de dimensionnement de suivi des cibles nommée `scalablepolicy` à un cluster nommé avec mise à l'échelle `myscalablecluster` ElastiCache automatique. Vous utilisez une configuration de politique basée sur la métrique prédéfinie `ElastiCacheReplicaEngineCPUUtilization`.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
}
}
}
```
# Modification d'une politique de dimensionnement
Vous pouvez modifier une politique de dimensionnement à l'aide de l' AWS Management Console API Application Auto Scaling ou de l'API Application Auto Scaling. AWS CLI
**Modification d'une politique de dimensionnement à l'aide du AWS Management Console**
Vous pouvez uniquement modifier des politiques avec le type métrique prédéfinies à l'aide de la AWS Management Console
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**
1. Choisissez le cluster auquel vous voulez ajouter une stratégie (choisissez le nom du cluster et non pas le bouton situé à sa gauche).
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Sous **Scaling policies** (Stratégies de dimensionnement), choisissez le bouton à gauche de la stratégie Auto Scaling que vous voulez changer, puis choisissez **Modify** (Modifier).
1. Apportez les modifications nécessaires à la politique.
1. Sélectionnez **Modifier**.
1. Apportez des modifications à la politique.
1. Sélectionnez **Modifier**.
**Modification d'une politique de dimensionnement à l'aide de l'API Application Auto Scaling AWS CLI ou de l'API Application Auto Scaling**
Vous pouvez utiliser l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling pour modifier une politique de dimensionnement de la même manière que vous appliquez une politique de dimensionnement :
+ Lorsque vous utilisez l'API Application Auto Scaling, spécifiez le nom de la politique à modifier dans le paramètre `PolicyName`. Spécifiez de nouvelles valeurs pour les paramètres que vous souhaitez modifier.
Pour de plus amples informations, veuillez consulter [Appliquer une politique de dimensionnement à un cluster ElastiCache pour Valkey et Redis OSS](AutoScaling-Defining-Policy.md#AutoScaling-Applying-Policy).
# Suppression d'une politique de dimensionnement
Vous pouvez supprimer une politique de dimensionnement à l' AWS Management Console aide de l' AWS CLI API Application Auto Scaling
**Suppression d'une politique de dimensionnement à l'aide du AWS Management Console**
Vous pouvez uniquement modifier des politiques avec le type métrique prédéfinies à l'aide de la AWS Management Console
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**
1. Choisissez le cluster dont vous voulez supprimer la politique Auto Scaling.
1. Cliquez sur l'onglet **Auto Scaling policies (Politiques de scalabilité automatique)**.
1. Sous **Scaling policies** (Stratégies de dimensionnement), choisissez la stratégie Auto Scaling, puis choisissez **Delete** (Supprimer).
**Suppression d'une politique de dimensionnement à l'aide de l'API Application Auto Scaling AWS CLI ou de l'API Application Auto Scaling**
Vous pouvez utiliser l'API Application Auto Scaling AWS CLI ou l'API Application Auto Scaling pour supprimer une politique de dimensionnement d'un ElastiCache cluster.
**INTERFACE DE LIGNE DE COMMANDE (CLI)**
Pour supprimer une politique de dimensionnement de votre cluster ElastiCache pour Valkey et Redis OSS, utilisez la [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html)commande avec les paramètres suivants :
+ --policy-name : nom de la politique de mise à l'échelle.
+ --resource-id — Identifiant de ressource pour le cluster. Pour ce paramètre, le type de ressource est ReplicationGroup et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ --service-namespace : définissez cette valeur à elasticache.
+ --scalable-dimension – Définit cette valeur à `elasticache:replication-group:Replicas`.
**Example**
Dans l'exemple suivant, vous supprimez une politique de suivi de cible et d'échelonnement nommée `myscalablepolicy` d'un cluster ELC; nommé `myscalablecluster`.
Pour Linux, macOS ou Unix :
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
```
Pour Windows :
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:Replicas ^
```
**API**
Pour supprimer une politique de dimensionnement de votre cluster ElastiCache pour Valkey et Redis OSS, utilisez l'opération d'API [DeleteScalingPolicy](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html)Application Auto Scaling avec les paramètres suivants :
+ PolicyName — Le nom de la politique de dimensionnement.
+ ResourceID — Identifiant de ressource pour le cluster. Pour ce paramètre, le type de ressource est ReplicationGroup et l'identifiant unique est le nom du cluster, par exemple`replication-group/myscalablecluster`.
+ ServiceNamespace — Définissez cette valeur sur elasticache.
+ ScalableDimension — Définissez cette valeur sur`elasticache:replication-group:Replicas`.
Dans l'exemple suivant, vous supprimez une politique de dimensionnement de suivi des cibles nommée à `myscalablepolicy` partir d'un cluster nommé `myscalablecluster` avec l'API Application Auto Scaling.
```
POST / HTTP/1.1
>>>>>>> mainline
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas"
}
```
# Utilisation CloudFormation pour les politiques Auto Scaling
Cet extrait montre comment créer une action planifiée et l'appliquer à une [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)ressource utilisant cette ressource. [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) Elle utilise les fonctions intrinsèques [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) et [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) pour construire la propriété `ResourceId` avec le nom logique de la ressource `AWS::ElastiCache::ReplicationGroup` qui est spécifiée dans le même modèle.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:Replicas'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCacheReplicaEngineCPUUtilization
TargetValue: 40
```
# Mise à l’échelle planifiée
La mise à l’échelle en fonction d’une planification vous permet de mettre à l’échelle l’application en réponse aux changements de demande. Pour utiliser le dimensionnement planifié, vous créez des actions planifiées qui indiquent ElastiCache à Valkey et Redis OSS d'effectuer des activités de dimensionnement à des moments précis. Lorsque vous créez une action planifiée, vous spécifiez un ElastiCache cluster existant, le moment où l'activité de dimensionnement doit avoir lieu, la capacité minimale et la capacité maximale. Vous pouvez créer des actions planifiées pour une mise à l’échelle unique ou selon une planification récurrente.
Vous ne pouvez créer une action planifiée que pour les ElastiCache clusters déjà existants. Vous ne pouvez pas créer une action planifiée en même temps que vous créez un cluster.
Pour plus d'informations sur la terminologie relative à la création, à la gestion et à la suppression d'actions planifiées, veuillez consulter [Commandes généralement utilisées pour la création, la gestion et la suppression d'actions planifiées](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**Pour créer une action planifiée unique :**
Similaire à la dimension partition. Consultez [Mise à l’échelle planifiée](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Pour supprimer une action planifiée**
Similaire à la dimension partition. Consultez [Mise à l’échelle planifiée](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Pour gérer la mise à l'échelle planifiée à l'aide de la AWS CLI **
Utilisez la mise à l'échelle automatique des applications APIs suivante :
+ [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)
+ [describe-scheduled-actions](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scheduled-actions.html)
+ [delete-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scheduled-action.html)
## CloudFormation À utiliser pour créer des politiques Auto Scaling
Cet extrait montre comment créer une action planifiée et l'appliquer à une [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)ressource utilisant cette ressource. [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) Elle utilise les fonctions intrinsèques [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) et [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) pour construire la propriété `ResourceId` avec le nom logique de la ressource `AWS::ElastiCache::ReplicationGroup` qui est spécifiée dans le même modèle.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScheduledActions:
- EndTime: '2020-12-31T12:00:00.000Z'
ScalableTargetAction:
MaxCapacity: '5'
MinCapacity: '2'
ScheduledActionName: First
Schedule: 'cron(0 18 * * ? *)'
```
# Modification du mode cluster
Valkey et Redis OSS sont des bases de données en mémoire distribuées qui prennent en charge le sharding et la réplication. ElastiCache Les clusters Valkey et Redis OSS sont l'implémentation distribuée qui permet de partitionner les données sur plusieurs nœuds. Un cluster ElastiCache pour Redis OSS possède deux modes de fonctionnement, le mode cluster activé (CME) et le mode cluster désactivé (CMD). Dans CME, un moteur Valkey et Redis OSS fonctionne comme une base de données distribuée avec plusieurs partitions et nœuds, tandis que dans CMD, Valkey et Redis OSS fonctionnent comme un seul nœud.
Avant d'effectuer une migration de CMD à CME, les conditions suivantes doivent être remplies :
**Important**
La configuration du mode cluster ne peut être modifiée que du mode cluster désactivé vers le mode cluster activé. Il n'est pas possible d'inverser cette configuration.
+ Le cluster ne peut avoir que des clés dans la base de données 0 uniquement.
+ Les applications doivent utiliser un client Valkey ou Redis OSS capable d'utiliser le protocole Cluster et d'utiliser un point de terminaison de configuration.
+ Le basculement automatique doit être activé sur le cluster avec au moins 1 réplica.
+ La version minimale du moteur requise pour la migration est Valkey 7.2 et versions ultérieures, ou Redis OSS 7.0 et versions ultérieures.
Afin de migrer de CMD vers CME, la configuration du mode cluster doit être modifiée du mode cluster désactivé vers le mode cluster activé. Il s'agit d'une procédure en deux étapes qui garantit la disponibilité du cluster pendant le processus de migration.
**Note**
Vous devez fournir un groupe de paramètres avec une configuration de cluster activé, c'est-à-dire que le paramètre de cluster activé est défini sur `yes`. Si vous utilisez un groupe de paramètres par défaut, ElastiCache pour Redis, OSS choisira automatiquement le groupe de paramètres par défaut correspondant avec une configuration compatible avec les clusters. La valeur du paramètre de cluster activé est définie sur `no` pour un cluster CMD. Lorsque le cluster passe en mode compatible, la valeur du paramètre de cluster activé est mise à jour vers `yes` dans le cadre de l'action de modification.
Pour de plus amples informations, consultez [Configuration des paramètres du moteur à l'aide de groupes de ElastiCache paramètres](ParameterGroups.md).
1. **Préparation** : créez un cluster CME de test et assurez-vous que votre stack est prêt à fonctionner avec celui-ci. ElastiCache pour Redis OSS n'a aucun moyen de vérifier que vous êtes prêt. Pour de plus amples informations, veuillez consulter [Création d'un cluster pour Valkey ou Redis OSS](Clusters.Create.md).
1. **Modifier la configuration existante du cluster CMD pour qu'elle soit compatible avec le mode cluster** — Dans ce mode, une seule partition sera déployée et, ElastiCache pour Redis OSS, elle fonctionnera comme un nœud unique mais également comme un cluster de partitions unique. Le mode compatible signifie que l'application cliente peut utiliser l'un ou l'autre des protocoles pour communiquer avec le cluster. Dans ce mode, les applications doivent être reconfigurées pour commencer à utiliser le protocole Valkey ou Redis OSS Cluster et le point de terminaison de configuration. Pour passer du mode cluster Valkey ou Redis OSS au mode cluster compatible, suivez les étapes ci-dessous :
**Note**
En mode compatible, les autres opérations de modification telles que la mise à l'échelle et la version du moteur ne sont pas autorisées pour le cluster. De plus, les paramètres (à l'exception`cacheParameterGroupName`) ne peuvent pas être modifiés lors de la définition d'un paramètre en mode cluster dans la demande. [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
1. Utilisation du mode cluster AWS Management Console, consultez [Modification d'un groupe de réplication](Replication.Modify.md) et réglez le mode cluster sur **Compatible**
1. À l'aide de l'API, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)et mettez à jour le `ClusterMode` paramètre sur`compatible`.
1. À l'aide de AWS CLI, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)et mettez à jour le `cluster-mode` paramètre sur`compatible`.
Après avoir changé le mode de cluster Valkey ou Redis OSS en mode cluster compatible, l'[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API renverra le point de terminaison de configuration du ElastiCache cluster Redis OSS. Le point de terminaison de configuration du cluster est un point de terminaison unique qui peut être utilisé par les applications pour se connecter au cluster. Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md).
1. **Modifier la configuration du cluster en mode cluster activé** : une fois que le mode cluster est défini comme compatible avec le mode cluster, la deuxième étape consiste à modifier la configuration du cluster en mode cluster activé. Dans ce mode, une seule partition est en cours d'exécution et les clients peuvent désormais mettre à l'échelle leurs clusters ou modifier d'autres configurations de cluster.
Pour activer le mode cluster, procédez comme suit :
Avant de commencer, assurez-vous que vos clients Valkey ou Redis OSS ont migré vers le protocole de cluster et que le point de terminaison de configuration du cluster n'est pas utilisé.
1. À l'aide de AWS Management Console, consultez [Modification d'un groupe de réplication](Replication.Modify.md) et réglez le mode cluster sur **Activé**.
1. À l'aide de l'API, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)et mettez à jour le `ClusterMode` paramètre sur`enabled`.
1. À l'aide de AWS CLI, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)et mettez à jour le `cluster-mode` paramètre sur`enabled`.
Après avoir changé le mode cluster en mode activé, les points de terminaison seront configurés conformément à la spécification du cluster Valkey ou Redis OSS. L'[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API renverra le paramètre du mode cluster sous forme `enabled` de points de terminaison du cluster qui sont désormais disponibles pour être utilisés par les applications pour se connecter au cluster.
Notez que les points de terminaison du cluster changent une fois que le mode cluster devient activé. Veillez à mettre à jour vos applications à l'aide des nouveaux points de terminaison.
Vous pouvez également choisir de revenir au mode cluster désactivé (CMD) à partir du mode cluster compatible et de conserver les configurations d'origine.
**Modifier la configuration du cluster du mode cluster activé au mode cluster désactivé**
1. Utilisation du mode cluster AWS Management Console, consultez [Modification d'un groupe de réplication](Replication.Modify.md) et réglez le mode cluster sur **Disabled**
1. À l'aide de l'API, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)et mettez à jour le `ClusterMode` paramètre sur`disabled`.
1. À l'aide de AWS CLI, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)et mettez à jour le `cluster-mode` paramètre sur`disabled`.
Une fois le mode cluster désactivé, l'[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API renvoie le paramètre du mode cluster sous la forme`disabled`.
# Réplication entre AWS régions à l'aide de banques de données mondiales
**Note**
Global Datastore n'est actuellement disponible que pour les clusters basés sur des nœuds.
En utilisant la fonctionnalité Global Datastore, vous pouvez utiliser une réplication de clusters Valkey ou Redis OSS entièrement gérée, rapide, fiable et sécurisée dans toutes les régions.AWS Grâce à cette fonctionnalité, vous pouvez créer des clusters de répliques de lecture entre régions pour permettre des lectures à faible latence et une reprise après sinistre dans toutes les régions AWS.
Dans les sections suivantes, vous trouverez une description de l'utilisation des magasins de données globaux.
**Topics**
+ [Présentation de](#Redis-Global-Data-Stores-Overview)
+ [Conditions préalables et limitations](Redis-Global-Datastores-Getting-Started.md)
+ [Utilisation des entrepôts de données globaux (console)](Redis-Global-Datastores-Console.md)
+ [Utilisation des entrepôts de données globaux (CLI)](Redis-Global-Datastores-CLI.md)
## Présentation de
Chaque *magasin de donnée global* est un ensemble d'un ou de plusieurs clusters qui se répliquent les uns sur les autres.
Un magasin de données global se compose des éléments suivants :
+ **Cluster principal (actif)** : un cluster principal accepte les écritures répliquées dans tous les clusters de l'entrepôt de données global. Un cluster principal accepte également les demandes de lecture.
+ **Cluster secondaire (passif)** : un cluster secondaire accepte uniquement les demandes de lecture et réplique les mises à jour de données à partir d'un cluster principal. Un cluster secondaire doit se trouver dans une AWS région différente de celle du cluster principal.
Lorsque vous créez une banque de données globale ElastiCache pour Valkey ou Redis OSS, elle réplique automatiquement vos données du cluster principal vers le cluster secondaire. Vous choisissez la AWS région dans laquelle les données Valkey ou Redis OSS doivent être répliquées, puis vous créez un cluster secondaire dans cette région.AWS ElastiCache configure et gère ensuite la réplication automatique et asynchrone des données entre les deux clusters.
L'utilisation d'une banque de données globale pour Valkey ou Redis OSS présente les avantages suivants :
+ **Performances géolocalisées** — En configurant des clusters de répliques distants dans des AWS régions supplémentaires et en synchronisant vos données entre elles, vous pouvez réduire la latence d'accès aux données dans cette région.AWS Une banque de données mondiale peut contribuer à améliorer la réactivité de votre application en proposant des lectures géolocalisées à faible latence dans toutes les régions.AWS
+ **Reprise après sinistre** : si votre cluster principal d'un entrepôt de données global subit une dégradation, vous pouvez promouvoir un cluster secondaire en tant que nouveau cluster principal. Vous pouvez le faire en vous connectant à n'importe quelle AWS région contenant un cluster secondaire.
Le schéma suivant montre le fonctionnement des magasins de données globaux.
![\[magasin de données global\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/Global-DataStore.png)
# Conditions préalables et limitations
Avant de commencer à utiliser les magasins de données globaux, tenez compte des éléments suivants :
+ Les banques de données mondiales sont prises en charge dans les régions suivantes : AWS
+ **Afrique** - Cape Town
+ **Asie-Pacifique** : Hong Kong, Hyderabad, Jakarta, Malaisie, Melbourne, Mumbai, Osaka, Séoul, Singapour, Sydney, Thaïlande et Tokyo
+ **Canada** - Centre du Canada et Canada Ouest (Calgary)
+ **Chine** - Pékin et Ningxia
+ **Europe** : Francfort, Londres, Irlande, Milan, Paris, Espagne, Stockholm et Zurich
+ **AWS GovCloud**-US-Ouest et US-Est
+ **Israël** - Tel Aviv
+ **Moyen-Orient** - Bahreïn et Émirats arabes unis
+ **États-Unis** - Est (Virginie du Nord et Ohio) et États-Unis Ouest (Californie du Nord et Oregon)
+ **Amérique du Sud** - Mexique (centre) et São Paulo
+ Tous les clusters (primaire et secondaire) de votre entrepôt de données global doivent avoir le même nombre de nœuds principaux, type de nœud, version du moteur et nombre de partitions (dans le cas où le mode cluster est activé). Chaque cluster de votre magasin de données global peut comporter un nombre différent de réplicas en lecture afin de tenir compte du trafic de lecture local vers ce cluster.
La réplication doit être activée si vous prévoyez d'utiliser un cluster à un seul nœud existant.
+ Les banques de données globales sont prises en charge sur les instances de grande taille ou supérieure.
+ Vous pouvez configurer la réplication d'un cluster principal d'une AWS région vers un cluster secondaire dans deux autres AWS régions au maximum.
**Note**
Les régions Chine (Beijing) et Chine (Ningxia), où la réplication ne peut se produire qu'entre les deux régions.
+ Vous pouvez utiliser les magasins de données globaux uniquement dans des clusters VPC. Pour de plus amples informations, veuillez consulter [Modèles d'accès pour accéder à un ElastiCache cache dans un Amazon VPC](elasticache-vpc-accessing.md). Les banques de données globales ne sont pas prises en charge lorsque vous utilisez EC2 -Classic. Pour plus d'informations, consultez [EC2-Classic](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-classic-platform.html) dans le *guide de l' EC2 utilisateur Amazon*.
**Note**
Pour le moment, vous ne pouvez pas utiliser les entrepôts de données globaux dans [Utilisation de zones locales avec ElastiCache](Local_zones.md).
+ ElastiCache ne prend pas en charge le basculement automatique d'une AWS région à l'autre. Si nécessaire, vous pouvez promouvoir manuellement un cluster secondaire. Pour obtenir un exemple, consultez [Promotion du cluster secondaire en cluster principal](Redis-Global-Datastores-Console.md#Redis-Global-Datastores-Console-Promote-Secondary).
+ Pour amorcer à partir de données existantes, utilisez un cluster existant en tant que cluster principal pour créer un magasin de données global. Nous ne prenons pas en charge l'ajout d'un cluster existant en tant que cluster secondaire. Le processus d'ajout d'un cluster existant en tant que cluster secondaire efface les données, ce qui peut entraîner une perte de données.
+ Les mises à jour de paramètres sont appliquées à tous les clusters lorsque vous modifiez un groupe de paramètres local d'un cluster appartenant à un magasin de données global.
+ Vous pouvez mettre à l'échelle les clusters régionaux à la fois verticalement (augmentation et diminution) et horizontalement (ajustement à la hausse et à la baisse). Vous pouvez mettre à l'échelle les clusters en modifiant le magasin de données global. Tous les clusters régionaux du magasin de données global sont ensuite mis à l'échelle sans interruption. Pour de plus amples informations, veuillez consulter [Dimensionnement ElastiCache](Scaling.md).
+ [Les banques de données mondiales prennent en charge [le chiffrement au repos, le](at-rest-encryption.md)[chiffrement en transit](in-transit-encryption.md) et l'AUTH.](auth.md)
+ Les banques de données globales ne prennent pas en charge le protocole Internet version 6 ()IPv6.
+ Les banques de données mondiales prennent en charge les clés AWS KMS . Pour plus d'informations, veuillez consulter les [Concepts du service de gestion des clés AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys) dans le *Guide du développeur AWS Key Management Service *.
**Note**
Les magasins de données globaux prennent en charge la [messagerie pub/sub (publish/subscribe - publier/abonner)](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-use-cases.html#elasticache-for-redis-use-cases-messaging) avec les conditions suivantes :
Si le mode cluster est désactivé, il pub/sub est entièrement pris en charge. Les événements publiés sur le cluster principal de la AWS région principale sont propagés aux AWS régions secondaires.
Lorsque le mode cluster est activé, les conditions suivantes s'appliquent :
Pour les événements publiés qui ne figurent pas dans un keyspace, seuls les abonnés de la même AWS région reçoivent les événements.
Pour les événements keyspace publiés, les abonnés de toutes les AWS régions reçoivent les événements.
# Utilisation des entrepôts de données globaux (console)
Pour créer un magasin de données global à l'aide de la console, suivez ce processus en deux étapes :
1. Créez un cluster principal, soit en utilisant un cluster existant, soit en créant un nouveau cluster. Le moteur doit être Valkey 7.2 ou version ultérieure, ou Redis OSS 5.0.6 ou version ultérieure.
1. Ajoutez jusqu'à deux clusters secondaires dans différentes AWS régions, toujours en utilisant Valkey 7.2 ou version ultérieure, ou Redis OSS 5.0.6 ou version ultérieure.
Les procédures suivantes vous expliquent comment créer une banque de données globale pour Valkey ou Redis OSS et comment effectuer d'autres opérations à l'aide de la console. ElastiCache
**Topics**
+ [Création d'un entrepôt de données global à l'aide d'un cluster existant](#Redis-Global-Datastores-Console-Create-Primary)
+ [Création d'un entrepôt de données global à l'aide d'un nouveau cluster principal](#Redis-Global-Datastores-Create-From-Scratch)
+ [Affichage des détails de l'entrepôt de données global](#Redis-Global-Datastores-Console-Details)
+ [Ajout d'une région à un entrepôt de données global](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Modification d'un entrepôt de données global](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
+ [Promotion du cluster secondaire en cluster principal](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Suppression d'une région d'un entrepôt de données global](#Redis-Global-Datastore-Console-Remove-Region)
+ [Suppression d'un entrepôt de données global](#Redis-Global-Datastores-Console-Delete-GlobalDatastore)
## Création d'un entrepôt de données global à l'aide d'un cluster existant
Dans ce scénario, vous utilisez un cluster existant comme cluster principal du nouveau magasin de données global. Vous créez ensuite un cluster secondaire, en lecture seule, dans une autre région AWS . Ce cluster secondaire reçoit des mises à jour automatiques et asynchrones du cluster principal.
**Important**
Le cluster existant doit utiliser un moteur Valkey 7.2 ou version ultérieure ou Redis OSS 5.0.6 ou version ultérieure.
**Pour créer un magasin de données global à l'aide d'un cluster existant**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Global Datastores**, puis **Create global** datastore.
1. Sur la page des **paramètres du cluster principal**, procédez comme suit :
+ Dans le champ **Informations sur la banque de données globale**, entrez le nom de la nouvelle banque de données globale.
+ (Facultatif) Entrez une valeur dans le champ **Description**.
1. Sous **Cluster régional**, sélectionnez **Utiliser le cluster régional existant**.
1. Sous **Cluster existant**, sélectionnez le cluster existant que vous souhaitez utiliser.
1. Ne modifiez pas les options suivantes. Elles sont prérenseignées pour correspondre à la configuration du cluster principal. Vous ne pouvez pas les modifier.
+ Version de moteur
+ Type de nœud
+ Groupe de paramètres
**Note**
ElastiCache génère automatiquement un nouveau groupe de paramètres à partir des valeurs du groupe de paramètres fourni et applique le nouveau groupe de paramètres au cluster. Utilisez ce nouveau groupe de paramètres pour modifier les paramètres d'un entrepôt de données global. Chaque groupe de paramètres généré automatiquement est associé à un seul cluster et, par conséquent, à un seul entrepôt de données global.
+ Nombre de partitions
+ Chiffrement au repos : active le chiffrement des données stockées sur le disque. Pour de plus amples informations, veuillez consulter [Chiffrement au repos](at-rest-encryption.md).
**Note**
Vous pouvez fournir une autre clé de chiffrement en choisissant la **clé AWS KMS gérée par le client** et en choisissant la clé. Pour plus d'informations, consultez la section [Utilisation de clés AWS KMS gérées par le client](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Chiffrement en transit : permet le chiffrement des données sur le câble. Pour de plus amples informations, veuillez consulter [Chiffrement en transit](in-transit-encryption.md). Pour Valkey 7.2 et versions ultérieures et Redis OSS 6.0 et versions ultérieures, si vous activez le chiffrement en transit, vous êtes invité à spécifier l'une des options de contrôle d'**accès** suivantes :
+ **Aucun contrôle d'accès** : il s'agit du paramètre par défaut. Cela indique qu'il n'y a pas de restrictions.
+ **Liste de contrôle d'accès aux groupes d'utilisateurs** : choisissez un groupe d'utilisateurs avec un ensemble défini d'utilisateurs et d'autorisations sur les opérations disponibles. Pour de plus amples informations, veuillez consulter [Gestion des groupes d'utilisateurs avec la console et la CLI](Clusters.RBAC.md#User-Groups).
+ **Utilisateur par défaut AUTH** : mécanisme d'authentification pour un serveur Valkey ou Redis OSS. Pour plus d'informations, consultez [AUTH.](auth.md)
1. (Facultatif) Si besoin, mettez à jour les autres paramètres des clusters secondaires. Ils sont prérenseignés avec les mêmes valeurs que celles du cluster principal, mais vous pouvez les mettre à jour pour répondre à des exigences spécifiques pour ce cluster.
+ Port
+ Nombre de réplicas
+ Groupe de sous-réseaux
+ Zone(s) de disponibilité préférée(s)
+ Groupes de sécurité
+ Géré par le client (cléAWS KMS)
+ Jeton AUTH
+ Activer les sauvegardes automatiques
+ Période de rétention des sauvegardes
+ Fenêtre de sauvegarde
+ Fenêtre de maintenance
+ Rubrique pour la notification SNS
1. Choisissez **Créer**. Cette opération définit l'état du magasin de données global sur **Creating (En cours de création)**. L'état passe à **Modifying (En cours de modification)** après association du cluster principal au magasin de données global et passage du cluster secondaire à l'état **Associating (En cours d'association)** .
Une fois que le cluster principal et les clusters secondaires sont associés au magasin de données global, l'état passe à **Available (Disponible)**. À ce stade, vous disposez d'un cluster principal qui accepte les lectures et les écritures, et de clusters secondaires qui acceptent les lectures répliquées à partir du cluster principal.
La page est mise à jour pour indiquer si un cluster fait partie d'une banque de données globale, notamment :
+ **Global Datastore (Magasin de données global)** : nom de l'entrepôt de données global auquel appartient le cluster.
+ **Global Datastore Role (Rôle de l'entrepôt de données global)** : rôle du cluster, principal ou secondaire.
Vous pouvez ajouter jusqu'à un cluster secondaire supplémentaire dans une AWS région différente. Pour de plus amples informations, veuillez consulter [Ajout d'une région à un entrepôt de données global](#Redis-Global-Datastores-Console-Create-Secondary).
## Création d'un entrepôt de données global à l'aide d'un nouveau cluster principal
Si vous choisissez de créer un entrepôt de données global avec un nouveau cluster, procédez comme suit.
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Global Datastores**, puis **Create global** datastore.
1. Sous **Primary cluster settings** (Paramètres de cluster principal), procédez comme suit :
1. Pour **Cluster mode** (Mode du cluster), choisissez **Enabled** (Activé) ou **Disabled** (Désactivé).
1. Pour les **informations sur la banque de données globale**, entrez une valeur pour le **nom**. ElastiCache utilise le suffixe pour générer un nom unique pour la banque de données globale. Vous pouvez rechercher l'entrepôt de données global à l'aide du suffixe que vous spécifiez ici.
1. (Facultatif) Entrez une valeur pour **Global Datastore Description (Description du magasin de données global)**.
1. Sous **Regional cluster** (Cluster régional) :
1. Pour **Région**, choisissez une AWS région disponible.
1. Choisissez **Create new regional cluster** (Créer un nouveau cluster régional) ou **Use existing regional cluster** (Utiliser un cluster régional existant)
1. Si vous choisissez **Create new regional cluster** (Créer un nouveau cluster régional), sous **Cluster info** (Infos sur le cluster), saisissez un nom et une description facultative du cluster.
1. Sous **Location** (Emplacement), nous vous recommandons d'accepter les paramètres par défaut pour **Multi-AZ** et **Auto-failover** (Basculement automatique).
1. Sous **Cluster settings** (Paramètres de cluster)
1. Pour **Engine version** (Version du moteur), choisissez une version disponible, à savoir 5.0.6 ou ultérieure.
1. Pour **Port**, utilisez le port par défaut, 6379. Si vous avez une raison d'utiliser un autre port, saisissez le numéro de port.
1. Pour **Groupe de paramètres**, choisissez un groupe de paramètres ou créez-en un nouveau. Les groupes de paramètres contrôlent les paramètres d'exécution de votre cluster. Pour plus d'informations sur les groupes de paramètres, consultez [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis) et [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md).
**Note**
Lorsque vous sélectionnez un groupe de paramètres pour définir les valeurs de configuration du moteur, ce groupe de paramètres est appliqué à tous les clusters du magasin de données global. Dans la page **Parameter Groups (Groupes de paramètres)** l'attribut **Global** yes/no (oui/non) indique si un groupe de paramètres fait partie d'un magasin de données global.
1. Pour **Type de nœud**, choisissez la flèche vers le bas (![\[Downward-pointing triangle icon, typically used to indicate a dropdown menu.\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-DnArrow.png)). Dans la boîte de dialogue **Modifier le type de nœud** choisissez une valeur pour la **famille d'instances** pour le type de nœud souhaité. Choisissez ensuite le type de nœud que vous souhaitez utiliser pour ce cluster, puis choisissez **Enregistrer**.
Pour de plus amples informations, veuillez consulter [Choix de la taille de votre nœud](CacheNodes.SelectSize.md).
Si vous choisissez un type de nœud r6gd, la hiérarchisation des données est automatiquement activée. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
1. Si vous créez un cluster Valkey ou Redis OSS (mode cluster désactivé) :
Pour **Number of replicas** (Nombre de réplicas), choisissez le nombre de réplicas que vous voulez pour ce cluster.
1. Si vous créez un cluster Valkey ou Redis OSS (mode cluster activé) :
1. Pour **Nombre de partitions**, choisissez le nombre de partitions (partitions/groupes de nœuds) que vous souhaitez pour ce cluster Valkey ou Redis OSS (mode cluster activé).
Pour certaines versions de Valkey ou Redis OSS (mode cluster activé), vous pouvez modifier dynamiquement le nombre de partitions de votre cluster :
+ **Redis OSS 3.2.10 et versions ultérieures** : si votre cluster exécute Redis OSS 3.2.10 ou versions ultérieures, vous pouvez modifier le nombre de partitions de votre cluster de manière dynamique. Pour de plus amples informations, veuillez consulter [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md).
+ **Autres versions de Redis OSS** — Si votre cluster exécute une version de Redis OSS antérieure à la version 3.2.10, il existe une autre approche. Pour modifier le nombre de fragments dans votre cluster dans ce cas, créez un nouveau cluster avec le nouveau nombre de fragments. Pour de plus amples informations, veuillez consulter [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
1. Pour **Réplicas par partition**, choisissez le nombre de nœuds de réplica en lecture souhaité dans chaque partition.
Les restrictions suivantes existent pour Valkey ou Redis OSS (mode cluster activé).
+ Si Multi-AZ est activé, assurez-vous d'avoir au moins un réplica par partition.
+ Le nombre de réplicas est le même pour chaque partition lors de la création du cluster à l'aide de la console.
+ Le nombre de réplicas de lecture par partition est fixe et ne peut pas être modifié. Si vous avez besoin de davantage ou de moins de réplicas par partition (API/CLI : groupe de nœuds), vous devez créer un cluster avec le nouveau nombre de réplicas. Pour de plus amples informations, veuillez consulter [Tutoriel : Création d'un nouveau cluster basé sur des nœuds avec une sauvegarde créée en externe](backups-seeding-redis.md).
1. Pour les **paramètres du groupe de sous-réseaux**, choisissez le sous-réseau que vous souhaitez appliquer à ce cluster. ElastiCache fournit un groupe de IPv4 sous-réseaux par défaut ou vous pouvez choisir d'en créer un nouveau. En IPv6 effet, vous devez créer un groupe de sous-réseaux avec un bloc IPv6 CIDR. Si vous choisissez la **double pile**, vous devez sélectionner un type d'IP de découverte, IPv6 soit IPv4.
Pour plus d'informations, consultez [Création d'un sous-réseau dans votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet).
1. Pour **Availability zone placements** (Placement de zones de disponibilité), vous avez deux options :
+ **Aucune préférence** : ElastiCache choisit la zone de disponibilité.
+ **Specify availability zones (Spécifier les zones de disponibilité)** : vous spécifiez la zone de disponibilité pour chaque cluster.
Si vous avez choisi de spécifier les Zones de disponibilité, pour chaque cluster de chaque partition, choisissez la Zone de disponibilité depuis la liste.
Pour de plus amples informations, veuillez consulter [Choix des régions et des zones de disponibilité pour ElastiCache](RegionsAndAZs.md).
![\[Image : Définition des Keyspaces et des zones de disponibilité\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-ClusterOn-Slots-AZs.png)
*Définition des Keyspaces et des zones de disponibilité*
1. Choisissez **Next** (Suivant)
1. Dans les **paramètres avancés de Valkey et Redis OSS**
1. Pour **Security** (Sécurité) :
1. Pour le chiffrement de vos données, vous avez les options suivantes :
+ **Encryption at rest (Chiffrement au repos)** : active le chiffrement des données stockées sur le disque. Pour de plus amples informations, veuillez consulter [Chiffrement au repos](at-rest-encryption.md).
**Note**
Vous avez la possibilité de fournir une autre clé de chiffrement en choisissant la clé ** AWS KMS gérée par le client** et en choisissant la clé. Pour de plus amples informations, veuillez consulter [Utilisation clés AWS KMS gérées par le client](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ **Encryption in-transit (Chiffrement en transit)** : permet le chiffrement des données sur le câble. Pour de plus amples informations, veuillez consulter [Chiffrement en transit](in-transit-encryption.md). Pour Valkey 7.2 et versions ultérieures et Redis OSS 6.0 et versions ultérieures, si vous activez le chiffrement en transit, vous serez invité à spécifier l'une des options de contrôle d'**accès** suivantes :
+ **No Access Control (Aucun contrôle d'accès)** – il s'agit du paramètre par défaut. Cela indique qu'aucune restriction n'est imposée à l'accès des utilisateurs au cluster.
+ **User Group Access Control List (Liste de contrôle d'accès au groupe d'utilisateurs)** : choisissez un groupe d'utilisateurs avec un ensemble défini d'utilisateurs pouvant accéder au cluster. Pour de plus amples informations, veuillez consulter [Gestion des groupes d'utilisateurs avec la console et la CLI](Clusters.RBAC.md#User-Groups).
+ **Utilisateur par défaut AUTH** : mécanisme d'authentification pour un serveur Valkey ou Redis OSS. Pour plus d'informations, consultez [AUTH.](auth.md)
+ **AUTH** — Mécanisme d'authentification pour un serveur Valkey ou Redis OSS. Pour plus d'informations, consultez [AUTH.](auth.md)
**Note**
Pour les versions de Redis OSS supérieures à 3.2.6, à l'exception de la version 3.2.10, AUTH est la seule option.
1. Pour **Groupes de sécurité**, choisissez les groupes de sécurité que vous souhaitez utiliser pour ce cluster. Un *groupe de sécurité* agit comme un pare-feu pour contrôler l'accès réseau à votre cluster. Vous pouvez utiliser le groupe de sécurité par défaut pour votre VPC ou en créer un nouveau.
Pour plus d'informations sur les groupes de sécurité, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le *Guide de l'utilisateur Amazon VPC*.
1. Pour des sauvegardes automatiques régulières, choisissez **Activer les sauvegardes automatiques**, puis entrez le nombre de jours pendant lesquels vous souhaitez conserver une sauvegarde automatique avant sa suppression automatique. Si vous ne souhaitez pas de sauvegardes automatiques régulières, désactivez la case à cocher **Enable automatic backups**. Dans les deux cas, vous avez toujours la possibilité de créer des sauvegardes manuelles.
Pour plus d'informations sur la sauvegarde et la restauration, consultez[Instantané et restauration](backups.md).
1. (Facultatif) Spécifiez une fenêtre de maintenance. La *fenêtre de maintenance* indique le moment, généralement d'une durée d'une heure, chaque semaine, où ElastiCache planifie la maintenance du système pour votre cluster. Vous pouvez ElastiCache autoriser le choix du jour et de l'heure de votre fenêtre de maintenance (*aucune préférence*), ou vous pouvez choisir vous-même le jour, l'heure et la durée (*Spécifiez la fenêtre de maintenance*). Si vous choisissez *Specify maintenance window*, choisissez dans les listes les valeurs de *Start day*, *Start time* et *Duration* (en heures) pour le créneau de maintenance. Toutes les heures sont en UTC.
Pour de plus amples informations, veuillez consulter [Gestion de la maintenance des ElastiCache clusters](maintenance-window.md).
1. (Facultatif) Pour **Logs (Journaux)** :
+ Sous **Log format (Format de journal)**, sélectionnez **Text (Texte)** ou **JSON**.
+ Sous **Type de destination**, sélectionnez **CloudWatch Logs** ou **Kinesis Firehose**.
+ Sous **Destination du journal**, choisissez **Create new** et entrez le nom de votre groupe de CloudWatch journaux ou le nom de votre flux Firehose, ou choisissez **Select existing**, puis choisissez le nom de votre groupe de journaux de CloudWatch journaux ou le nom de votre stream Firehose,
1. Pour les **balises**, pour vous aider à gérer vos clusters et autres ElastiCache ressources, vous pouvez attribuer vos propres métadonnées à chaque ressource sous forme de balises. Pour plus d'informations, consultez [Marquer vos ressources ElastiCache](Tagging-Resources.md).
1. Passez en revue toutes vos entrées et sélections, puis effectuez les corrections nécessaires. Lorsque vous avez terminé, choisissez **Next** (Suivant).
1. Une fois que vous avez configuré le cluster dans les étapes précédentes, vous configurez maintenant les détails de votre cluster secondaire.
1. Sous **Cluster régional**, choisissez la AWS région où se trouve le cluster.
1. Sous **Cluster info** (Infos sur le cluster), saisissez un nom et une description facultative du cluster.
1. Les options suivantes sont prérenseignées pour correspondre à la configuration du cluster principal et ne peuvent pas être modifiés :
+ Emplacement
+ Version de moteur
+ Type d’instance
+ Type de nœud
+ Nombre de partitions
+ Groupe de paramètres
**Note**
ElastiCache génère automatiquement un nouveau groupe de paramètres à partir des valeurs du groupe de paramètres fourni et applique le nouveau groupe de paramètres au cluster. Utilisez ce nouveau groupe de paramètres pour modifier les paramètres d'un entrepôt de données global. Chaque groupe de paramètres généré automatiquement est associé à un seul cluster et, par conséquent, à un seul entrepôt de données global.
+ Encryption at rest (Chiffrement au repos) : active le chiffrement des données stockées sur le disque. Pour de plus amples informations, veuillez consulter [Chiffrement au repos](at-rest-encryption.md).
**Note**
Vous pouvez fournir une autre clé de chiffrement en choisissant la **clé AWS KMS gérée par le client** et en choisissant la clé. Pour plus d'informations, consultez la section [Utilisation de clés AWS KMS gérées par le client](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Chiffrement en transit : permet le chiffrement des données sur le câble. Pour de plus amples informations, veuillez consulter [Chiffrement en transit](in-transit-encryption.md). Pour Valkey 7.2 et versions ultérieures et Redis OSS 6.4 et versions ultérieures, si vous activez le chiffrement en transit, vous êtes invité à spécifier l'une des options de contrôle d'**accès** suivantes :
+ **No Access Control (Aucun contrôle d'accès)** – il s'agit du paramètre par défaut. Cela indique qu'aucune restriction n'est imposée à l'accès des utilisateurs au cluster.
+ **User Group Access Control List (Liste de contrôle d'accès au groupe d'utilisateurs)** : choisissez un groupe d'utilisateurs avec un ensemble défini d'utilisateurs pouvant accéder au cluster. Pour de plus amples informations, veuillez consulter [Gestion des groupes d'utilisateurs avec la console et la CLI](Clusters.RBAC.md#User-Groups).
+ **Utilisateur par défaut AUTH** : mécanisme d'authentification pour un serveur Valkey ou Redis OSS. Pour plus d'informations, consultez [AUTH.](auth.md)
**Note**
Pour les versions de Redis OSS comprises entre 4.0.2, lorsque le chiffrement en transit a été pris en charge pour la première fois, et 6.0.4, AUTH est la seule option.
Les autres paramètres de cluster secondaire sont prérenseignés avec les mêmes valeurs que celles du cluster principal, mais les éléments suivants peuvent être mis à jour pour répondre à aux exigences spécifiques de ce cluster :
+ Port
+ Nombre de réplicas
+ Groupe de sous-réseaux
+ Zone(s) de disponibilité préférée(s)
+ Groupes de sécurité
+ Géré par le client (cléAWS KMS)
+ Jeton AUTH
+ Activer les sauvegardes automatiques
+ Période de rétention des sauvegardes
+ Fenêtre de sauvegarde
+ Fenêtre de maintenance
+ Rubrique pour la notification SNS
1. Choisissez **Créer**. Cette opération définit l'état du magasin de données global sur **Creating (En cours de création)**. Une fois que le cluster principal et les clusters secondaires sont associés au magasin de données global, l'état passe à **Available (Disponible)**. Vous disposez d'un cluster principal qui accepte les lectures et les écritures, et d'un cluster secondaire qui accepte les lectures répliquées à partir du cluster principal.
La page est également mise à jour pour indiquer si un cluster fait partie d'une banque de données globale, notamment les éléments suivants :
+ **Global Datastore (Magasin de données global)** : nom de l'entrepôt de données global auquel appartient le cluster.
+ **Global Datastore Role (Rôle de l'entrepôt de données global)** : rôle du cluster, principal ou secondaire.
Vous pouvez ajouter jusqu'à un cluster secondaire supplémentaire dans une AWS région différente. Pour de plus amples informations, veuillez consulter [Ajout d'une région à un entrepôt de données global](#Redis-Global-Datastores-Console-Create-Secondary).
## Affichage des détails de l'entrepôt de données global
Vous pouvez consulter les détails des banques de données globales existantes et également les modifier sur la page Banques de **données globales**.
**Pour afficher les détails du magasin de données global**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Global Datastores**, puis choisissez une banque de données globale disponible.
Vous pouvez ensuite examiner les propriétés du magasin de données global suivantes :
+ **Global Datastore Name (Nom du magasin de données global) :** Nom du magasin de données global
+ **Description :** Description du magasin de données global
+ **Status (État) :** Les options comprennent :
+ Création
+ Modification
+ Disponible
+ Suppression
+ Primary Only (Principal uniquement) - Cet état indique que le magasin de données global ne contient qu'un cluster principal. Tous les clusters secondaires sont supprimés ou leur création a échoué.
+ **Cluster Mode (Mode cluster) :** Activé ou désactivé
+ **Version du moteur : version** du moteur Valkey ou Redis OSS exécutant la banque de données globale
+ **Instance Node Type (Type de nœud d'instance) :** Type de nœud utilisé pour le magasin de données global
+ **Encryption at-rest (Chiffrement au repos) :** Activé ou désactivé
+ **Encryption in-transit (Chiffrement en transit) :** Activé ou désactivé
+ **AUTH :** activé ou désactivé
Vous pouvez apporter les modifications suivantes au magasin de données global :
+ [Ajout d'une région à un entrepôt de données global](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Suppression d'une région d'un entrepôt de données global](#Redis-Global-Datastore-Console-Remove-Region)
+ [Promotion du cluster secondaire en cluster principal](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Modification d'un entrepôt de données global](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
La page Global Datastore (Magasin de données global) répertorie également les clusters individuels qui composent le magasin de données global et les propriétés suivantes pour chacun d'eux :
+ **Région** : AWS région dans laquelle le cluster est stocké
+ **Role (Rôle)** - Principal ou secondaire
+ **Cluster name (Nom du cluster)** - Nom du cluster
+ **Statut (État)** - Les options comprennent :
+ **Associating (En cours d'association)** - Le cluster est en cours d'association au magasin de données global
+ **Associated (Associé)** - Le cluster est associé au magasin de données global
+ **Disassociating (En cours de dissociation)** - Processus de suppression d'un cluster secondaire du magasin de données global à l'aide du nom de ce dernier. Ensuite, le cluster secondaire ne reçoit plus de mises à jour du cluster principal, mais il reste un cluster autonome dans cette AWS région.
+ **Disassociated (Dissocié)** - Le cluster secondaire a été supprimé de l'entrepôt de données global et est désormais un cluster autonome dans sa région AWS .
+ **Retard global de réplication de la banque** de données : affiche une valeur par AWS région secondaire dans la banque de données globale. Il s'agit du décalage entre le nœud primaire de la région secondaire et le nœud primaire de la région primaire. Pour Valkey ou Redis OSS activé en mode cluster, le décalage indique le délai maximal en secondes entre les partitions.
## Ajout d'une région à un entrepôt de données global
Vous pouvez ajouter jusqu'à une AWS région supplémentaire à une banque de données mondiale existante. Dans ce scénario, vous créez un cluster en lecture seule dans une AWS région distincte qui reçoit des mises à jour automatiques et asynchrones du cluster principal.
**Pour ajouter une AWS région à une banque de données globale**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Global Datastores**, puis sélectionnez une banque de données globale existante.
1. Choisissez **Ajouter un cluster régional**, puis choisissez la AWS région dans laquelle le cluster secondaire doit résider.
1. Sous **Informations sur le cluster**, entrez une valeur pour **le nom** et, éventuellement, pour la **description** du cluster.
1. Ne modifiez pas les options suivantes. Elles sont prérenseignées pour correspondre à la configuration du cluster principal. Vous ne pouvez pas les modifier.
+ Version de moteur
+ Type d’instance
+ Type de nœud
+ Nombre de partitions
+ Groupe de paramètres
**Note**
ElastiCache génère automatiquement un nouveau groupe de paramètres à partir des valeurs du groupe de paramètres fourni et applique le nouveau groupe de paramètres au cluster. Utilisez ce nouveau groupe de paramètres pour modifier les paramètres d'un entrepôt de données global. Chaque groupe de paramètres généré automatiquement est associé à un seul cluster et, par conséquent, à un seul entrepôt de données global.
+ Chiffrement au repos
**Note**
Vous pouvez fournir une autre clé de chiffrement en choisissant la **clé AWS KMS gérée par le client** et en choisissant la clé.
+ Chiffrement en transit
+ AUTH
1. (Facultatif) Mettez à jour les autres paramètres des clusters secondaires. Ils sont prérenseignés avec les mêmes valeurs que celles du cluster principal, mais vous pouvez les mettre à jour pour répondre à des exigences spécifiques pour ce cluster :
+ Port
+ Nombre de réplicas
+ Groupe de sous-réseaux
+ Zone(s) de disponibilité préférée(s)
+ Groupes de sécurité
+ AWS KMS géré par le client (clé)
+ Jeton AUTH
+ Activer les sauvegardes automatiques
+ Période de rétention des sauvegardes
+ Fenêtre de sauvegarde
+ Fenêtre de maintenance
+ Rubrique pour la notification SNS
1. Choisissez **Ajouter**.
## Modification d'un entrepôt de données global
Vous pouvez modifier les propriétés des clusters régionaux. Une seule opération de modification peut être en cours sur un magasin de données global, à l'exception de la promotion d'un cluster secondaire en cluster principal. Pour de plus amples informations, veuillez consulter [Promotion du cluster secondaire en cluster principal](#Redis-Global-Datastores-Console-Promote-Secondary).
**Pour modifier un magasin de données global**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Global Datastores**, puis pour **Global Datastore Name**, choisissez une banque de données globale.
1. Choisissez **Modify (Modifier)** et choisissez l'une des options suivantes :
+ **Modify description (Modifier la description)** : mettre à jour la description de l'entrepôt de données global
+ **Modifier la version du moteur** — Seuls Valkey 7.2 et versions ultérieures ou Redis OSS 5.0.6 et versions ultérieures sont disponibles.
+ **Modify node type (Modifier le type de nœud)** : mettre à l'échelle les clusters régionaux à la fois verticalement (augmentation et diminution du nombre de ressources) et horizontalement (redimensionnement à la hausse et à la baisse du nombre de noeuds). Les options incluent les familles de nœuds R5 et M5. Pour de plus amples informations sur les types de nœud, veuillez consulter [Types de nœuds pris en charge](CacheNodes.SupportedTypes.md).
+ **Modification du basculement automatique** : activez ou désactivez le basculement automatique. Lorsque vous activez le basculement et que les nœuds principaux des clusters régionaux s'arrêtent de manière inattendue, ils ElastiCache basculent vers l'une des répliques régionales. Pour de plus amples informations, veuillez consulter [Basculement automatique](AutoFailover.md).
Pour les clusters Valkey ou Redis OSS avec le mode cluster activé :
+ **Add shards (Ajouter des partitions)** : entrez le nombre de partitions à ajouter et spécifiez éventuellement une ou plusieurs zones de disponibilité.
+ **Supprimer les partitions** : choisissez les partitions à supprimer dans chaque AWS région.
+ **Rebalance shards (Rééquilibrer les partitions)** : rééquilibrez la distribution des emplacements pour assurer une distribution uniforme entre les partitions existantes dans le cluster.
Pour modifier les paramètres d'une banque de données globale, modifiez le groupe de paramètres de n'importe quel cluster membre de la banque de données globale. ElastiCache applique automatiquement cette modification à tous les clusters de cette banque de données globale. Pour modifier le groupe de paramètres de ce cluster, utilisez la console Valkey ou Redis OSS ou l'opération [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html)API. Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md). Lorsque vous modifiez le groupe de paramètres d'un cluster contenu dans un magasin de données global, la modification est appliquée à tous les clusters dans ce magasin de données global.
Pour réinitialiser un groupe de paramètres entier ou des paramètres spécifiques, utilisez l'opération [ResetCacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ResetCacheParameterGroup.html)API.
## Promotion du cluster secondaire en cluster principal
Si le cluster ou la AWS région principal devient indisponible ou rencontre des problèmes de performances, vous pouvez transformer un cluster secondaire en cluster principal. La promotion est autorisée à tout moment, même si d'autres modifications sont en cours. Vous pouvez également effectuer plusieurs promotions en parallèle. Au final, le magasin de données global contiendra un seul cluster principal. Si vous promouvez plusieurs clusters secondaires simultanément, ElastiCache cela ne garantit pas lequel sera finalement transformé en cluster principal.
**Pour promouvoir un cluster secondaire en cluster principal**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, sélectionnez **Global Datastores**.
1. Sélectionnez le nom de l'entrepôt de données global pour en afficher les détails.
1. Choisissez le cluster **Secondary (Secondaire)**.
1. Choisissez **Promote to primary (Promouvoir en cluster principal)**.
L'avertissement suivant vous invite à confirmer votre décision : ` Promoting a region to primary will make the cluster in this region as read/writable. Are you sure you want to promote the secondary cluster to primary?`
`The current primary cluster in primary region will become secondary and will stop accepting writes after this operation completes. Please ensure you update your application stack to direct traffic to the new primary region.`
1. Choisissez **Confirm (Confirmer)** si vous souhaitez continuer la promotion ou **Cancel (Annuler)** si vous ne le souhaitez pas.
Si vous choisissez de confirmer, votre magasin de données global passe à l'état **Modifying (En cours de modification) ** et n'est pas disponible tant que la promotion n'est pas terminée.
## Suppression d'une région d'un entrepôt de données global
Vous pouvez supprimer une AWS région d'une banque de données globale à l'aide de la procédure suivante.
**Pour supprimer une AWS région d'une banque de données globale**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, sélectionnez **Global Datastores**.
1. Sélectionnez un entrepôt de données global.
1. Choisissez la **région** que vous souhaitez supprimer.
1. Choisissez **Remove region (Supprimer la région)**.
**Note**
Cette option n'est disponible que pour les clusters secondaires.
L'avertissement suivant vous invite à confirmer votre décision : ` Removing the region will remove your only available cross region replica for the primary cluster. Your primary cluster will no longer be set up for disaster recovery and improved read latency in remote region. Are you sure you want to remove the selected region from the global datastore?`
1. Choisissez **Confirm (Confirmer)** si vous souhaitez continuer la promotion ou **Cancel (Annuler)** si vous ne le souhaitez pas.
Si vous choisissez Confirmer, la AWS région est supprimée et le cluster secondaire ne reçoit plus de mises à jour de réplication.
## Suppression d'un entrepôt de données global
Pour supprimer un magasin de données global, commencez par supprimer tous les clusters secondaires. Pour de plus amples informations, veuillez consulter [Suppression d'une région d'un entrepôt de données global](#Redis-Global-Datastore-Console-Remove-Region). L'état du magasin de données global reste alors **primary-only (principal seulement)**.
**Pour supprimer un magasin de données global**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, sélectionnez **Global Datastores**.
1. Sous **Global Datastore Name (Nom du magasin de données global)** de données globale, choisissez le magasin de données global à supprimer, puis choisissez **Delete (Supprimer)**.
L'avertissement suivant vous invite à confirmer votre décision : `Are you sure you want to delete this Global Datastore?`
1. Sélectionnez **Delete (Supprimer)**.
Le magasin de données global passe à l'état **Deleting (En cours de suppression)** .
# Utilisation des entrepôts de données globaux (CLI)
Vous pouvez utiliser le AWS Command Line Interface (AWS CLI) pour contrôler plusieurs AWS services à partir de la ligne de commande et les automatiser par le biais de scripts. Vous pouvez utiliser la AWS CLI pour des opérations ad hoc (ponctuelles).
## Téléchargement et configuration du AWS CLI
Il AWS CLI fonctionne sous Windows, macOS ou Linux. Suivez la procédure suivante pour la télécharger et la configurer.
**Pour télécharger, installer et configurer la CLI**
1. Téléchargez la AWS CLI sur la page Web de l'[interface de ligne de AWS commande](https://aws.amazon.com/cli).
1. Suivez les instructions d'installation de la AWS CLI et de configuration de la AWS CLI dans le *guide de AWS Command Line Interface l'utilisateur*.
## Utilisation de la AWS CLI avec des banques de données globales
Utilisez les opérations de la CLI suivantes pour utiliser les magasins de données globaux :
+ [create-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-global-replication-group.html)
```
aws elasticache create-global-replication-group \
--global-replication-group-id-suffix my global datastore \
--primary-replication-group-id sample-repl-group \
--global-replication-group-description an optional description of the global datastore
```
Amazon applique ElastiCache automatiquement un préfixe à l'identifiant global de la banque de données lors de sa création. Chaque AWS région possède son propre préfixe. Par exemple, un ID d'entrepôt de données global créé dans la région USA Ouest (Californie du Nord) commence par « virxk » avec le nom de suffixe que vous fournissez. Le suffixe, combiné au préfixe autogénéré, garantit l'unicité du nom de l'entrepôt de données global dans plusieurs régions.
Le tableau suivant répertorie chaque AWS région et son préfixe d'ID de banque de données global.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/Redis-Global-Datastores-CLI.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)— Utilisez cette opération pour créer des clusters secondaires pour une banque de données globale en fournissant le nom de la banque de données globale au `--global-replication-group-id` paramètre.
```
aws elasticache create-replication-group \
--replication-group-id secondary replication group name \
--replication-group-description “Replication group description" \
--global-replication-group-id global datastore name
```
Lorsque vous appelez cette opération et que vous `--global-replication-group-id` transmettez une valeur, les valeurs ElastiCache seront déduites du groupe de réplication principal du groupe de réplication global pour les paramètres suivants. Ne transmettez pas de valeurs pour ces paramètres :
`"PrimaryClusterId",`
`"AutomaticFailoverEnabled",`
` "NumNodeGroups",`
` "CacheParameterGroupName",`
` "CacheNodeType",`
` "Engine",`
` "EngineVersion",`
` "CacheSecurityGroupNames",`
` "EnableTransitEncryption",`
` "AtRestEncryptionEnabled",`
` "SnapshotArns",`
` "SnapshotName"`
+ [describe-global-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-global-replication-groups.html)
```
aws elasticache describe-global-replication-groups \
--global-replication-group-id my global datastore \
--show-member-info an optional parameter that returns a list of the primary and secondary clusters that make up the global datastore
```
+ [modify-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-global-replication-group.html)
```
aws elasticache modify-global-replication-group \
--global-replication-group-id my global datastore \
--automatic-failover-enabled \
--cache-node-type node type \
--cache-parameter-group-name parameter group name \
--engine-version engine version \
-—apply-immediately \
--global-replication-group-description description
```
**Mise à niveau multimoteur de Redis vers OSS Valkey pour ElastiCache GlobalDataStore**
Vous pouvez mettre à niveau un groupe de réplication global Redis OSS existant vers Valkey à l'aide de la console, de l'API ou de la CLI.
Si vous disposez d'un groupe de réplication global Redis OSS existant, vous pouvez passer à Valkey en spécifiant le nouveau moteur et la nouvelle version du moteur avec modify-global-replication-group l'API.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--apply-immediately \
--engine-version 8.0
```
Pour Windows :
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--apply-immediately ^
--engine-version 8.0
```
Si un groupe de paramètres de cache personnalisé est appliqué au groupe de réplication global Redis OSS existant que vous souhaitez mettre à niveau, vous devrez également transmettre un groupe de paramètres de cache Valkey personnalisé dans la demande. Le groupe de paramètres personnalisés Valkey en entrée doit avoir les mêmes valeurs de paramètres statiques Redis OSS que le groupe de paramètres personnalisés Redis OSS existant.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--engine-version 8.0 \
--apply-immediately \
--cache-parameter-group-name myParamGroup
```
Pour Windows :
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--apply-immediately ^
--cache-parameter-group-name myParamGroup
```
+ [delete-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-global-replication-group.html)
```
aws elasticache delete-global-replication-group \
--global-replication-group-id my global datastore \
--retain-primary-replication-group defaults to true
```
+ [disassociate-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/disassociate-global-replication-group.html)
```
aws elasticache disassociate-global-replication-group \
--global-replication-group-id my global datastore \
--replication-group-id my secondary cluster \
--replication-group-region the AWS Region in which the secondary cluster resides
```
+ [failover-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/failover-global-replication-group.html)
```
aws elasticache failover-replication-group \
--global-replication-group-id my global datastore \
--primary-region The AWS Region of the primary cluster \
--primary-replication-group-id The name of the global datastore, including the suffix.
```
+ [increase-node-groups-in-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-node-groups-in-global-replication-group.html)
```
aws elasticache increase-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
```
+ [decrease-node-groups-in-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-node-groups-in-global-replication-group.html)
```
aws elasticache decrease-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
```
+ [rebalance-shards-in-global-groupe de réplication](https://docs.aws.amazon.com/cli/latest/reference/elasticache/rebalance-slots-in-global-replication-group.html)
```
aws elasticache rebalance-shards-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name
```
Utilisez l'aide pour répertorier toutes les commandes disponibles ElastiCache pour Valkey ou Redis OSS.
```
aws elasticache help
```
Vous pouvez également utiliser l'aide pour décrire une commande spécifique et en savoir plus sur son utilisation :
```
aws elasticache create-global-replication-group help
```
# Haute disponibilité avec les groupes de réplication
Les clusters Amazon ElastiCache Valkey et Redis OSS à nœud unique sont des entités en mémoire dotées de services de protection des données (AOF) limités. Si votre cluster échoue pour une raison quelconque, vous perdez toutes les données du cluster. Toutefois, si vous utilisez un moteur Valkey ou Redis OSS, vous pouvez regrouper 2 à 6 nœuds dans un cluster avec des répliques où 1 à 5 nœuds en lecture seule contiennent les données de réplication du nœud principal unique du groupe. read/write Dans ce scénario, si un nœud échoue pour une raison quelconque, vous ne perdez pas toutes vos données puisque celles-ci sont répliquées sur un ou plusieurs nœuds. En raison de la latence de réplication, certaines données peuvent être perdues si c'est le read/write nœud principal qui tombe en panne.
Comme le montre le graphique suivant, la structure de réplication est contenue dans une partition (appelée *groupe de nœuds* dans l'API/CLI) contenue dans un cluster Valkey ou Redis OSS. Les clusters Valkey ou Redis OSS (mode cluster désactivé) ont toujours une partition. Les clusters Valkey ou Redis OSS (mode cluster activé) peuvent contenir jusqu'à 500 partitions, les données du cluster étant partitionnées entre les partitions. Vous pouvez créer un cluster contenant un nombre de partitions supérieur et un nombre de réplicas inférieur, qui conduisent à un nombre total de 90 nœuds par cluster. Cette configuration de cluster peut contenir de 90 partitions avec 0 réplica à 15 partitions avec 5 réplicas, ce qui correspond au nombre maximal de réplicas autorisé.
La limite de nœuds ou de partitions peut être augmentée jusqu'à un maximum de 500 par cluster avec ElastiCache Valkey, et avec la ElastiCache version 5.0.6 ou supérieure pour Redis OSS. Par exemple, vous pouvez choisir de configurer un cluster de 500 nœuds compris entre 83 (un principal et 5 réplicas par partition) et 500 partitions (un principal et aucun réplicas). Assurez-vous qu’il y ait suffisamment d’adresses IP disponibles pour faire face à l’augmentation. Les pièges courants incluent les sous-réseaux du groupe de sous-réseaux avec une plage CIDR trop petite ou les sous-réseaux partagés et fortement utilisés par d’autres clusters. Pour de plus amples informations, veuillez consulter [Création d'un groupe de sous-réseaux](SubnetGroups.Creating.md).
Pour les versions antérieures à 5.0.6, la limite est de 250 par cluster.
Pour demander une augmentation de cette limite, veuillez consulter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et sélectionnez le type de limite **Nœuds par cluster par type d'instance**.
![\[Image : le cluster Valkey ou Redis OSS (mode cluster désactivé) possède une partition et 0 à 5 nœuds de réplication\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Le cluster Valkey ou Redis OSS (mode cluster désactivé) possède une partition et 0 à 5 nœuds de réplication*
Si le mode Multi-AZ est activé pour le cluster avec réplicas et que le nœud principal échoue, le cluster bascule vers un réplica en lecture. Etant donné que les données sont mises à jour de façon asynchrone sur les nœuds de réplica, des données peuvent être perdues du fait de la latence des mises à jour des nœuds de réplication. Pour de plus amples informations, veuillez consulter [Atténuer les défaillances lors de l'exécution de Valkey ou Redis OSS](disaster-recovery-resiliency.md#FaultTolerance.Redis).
**Topics**
+ [Comprendre la réplication Valkey et Redis OSS](Replication.Redis.Groups.md)
+ [Réplication : mode cluster Valkey et Redis OSS désactivé ou activé](Replication.Redis-RedisCluster.md)
+ [Minimiser les temps d'arrêt en ElastiCache utilisant le multi-AZ avec Valkey et Redis OSS](AutoFailover.md)
+ [Implémentation de la sauvegarde et de la synchronisation](Replication.Redis.Versions.md)
+ [Création d'un groupe de réplication Valkey ou Redis OSS](Replication.CreatingRepGroup.md)
+ [Affichage des détails d'un groupe de réplication](Replication.ViewDetails.md)
+ [Recherche des points de terminaison du groupe de réplication](Replication.Endpoints.md)
+ [Modification d'un groupe de réplication](Replication.Modify.md)
+ [Suppression d'un groupe de réplication](Replication.DeletingRepGroup.md)
+ [Modification du nombre de réplicas](increase-decrease-replica-count.md)
+ [Promouvoir une réplique en lecture au statut principal, pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé)](Replication.PromoteReplica.md)
# Comprendre la réplication Valkey et Redis OSS
Redis OSS implémente la réplication de deux manières :
+ Avec une seule partition contenant toutes les données du cluster dans chaque nœud : Valkey ou Redis OSS (mode cluster désactivé)
+ Avec des données partitionnées sur un maximum de 500 partitions : Valkey ou Redis OSS (mode cluster activé)
Chaque partition d'un groupe de réplication possède un seul nœud read/write principal et jusqu'à 5 nœuds de réplication en lecture seule. Vous pouvez créer un cluster contenant un nombre de partitions supérieur et un nombre de réplicas inférieur, qui conduisent à un nombre total de 90 nœuds par cluster. Cette configuration de cluster peut contenir de 90 partitions avec 0 réplica à 15 partitions avec 5 réplicas, ce qui correspond au nombre maximal de réplicas autorisé.
La limite de nœuds ou de partitions peut être augmentée jusqu'à un maximum de 500 par cluster si la version du moteur Redis OSS est 5.0.6 ou supérieure. Par exemple, vous pouvez choisir de configurer un cluster de 500 nœuds compris entre 83 (un principal et 5 réplicas par partition) et 500 partitions (un principal et aucun réplicas). Assurez-vous qu’il y ait suffisamment d’adresses IP disponibles pour faire face à l’augmentation. Les pièges courants incluent les sous-réseaux du groupe de sous-réseaux avec une plage CIDR trop petite ou les sous-réseaux partagés et fortement utilisés par d’autres clusters. Pour de plus amples informations, veuillez consulter [Création d'un groupe de sous-réseaux](SubnetGroups.Creating.md).
Pour les versions antérieures à 5.0.6, la limite est de 250 par cluster.
Pour demander une augmentation de cette limite, veuillez consulter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et sélectionnez le type de limite **Nœuds par cluster par type d'instance**.
**Topics**
+ [Valkey ou Redis OSS (mode cluster désactivé)](#Replication.Redis.Groups.Classic)
+ [Valkey ou Redis OSS (mode cluster activé)](#Replication.Redis.Groups.Cluster)
## Valkey ou Redis OSS (mode cluster désactivé)
Un cluster Valkey ou Redis OSS (mode cluster désactivé) possède une seule partition, à l'intérieur de laquelle se trouve un ensemble de nœuds : un read/write nœud principal et jusqu'à cinq nœuds répliques secondaires en lecture seule. Chaque réplica en lecture conserve une copie des données du nœud principal du cluster. Des mécanismes de réplication asynchrones sont utilisés pour maintenir les réplicas en lecture synchronisés avec le nœud principal. Les applications peuvent lire à partir de n'importe quel nœud du cluster. Les applications ne peuvent écrire que sur le nœud principal. Les réplicas en lecture améliorent le débit de lecture et préviennent la perte de données en cas de défaillance d'un nœud.
![\[Image : cluster Valkey ou Redis OSS (mode cluster désactivé) avec une seule partition et des nœuds de réplication\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Cluster Valkey ou Redis OSS (mode cluster désactivé) avec une seule partition et des nœuds de réplication*
Vous pouvez utiliser des clusters Valkey ou Redis OSS (mode cluster désactivé) avec des nœuds de réplication pour adapter votre solution ElastiCache afin de gérer les applications gourmandes en lecture ou de prendre en charge un grand nombre de clients lisant simultanément à partir du même cluster.
Tous les nœuds d'un cluster Valkey ou Redis OSS (mode cluster désactivé) doivent résider dans la même région.
Lorsque vous ajoutez un réplica en lecture à un cluster, toutes les données du nœud principal sont copiées dans le nouveau nœud. A partir de ce moment, chaque fois que des données sont écrites sur le nœud principal, les changements sont propagés en mode asynchrone sur tous les réplicas en lecture.
Pour améliorer la tolérance aux pannes et réduire les temps d'arrêt d'écriture, activez le mode multi-AZ avec basculement automatique pour votre cluster Valkey ou Redis OSS (mode cluster désactivé) avec des répliques. Pour de plus amples informations, veuillez consulter [Minimiser les temps d'arrêt en ElastiCache utilisant le multi-AZ avec Valkey et Redis OSS](AutoFailover.md).
Vous pouvez modifier les rôles des nœuds au sein du cluster Valkey ou Redis OSS (mode cluster désactivé), le principal et l'une des répliques échangeant des rôles. Vous pouvez décider de le faire pour améliorer des performances. Par exemple, avec une application Web qui a une activité d'écriture intensive, vous pouvez choisir le nœud avec la plus basse latence réseau. Pour de plus amples informations, veuillez consulter [Promouvoir une réplique en lecture au statut principal, pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé)](Replication.PromoteReplica.md).
## Valkey ou Redis OSS (mode cluster activé)
Un cluster Valkey ou Redis OSS (mode cluster activé) est composé de 1 à 500 partitions (API/CLI : groupes de nœuds). Chaque partition dispose d'un nœud primaire et jusqu'à 5 nœuds de réplica en lecture seule. La configuration peut contenir de 90 partitions avec 0 réplica à 15 partitions avec 5 réplicas, ce qui correspond au nombre maximal de réplicas autorisé.
La limite de nœuds ou de partitions peut être augmentée jusqu'à un maximum de 500 par cluster si la version du moteur est Valkey 7.2 ou supérieure, ou Redis OSS 5.0.6 ou version ultérieure. Par exemple, vous pouvez choisir de configurer un cluster de 500 nœuds compris entre 83 (un principal et 5 réplicas par partition) et 500 partitions (un principal et aucun réplicas). Assurez-vous qu’il y ait suffisamment d’adresses IP disponibles pour faire face à l’augmentation. Les pièges courants incluent les sous-réseaux du groupe de sous-réseaux avec une plage CIDR trop petite ou les sous-réseaux partagés et fortement utilisés par d’autres clusters. Pour de plus amples informations, veuillez consulter [Création d'un groupe de sous-réseaux](SubnetGroups.Creating.md).
Pour les versions antérieures à 5.0.6, la limite est de 250 par cluster.
Pour demander une augmentation de cette limite, veuillez consulter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et sélectionnez le type de limite **Nœuds par cluster par type d'instance**.
Chaque réplica en lecture d'une partition conserve une copie des données du nœud principal de la partition. Des mécanismes de réplication asynchrones sont utilisés pour maintenir les réplicas en lecture synchronisés avec le nœud principal. Les applications peuvent lire à partir de n'importe quel nœud du cluster. Les applications ne peuvent écrire que sur les nœuds principaux. Les réplicas en lecture améliorent l'évolutivité de la lecture et empêchent la perte de données. Les données sont partitionnées entre les partitions d'un cluster Valkey ou Redis OSS (mode cluster activé).
Les applications utilisent le point de *terminaison de configuration* du cluster Valkey ou Redis OSS (mode cluster activé) pour se connecter aux nœuds du cluster. Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md).
![\[Image : cluster Valkey ou Redis OSS (mode cluster activé) avec plusieurs partitions et nœuds de réplication\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-RedisClusters.png)
*Cluster Valkey ou Redis OSS (mode cluster activé) avec plusieurs partitions et nœuds de réplication*
Tous les nœuds d'un cluster Valkey ou Redis OSS (mode cluster activé) doivent résider dans la même région. Pour améliorer la tolérance aux pannes, vous pouvez mettre en service les réplicas principaux et en lecture dans plusieurs zones de disponibilité au sein de cette région.
Actuellement, les fonctionnalités de Valkey ou Redis OSS (mode cluster activé) présentent certaines limites.
+ Vous ne pouvez promouvoir manuellement aucun des nœuds de réplica en tant que nœud principal.
# Réplication : mode cluster Valkey et Redis OSS désactivé ou activé
À partir de Valkey 7.2 et de Redis OSS version 3.2, vous avez la possibilité de créer l'un des deux types distincts de clusters (API/CLI: replication groups). A Valkey or Redis OSS (cluster mode disabled) cluster always has a single shard (API/CLIgroupe de nœuds) avec jusqu'à 5 nœuds de réplication en lecture. Un cluster Valkey ou Redis OSS (mode cluster activé) comporte jusqu'à 500 partitions contenant chacune 1 à 5 nœuds de réplication en lecture.
![\[Image : clusters Valkey ou Redis OSS (mode cluster désactivé) et clusters Valkey ou Redis OSS (mode cluster activé)\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-NodeGroups.png)
*Clusters Valkey ou Redis OSS (mode cluster désactivé) et clusters Valkey ou Redis OSS (mode cluster activé)*
Le tableau suivant résume les différences importantes entre les clusters Valkey ou Redis OSS (mode cluster désactivé) et les clusters Valkey ou Redis OSS (mode cluster activé).
**Comparaison de clusters Valkey ou Redis OSS (mode cluster désactivé) et Valkey ou Redis OSS (mode cluster activé)**
| Fonctionnalité | Valkey ou Redis OSS (mode cluster désactivé) | Valkey ou Redis OSS (mode cluster activé) |
| --- | --- | --- |
| Adaptabilité | Oui. Prend en charge l'ajout et la suppression des nœuds de réplica et la mise à l'échelle du type de nœud. | Limité. Pour plus d’informations, consultez [Gestion des versions pour ElastiCache](VersionManagement.md) et [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md). |
| Partitionnement de données | Non | Oui |
| Partitions | 1 | 1 à 500 |
| Réplicas en lecture | 0 à 5 Si vous n'avez aucun réplica et que le nœud échoue, vous risquez de perdre toutes les données. | 0 sur 5 par partition. Si vous n'avez aucun réplica et qu'un nœud échoue, vous risquez de perdre toutes les données de cette partition. |
| Multi-AZ | Oui, avec au moins 1 réplica. Facultatif. Activé par défaut. | OuiFacultatif. Activé par défaut. |
| Instantanés (Sauvegardes) | Oui, création d'un fichier .rdb unique. | Oui, création d'un fichier .rdb unique pour chaque partition. |
| Restaurer | Oui, en utilisant un seul fichier .rdb provenant d'un cluster Valkey ou Redis OSS (mode cluster désactivé). | Oui, en utilisant des fichiers .rdb provenant d'un Valkey ou Redis OSS (mode cluster désactivé) ou d'un cluster Valkey ou Redis OSS (mode cluster activé). |
| Pris en charge par | Toutes les versions de Valkey et Redis OSS | Toutes les versions de Valkey, ainsi que Redis OSS 3.2 et versions ultérieures |
| Moteur évolutif | Oui, avec certaines limites. Pour de plus amples informations, veuillez consulter [Gestion des versions pour ElastiCache](VersionManagement.md). | Oui, avec certaines limites. Pour de plus amples informations, veuillez consulter [Gestion des versions pour ElastiCache](VersionManagement.md). |
| Chiffrement | Versions 3.2.6 (dont la fin de vie est prévue, voir le [calendrier de fin de vie des versions Redis OSS) et 4.0.10](engine-versions.md#deprecated-engine-versions) et versions ultérieures. | Versions 3.2.6 (dont la fin de vie est prévue, voir le [calendrier de fin de vie des versions Redis OSS) et 4.0.10](engine-versions.md#deprecated-engine-versions) et versions ultérieures. |
| Éligible HIPAA | Versions 3.2.6 (dont la fin de vie est prévue, voir le [calendrier de fin de vie des versions Redis OSS) et 4.0.10](engine-versions.md#deprecated-engine-versions) et versions ultérieures. | Versions 3.2.6 (dont la fin de vie est prévue, voir le [calendrier de fin de vie des versions Redis OSS) et 4.0.10](engine-versions.md#deprecated-engine-versions) et versions ultérieures. |
| Conforme à PCI DSS | Versions 3.2.6 (dont la fin de vie est prévue, voir le [calendrier de fin de vie des versions Redis OSS) et 4.0.10](engine-versions.md#deprecated-engine-versions) et versions ultérieures. | Versions 3.2.6 (dont la fin de vie est prévue, voir le [calendrier de fin de vie des versions Redis OSS) et 4.0.10](engine-versions.md#deprecated-engine-versions) et versions ultérieures. |
| Repartitionnement en ligne | N/A | Version 3.2.10 (prévue pour EOL, voir le [calendrier de fin de vie des versions Redis OSS](engine-versions.md#deprecated-engine-versions)) et versions ultérieures. |
## Lequel choisir ?
Lorsque vous choisissez entre Valkey ou Redis OSS (mode cluster désactivé) ou Valkey ou Redis OSS (mode cluster activé), tenez compte des facteurs suivants :
+ **Mise à l'échelle ou partitionnement** – Les besoins métier évoluent. Vous devez soit allouer les ressources pour les fortes demandes ou mettre à l'échelle vos ressources en fonction des demandes. Valkey ou Redis OSS (mode cluster désactivé) prend en charge le dimensionnement. Vous pouvez mettre à l'échelle la capacité de lecture en ajoutant ou en supprimant des nœuds de réplica, ou vous pouvez mettre à l'échelle la capacité en optant pour un type de nœud de plus grande capacité. Ces deux opérations prennent du temps. Pour plus d'informations, consultez [Dimensionnement des nœuds de réplication pour Valkey ou Redis OSS (mode cluster désactivé)](Scaling.RedisReplGrps.md).
Valkey ou Redis OSS (mode cluster activé) prend en charge le partitionnement de vos données sur un maximum de 500 groupes de nœuds. Vous pouvez modifier dynamiquement le nombre de partitions au fur et à mesure que les besoins de votre entreprise évoluent. Le partitionnement présente notamment l'avantage de pouvoir répartir votre charge sur un plus grand nombre de points de terminaison, ce qui réduit les goulots d'étranglement lorsque la demande est la plus élevée. En outre, vous pouvez gérer un plus grand nombre de données dans la mesure où elles peuvent être réparties sur plusieurs serveurs. Pour plus d'informations sur la mise à l'échelle de vos partitions, consultez[Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md).
+ **Taille du nœud par rapport au nombre de nœuds** : étant donné qu'un cluster Valkey ou Redis OSS (mode cluster désactivé) ne possède qu'une seule partition, le type de nœud doit être suffisamment grand pour accueillir toutes les données du cluster ainsi que la surcharge nécessaire. D'autre part, étant donné que vous pouvez partitionner vos données sur plusieurs partitions lorsque vous utilisez un cluster Valkey ou Redis OSS (mode cluster activé), les types de nœuds peuvent être plus petits, mais vous en avez besoin d'un plus grand nombre. Pour de plus amples informations, veuillez consulter [Choix de la taille de votre nœud](CacheNodes.SelectSize.md).
+ **Lectures et écritures** : si la charge principale de votre cluster est constituée d'applications lisant des données, vous pouvez redimensionner un cluster Valkey ou Redis OSS (mode cluster désactivé) en ajoutant et en supprimant des répliques de lecture. Néanmoins, notez qu'il y a un maximum de 5 réplicas en lecture. Si la charge de votre cluster est importante en écriture, vous pouvez bénéficier des points de terminaison d'écriture supplémentaires d'un cluster Valkey ou Redis OSS (mode cluster activé) avec plusieurs partitions.
Quel que soit le type de cluster que vous choisissez d'implémenter, assurez-vous de choisir un type de nœud qui convient à vos besoins actuels et futurs.
# Minimiser les temps d'arrêt en ElastiCache utilisant le multi-AZ avec Valkey et Redis OSS
Dans un certain nombre de cas ElastiCache , Valkey et Redis OSS peuvent avoir besoin de remplacer un nœud principal ; il s'agit notamment de certains types de maintenance planifiée et de l'éventualité peu probable d'une défaillance d'un nœud principal ou d'une zone de disponibilité.
Ce remplacement entraîne un certain temps d'arrêt pour le cluster, mais si Multi-AZ est activé, le temps d'arrêt est réduit. Le rôle du nœud primaire bascule automatiquement sur l'un des réplicas en lecture. Il n'est pas nécessaire de créer et de provisionner un nouveau nœud principal, car il ElastiCache gérera cela de manière transparente. Ce basculement et la promotion d'un réplica vous permettent de recommencer à écrire dans le nouveau nœud principal dès que la promotion est terminée.
ElastiCache propage également le nom DNS (Domain Name Service) de la réplique promue. De cette façon, si votre application écrit dans le point de terminaison principal, aucun changement du point de terminaison ne sera nécessaire dans le cadre de votre application. Si vous lisez à partir de points de terminaison individuels, veillez à modifier le point de terminaison de lecture du réplica promu en principal en point de terminaison du nouveau réplica.
Dans le cas de remplacements de nœuds planifiés, initiés en raison de mises à jour de maintenance ou de mises à jour en libre service, soyez conscient des points suivants :
+ Pour les clusters Valkey et Redis OSS, les remplacements de nœuds prévus sont terminés pendant que le cluster traite les demandes d'écriture entrantes.
+ Pour les clusters désactivés en mode cluster Valkey et Redis OSS avec le mode multi-AZ activé qui s'exécutent sur le moteur 5.0.6 ou version ultérieure, les remplacements de nœuds prévus sont terminés pendant que le cluster traite les demandes d'écriture entrantes.
+ Pour les clusters désactivés en mode cluster Valkey et Redis OSS avec le mode multi-AZ activé qui s'exécutent sur le moteur 4.0.10 ou une version antérieure, vous remarquerez peut-être une brève interruption d'écriture associée aux mises à jour DNS. Cette interruption peut prendre jusqu'à quelques secondes. Ce processus est nettement plus rapide que celui qui consiste à recréer et mettre en service un nouveau nœud primaire, processus appliqué si vous n'activez pas le mode Multi-AZ.
Vous pouvez activer le Multi-AZ à l'aide de la console de ElastiCache gestion AWS CLI, de ou de l' ElastiCache API.
L'activation de ElastiCache Multi-AZ sur votre cluster Valkey ou Redis OSS (dans l'API et la CLI, groupe de réplication) améliore votre tolérance aux pannes. Cela est particulièrement vrai dans les cas où le cluster read/write principal de votre cluster devient inaccessible ou tombe en panne pour une raison quelconque. Le multi-AZ n'est pris en charge que sur les clusters Valkey et Redis OSS comportant plus d'un nœud par partition.
**Topics**
+ [Activation du multi-AZ](#AutoFailover.Enable)
+ [Scénarios de défaillance avec réponses multi-AZ](#AutoFailover.Scenarios)
+ [Test du basculement automatique](#auto-failover-test)
+ [Limitations relatives à la technologie Multi-AZ](#AutoFailover.Limitations)
## Activation du multi-AZ
Vous pouvez activer le mode multi-AZ lorsque vous créez ou modifiez un cluster (API ou CLI, groupe de réplication) à l'aide de la ElastiCache console ou de l' ElastiCacheAPI. AWS CLI
Vous pouvez activer le mode multi-AZ uniquement sur les clusters Valkey ou Redis OSS (mode cluster désactivé) disposant d'au moins une réplique en lecture disponible. Les clusters sans réplica en lecture n'offrent pas une haute disponibilité ni la tolérance aux pannes. Pour plus d'informations sur la création d'un cluster avec réplication, consultez [Création d'un groupe de réplication Valkey ou Redis OSS](Replication.CreatingRepGroup.md). Pour plus d'informations sur l'ajout d'un réplica à un cluster avec réplication, consultez [Ajouter une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé)](Replication.AddReadReplica.md).
**Topics**
+ [Activation du multi-AZ (console)](#AutoFailover.Enable.Console)
+ [Activation de Multi-AZ (AWS CLI)](#AutoFailover.Enable.CLI)
+ [Activation du Multi-AZ (ElastiCache API)](#AutoFailover.Enable.API)
### Activation du multi-AZ (console)
Vous pouvez activer le Multi-AZ à l'aide de la ElastiCache console lorsque vous créez un nouveau cluster Valkey ou Redis OSS ou en modifiant un cluster existant par réplication.
Le multi-AZ est activé par défaut sur les clusters Valkey ou Redis OSS (mode cluster activé).
**Important**
ElastiCache activera automatiquement le mode multi-AZ uniquement si le cluster contient au moins une réplique dans une zone de disponibilité différente de la principale dans toutes les partitions.
#### Activation du mode multi-AZ lors de la création d'un cluster à l'aide de la console ElastiCache
Pour plus d'informations sur ce processus, consultez [Création d'un cluster Valkey (mode cluster désactivé) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs). Assurez-vous d'avoir un ou plusieurs réplicas et activez Multi-AZ.
#### Activation du multi-AZ sur un cluster existant (console)
Pour plus d'informations sur ce processus, consultez Modification d'un cluster [À l'aide du ElastiCache AWS Management Console](Clusters.Modify.md#Clusters.Modify.CON).
### Activation de Multi-AZ (AWS CLI)
L'exemple de code suivant utilise le AWS CLI pour activer le mode multi-AZ pour le groupe `redis12` de réplication.
**Important**
Le groupe de réplication `redis12` doit déjà exister et avoir au moins un réplica en lecture disponible.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id redis12 \
--automatic-failover-enabled \
--multi-az-enabled \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id redis12 ^
--automatic-failover-enabled ^
--multi-az-enabled ^
--apply-immediately
```
Le résultat JSON de cette commande devrait ressembler à cet exemple.
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "One shard, two nodes",
"NodeGroups": [
{
"Status": "modifying",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "redis12",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabling",
"MultiAZ": "enabled",
"SnapshotWindow": "07:00-08:00",
"SnapshottingClusterId": "redis12-002",
"MemberClusters": [
"redis12-001",
"redis12-002"
],
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations, consultez ces rubriques dans la *Référence des commandes de l'AWS CLI * :
+ [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
+ [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)dans la *référence de AWS CLI commande.*
### Activation du Multi-AZ (ElastiCache API)
L'exemple de code suivant utilise l' ElastiCache API pour activer le mode multi-AZ pour le groupe `redis12` de réplication.
**Note**
Pour que vous puissiez utiliser cet exemple, le groupe de réplication `redis12` doit déjà exister et avoir au moins un réplica en lecture disponible.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&AutoFailover=true
&MultiAZEnabled=true
&ReplicationGroupId=redis12
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez ces rubriques dans la *référence de l'API ElastiCache * :
+ [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html)
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
## Scénarios de défaillance avec réponses multi-AZ
Avant l'introduction du Multi-AZ, les nœuds défaillants d'un cluster étaient ElastiCache détectés et remplacés en recréant et en reprovisionnant le nœud défaillant. Si vous activez Multi-AZ, un cluster principal défaillant bascule vers le réplica ayant le moindre décalage de réplication. Le réplica sélectionné est automatiquement promu au rang de principal, ce qui est beaucoup plus rapide que de créer et de remettre en service un nouveau nœud principal. Ce processus dure généralement quelques secondes pendant lesquelles vous ne pouvez pas écrire sur le cluster.
Lorsque le mode Multi-AZ est activé, il surveille ElastiCache en permanence l'état du nœud principal. En cas de défaillance du nœud principal, l'une des actions suivantes est effectuée selon le type de la défaillance.
**Topics**
+ [Scénarios d'échec lorsque seul le nœud primaire échoue](#AutoFailover.Scenarios.PrimaryOnly)
+ [Scénarios de défaillance en cas de défaillance du nœud primaire et de certains réplicas en lecture](#AutoFailover.Scenarios.PrimaryAndReplicas)
+ [Scénarios d'échec lorsque l'ensemble du cluster tombe en panne](#AutoFailover.Scenarios.AllFail)
### Scénarios d'échec lorsque seul le nœud primaire échoue
Si seul le nœud principal échoue, le réplica en lecture ayant le moindre décalage de réplication est promu au rang de principal. Un réplica en lecture de remplacement est ensuite créé et provisionné dans la même zone de disponibilité que le principal défaillant.
Lorsque seul le nœud principal tombe en panne, ElastiCache Multi-AZ effectue les opérations suivantes :
1. Le nœud principal défaillant est mis hors ligne.
1. Le réplica en lecture ayant le moindre décalage de réplication est promu au rang de principal.
Les écritures peuvent reprendre dès que le processus de promotion est terminé, généralement au bout de quelques secondes. Si votre application écrit sur le point de terminaison principal, il n'est pas nécessaire de changer le point de terminaison pour les écritures et les lectures dans la mesure où ElastiCache diffuse le nom DNS du réplica promu.
1. Un réplica en lecture de remplacement est lancé et mis en service.
Le réplica en lecture de remplacement est lancé dans la zone de disponibilité où se trouvait le nœud principal défaillant afin que la distribution de nœuds soit maintenue.
1. La synchronisation des autres réplicas avec le nouveau nœud principal se produit.
Lorsque le nouveau réplica est disponible, vous devez être conscient des effets suivants :
+ **Point de terminaison principal** : vous n'avez besoin d'effectuer aucune modification sur votre application, dans la mesure où le nom DNS du nouveau nœud primaire est propagé au point de terminaison principal.
+ **Point de terminaison de lecture** : le point de terminaison du lecteur est automatiquement mis à jour de manière à pointer vers les nouveaux nœuds de réplica.
Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes :
+ [Trouver les points de terminaison d'un cluster Valkey ou Redis OSS (mode cluster désactivé) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Recherche des points de terminaison pour les groupes de réplication Valkey ou Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Recherche de points de terminaison pour les groupes de réplication (API) Valkey ou Redis OSS ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Scénarios de défaillance en cas de défaillance du nœud primaire et de certains réplicas en lecture
Lorsque le nœud principal et au moins un réplica en lecture sont défaillants, le réplica disponible avec le moindre décalage de réplication est promu cluster principal. De nouveaux réplicas en lecture sont également créés et mis en service dans les mêmes zones de disponibilité que les nœuds défaillants et le réplica promu cluster principal.
Lorsque le nœud principal et certaines répliques de lecture échouent, ElastiCache Multi-AZ effectue les opérations suivantes :
1. Le nœud principal et les réplicas en lecture ayant échoué sont mis hors ligne.
1. Le réplica en lecture disponible ayant le moindre décalage de réplication est promu au rang de nœud principal.
Les écritures peuvent reprendre dès que le processus de promotion est terminé, généralement au bout de quelques secondes. Si votre application écrit sur le point de terminaison principal, il n'est pas nécessaire de modifier le point de terminaison pour les écritures. ElastiCache propage le nom DNS de la réplique promue.
1. Des réplicas de remplacement sont créés et provisionnés.
Les réplicas de remplacement sont créés dans les zones de disponibilité des nœuds ayant échoué afin que la distribution des nœuds soit maintenue.
1. Tous les clusters sont synchronisés avec le nouveau nœud principal.
Vous devez apporter les modifications suivantes à votre application, une fois que les nouveaux nœuds sont disponibles :
+ **Point de terminaison principal** : n'apportez aucune modification à votre application. Le nom DNS du nouveau nœud principal est propagé au point de terminaison principal.
+ **Point de terminaison de lecture** : le point de terminaison de lecture est automatiquement mis à jour de manière à pointer vers les nouveaux nœuds de réplica.
Pour plus d'informations sur la recherche des points de terminaison d'un groupe de réplication, consultez les rubriques suivantes :
+ [Trouver les points de terminaison d'un cluster Valkey ou Redis OSS (mode cluster désactivé) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Recherche des points de terminaison pour les groupes de réplication Valkey ou Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Recherche de points de terminaison pour les groupes de réplication (API) Valkey ou Redis OSS ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Scénarios d'échec lorsque l'ensemble du cluster tombe en panne
En cas de défaillance générale, tous les nœuds sont recréés et mis en service dans les mêmes zones de disponibilité que les nœuds initiaux.
Dans ce scénario, toutes les données du cluster sont perdues en raison de la défaillance au niveau de chaque nœud du cluster. Cela se produit rarement.
Lorsque l'ensemble du cluster échoue, ElastiCache Multi-AZ effectue les opérations suivantes :
1. Le nœud principal et les réplicas en lecture ayant échoué sont mis hors ligne.
1. Un nœud principal de remplacement est créé et mis en service.
1. Des réplicas de remplacement sont créés et provisionnés.
Les remplacements sont créés dans les zones de disponibilité des nœuds ayant échoué afin que la distribution des nœuds soit maintenue.
Etant donné que la totalité du cluster a échoué, les données sont perdues et tous les nouveaux nœuds démarrent à vide.
Comme chacun des nœuds de remplacement a le même point de terminaison que le nœud qu'il remplace, il n'est pas nécessaire de modifier le point de terminaison de votre application.
Pour plus d'informations sur la recherche des points de terminaison d'un groupe de réplication, consultez les rubriques suivantes :
+ [Trouver les points de terminaison d'un cluster Valkey ou Redis OSS (mode cluster désactivé) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Recherche des points de terminaison pour les groupes de réplication Valkey ou Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Recherche de points de terminaison pour les groupes de réplication (API) Valkey ou Redis OSS ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
Nous vous recommandons de créer le nœud principal et les réplicas dans différentes zones de disponibilité pour augmenter votre niveau de tolérance aux pannes.
## Test du basculement automatique
Après avoir activé le basculement automatique, vous pouvez le tester à l'aide de la ElastiCache console AWS CLI, du et de l' ElastiCache API.
Lors du test, tenez compte des points suivants :
+ Vous pouvez utiliser cette opération pour tester le basculement automatique sur un maximum de 15 partitions (appelées groupes de nœuds dans l' ElastiCache API et AWS CLI) sur une période continue de 24 heures.
+ Si vous appelez cette opération sur des partitions de différents clusters (nommés groupes de réplication dans l'API et la CLI), vous pouvez effectuer des appels simultanément.
+ Dans certains cas, vous pouvez effectuer cette opération plusieurs fois sur différents fragments du même groupe de réplication Valkey ou Redis OSS (mode cluster activé). Dans de tels cas, le premier remplacement de nœud doit se terminer avant qu'un appel ultérieur puisse être effectué.
+ Pour déterminer si le remplacement du nœud est terminé, vérifiez les événements à l'aide de la ElastiCache console Amazon, de l' AWS CLI API ou de l' ElastiCache API. Recherchez les événements suivants liés au basculement automatique, répertoriés ici dans leur ordre d'occurrence probable :
1. Message du groupe de réplication : `Test Failover API called for node group `
1. Message du cluster de cache : `Failover from primary node to replica node completed`
1. Message du groupe de réplication : `Failover from primary node to replica node completed`
1. Message du cluster de cache : `Recovering cache nodes `
1. Message du cluster de cache : `Finished recovery for cache nodes `
Pour plus d’informations, consultez les ressources suivantes :
+ [Affichage des ElastiCache événements](ECEvents.Viewing.md) dans le *guide de l'utilisateur ElastiCache *
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) dans la *Référence d'API ElastiCache *
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) dans la *Référence des commandes de l'AWS CLI *.
+ Cette API est conçue pour tester le comportement de votre application en cas de ElastiCache basculement. Elle n’a pas été conçue pour être un outil opérationnel permettant de lancer un basculement pour résoudre un problème avec le cluster. De plus, dans certaines conditions, telles que des événements opérationnels à grande échelle, cette API AWS peut être bloquée.
**Topics**
+ [Test du basculement automatique à l'aide du AWS Management Console](#auto-failover-test-con)
+ [Test du basculement automatique à l'aide du AWS CLI](#auto-failover-test-cli)
+ [Test du basculement automatique à l'aide de l'API ElastiCache](#auto-failover-test-api)
### Test du basculement automatique à l'aide du AWS Management Console
Utilisez la procédure suivante pour tester le basculement automatique avec la console.
**Pour tester le basculement automatique**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**.
1. Dans la liste des clusters, cochez la case située à gauche du cluster que vous souhaitez tester. Ce cluster doit avoir au moins un nœud de réplica en lecture.
1. Dans la zone **Détails** vérifiez que la fonctionnalité Multi-AZ est activée pour ce cluster. Si tel n'est pas le cas, choisissez un autre cluster ou modifiez-le afin d'activer Multi-AZ. Pour de plus amples informations, veuillez consulter [À l'aide du ElastiCache AWS Management Console](Clusters.Modify.md#Clusters.Modify.CON).
![\[Image : zone de détails d'un cluster compatible multi-AZ\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-AutoFailover-MultiAZ-Enabled.png)
1. Pour Valkey ou Redis OSS (mode cluster désactivé), choisissez le nom du cluster.
Pour Valkey ou Redis OSS (mode cluster activé), procédez comme suit :
1. Choisissez le nom du cluster.
1. Sur la page **Partitions**, pour la partition (nommée groupe de nœuds dans l'API ou la CLI) sur laquelle vous souhaitez tester le basculement, choisissez le nom de la partition.
1. Sur la page Nœuds, choisissez **Failover Primary**.
1. Choisissez **Continuer** pour basculer le nœud principal, ou sur **Annuler** pour annuler l'opération et ne pas basculer le nœud principal.
Au cours du processus de basculement, la console continue à afficher le statut *available* du nœud. Pour suivre l'avancement du test de basculement, choisissez**Événements** dans le volet de navigation de la console. Sous l'onglet **Événements**, recherchez les événements indiquant que le basculement a commencé (`Test Failover API called`) et est terminé (`Recovery completed`).
### Test du basculement automatique à l'aide du AWS CLI
Vous pouvez tester le basculement automatique sur n'importe quel cluster compatible Multi-AZ à l' AWS CLI aide de cette opération. `test-failover`
**Paramètres**
+ `--replication-group-id` : obligatoire. Groupe de réplication (sur la console, cluster) qui va être testé.
+ `--node-group-id` : obligatoire. Nom du groupe de nœuds sur lequel vous souhaitez tester le basculement automatique. Vous pouvez tester un maximum de 15 groupes de nœuds sur une période continue de 24 heures.
L'exemple suivant utilise le AWS CLI pour tester le basculement automatique sur le groupe `redis00-0003` de nœuds du cluster Valkey ou Redis OSS (mode cluster activé). `redis00`
**Example Test du basculement automatique**
Pour Linux, macOS ou Unix :
```
aws elasticache test-failover \
--replication-group-id redis00 \
--node-group-id redis00-0003
```
Pour Windows :
```
aws elasticache test-failover ^
--replication-group-id redis00 ^
--node-group-id redis00-0003
```
Le résultat de la commande précédente doit ressembler à ce qui suit.
```
{
"ReplicationGroup": {
"Status": "available",
"Description": "1 shard, 3 nodes (1 + 2 replicas)",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ClusterEnabled": false,
"ReplicationGroupId": "redis1x3",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"MultiAZ": "enabled",
"SnapshotWindow": "11:30-12:30",
"SnapshottingClusterId": "redis1x3-002",
"MemberClusters": [
"redis1x3-001",
"redis1x3-002",
"redis1x3-003"
],
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
Pour suivre la progression de votre basculement, utilisez l' AWS CLI `describe-events`opération.
Pour plus d'informations, veuillez consulter les ressources suivantes :
+ [test-failover](https://docs.aws.amazon.com/cli/latest/reference/elasticache/test-failover.html) dans la *Référence des commandes de l'AWS CLI *.
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) dans la *Référence des commandes de l'AWS CLI *.
### Test du basculement automatique à l'aide de l'API ElastiCache
Vous pouvez tester le basculement automatique sur n'importe quel cluster activé avec Multi-AZ à l'aide de l'opération ElastiCache API. `TestFailover`
**Paramètres**
+ `ReplicationGroupId` : obligatoire. Groupe de réplication (sur la console, le cluster) qui va être testé.
+ `NodeGroupId` : obligatoire. Nom du groupe de nœuds sur lequel vous souhaitez tester le basculement automatique. Vous pouvez tester un maximum de 15 groupes de nœuds sur une période continue de 24 heures.
L'exemple suivant teste le basculement automatique sur le groupe de nœuds `redis00-0003` dans le groupe de réplication (sur la console, cluster) `redis00`.
**Example Test du basculement automatique**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=TestFailover
&NodeGroupId=redis00-0003
&ReplicationGroupId=redis00
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=
```
Pour suivre la progression de votre basculement, utilisez l'opération ElastiCache `DescribeEvents` API.
Pour plus d’informations, consultez les ressources suivantes :
+ [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)dans la *référence de ElastiCache l'API*
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)dans la *référence de ElastiCache l'API*
## Limitations relatives à la technologie Multi-AZ
Tenez compte des limites suivantes pour le Multi-AZ :
+ Le multi-AZ est pris en charge sur Valkey et sur Redis OSS version 2.8.6 et versions ultérieures.
+ Le multi-AZ n'est pas pris en charge sur les types de nœuds T1.
+ La réplication Valkey et Redis OSS est asynchrone. Par conséquent, lorsqu'un nœud principal bascule vers un réplica, une petite quantité de données peut être perdue en raison d'un décalage de réplication.
Lorsque vous choisissez le réplica à promouvoir au niveau principal, ElastiCache choisissez le réplica présentant le moins de retard de réplication. En d'autres termes, il choisit le réplica le plus à jour. Cela permet de réduire la quantité de données perdues. Le réplica dont le décalage de réplication est le moins important peut se trouver dans la même zone de disponibilité que le nœud principal défaillant ou dans une zone de disponibilité différente.
+ Lorsque vous promouvez manuellement des répliques en lecture au statut principal sur des clusters Valkey ou Redis OSS avec le mode cluster désactivé, vous ne pouvez le faire que lorsque le mode multi-AZ et le basculement automatique sont désactivés. Pour promouvoir un réplica en lecture en réplica principal, procédez comme suit :
1. Désactivez Multi-AZ sur le cluster.
1. Désactivez le basculement automatique sur le cluster. Vous pouvez le faire via la console en décochant la case **Auto failover** pour le groupe de réplication. Vous pouvez également le faire en AWS CLI définissant la `AutomaticFailoverEnabled` propriété sur `false` lorsque vous appelez l'`ModifyReplicationGroup`opération.
1. Promouvez le réplica en lecture en réplica principal.
1. Réactivez Multi-AZ.
+ ElastiCache pour Redis OSS Multi-AZ et fichier d'ajout uniquement (AOF) s'excluent mutuellement. Si vous en activez une, vous ne pouvez pas activer l'autre.
+ La défaillance d'un nœud peut être provoquée par une improbable panne générale de la zone de disponibilité. Dans ce cas, le réplica remplaçant le réplica principal ayant échoué n'est créé que si la zone de disponibilité est rétablie. Par exemple, imaginons un groupe de réplication avec le principal dans AZ-a et des réplicas dans AZ-b et AZ-c. En cas de défaillance du principal, le réplica ayant le moindre décalage de réplication sera promu au rang de cluster principal. ElastiCache Crée ensuite une nouvelle réplique dans AZ-a (où se trouvait le principal défaillant) uniquement lorsque AZ-a est de nouveau disponible.
+ Un redémarrage lancé par le client d'un principal n'entraîne de basculement automatique. D'autres redémarrages et défaillances déclenchent un basculement automatique.
+ Lorsque le principal est redémarré, ses données sont effacées dès qu'il est à nouveau en ligne. Lorsque les réplicas en lecture voient le cluster principal effacé, ils effacent leur copie de données, ce qui entraîne une perte des données.
+ Une fois qu'un réplica en lecture a été promu, les autres réplicas se synchronisent avec le nouveau principal. Après la synchronisation initiale, le contenu des réplicas est supprimé et ils synchronisent les données du nouveau principal. Ce processus de synchronisation provoque une brève interruption, au cours de laquelle les réplicas ne sont pas accessibles. Le processus de synchronisation entraîne également une augmentation de la charge temporaire sur le cluster principal lors de la synchronisation avec les réplicas. Ce comportement est propre à Valkey et Redis OSS et n'est pas propre à ElastiCache Multi-AZ. Pour plus de détails sur ce comportement, consultez la section [Réplication](http://valkey.io/topics/replication) sur le site Web de Valkey.
**Important**
Pour Valkey 7.2.6 et versions ultérieures ou Redis OSS version 2.8.22 et versions ultérieures, vous ne pouvez pas créer de répliques externes.
Pour les versions de Redis OSS antérieures à 2.8.22, nous vous recommandons de ne pas connecter de réplique externe à un ElastiCache cluster compatible avec le mode multi-AZ. Cette configuration non prise en charge peut créer des problèmes qui ElastiCache empêchent d'effectuer correctement le basculement et la restauration. Pour connecter une réplique externe à un ElastiCache cluster, assurez-vous que le mode Multi-AZ n'est pas activé avant d'établir la connexion.
# Implémentation de la sauvegarde et de la synchronisation
Toutes les versions prises en charge de Valkey et Redis OSS prennent en charge la sauvegarde et la synchronisation entre le nœud principal et le nœud de réplication. Cependant, la manière dont la sauvegarde et la synchronisation sont mises en œuvre varie en fonction de la version.
## Redis OSS version 2.8.22 et versions ultérieures
La réplication Redis OSS, dans les versions 2.8.22 et ultérieures, permet de choisir entre deux méthodes. Pour plus d’informations, consultez [Versions de Redis OSS antérieures à 2.8.22](#Replication.Redis.Earlier2-8-22) et [Instantané et restauration](backups.md).
Au cours d'un processus sans fonction fork, si les charges d'écriture sont élevées, les écritures sur le cluster sont retardées pour éviter d'accumuler trop de changements et de mettre en échec la création de l'instantané.
## Versions de Redis OSS antérieures à 2.8.22
La sauvegarde et la synchronisation de Redis OSS dans les versions antérieures à la version 2.8.22 sont un processus en trois étapes.
1. Appliquez la fonction fork et, dans le processus d'arrière-plan, sérialisez les données de cluster sur le disque. Cela crée un point-in-time instantané.
1. Au premier plan, créez un journal des modifications dans la *mémoire tampon de sortie du client*.
**Important**
Si le journal des modifications dépasse la taille de la *mémoire tampon de sortie du client*, la sauvegarde ou la synchronisation échoue. Pour de plus amples informations, veuillez consulter [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md).
1. Enfin, transmettez les données de cache, puis le journal des modifications au nœud réplica.
# Création d'un groupe de réplication Valkey ou Redis OSS
Vous disposez des options suivantes pour créer un cluster avec des nœuds de réplica. L'une s'applique lorsque vous disposez déjà d'un cluster Valkey ou Redis OSS (mode cluster désactivé) disponible qui n'est associé à aucun cluster contenant des répliques à utiliser comme nœud principal. L'autre s'applique lorsque vous avez besoin de créer un nœud principal avec les réplicas de cluster et en lecture. Actuellement, un cluster Valkey ou Redis OSS (mode cluster activé) doit être créé à partir de zéro.
**Option 1 :[Création d'un groupe de réplication à l'aide d'un cluster existant](Replication.CreatingReplGroup.ExistingCluster.md)**
Utilisez cette option pour tirer parti d'un cluster Valkey ou Redis OSS à nœud unique existant (mode cluster désactivé). Vous spécifiez ce nœud existant en tant que nœud primaire dans le nouveau cluster, puis ajoutez individuellement de 1 à 5 réplicas en lecture au cluster. Si le cluster existant est actif, les réplicas en lecture se synchronisent avec lui au fur et à mesure de leur création. Consultez [Création d'un groupe de réplication à l'aide d'un cluster existant](Replication.CreatingReplGroup.ExistingCluster.md).
Vous ne pouvez pas créer de cluster Valkey ou Redis OSS (mode cluster activé) en utilisant un cluster existant. Pour créer un cluster Valkey ou Redis OSS (mode cluster activé) (API/CLI : groupe de réplication) à l'aide de la ElastiCache console, consultez. [Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
**Option 2 :[Création d'un groupe de réplication Valkey ou Redis OSS à partir de zéro](Replication.CreatingReplGroup.NoExistingCluster.md)**
Utilisez cette option si vous ne disposez pas encore d'un cluster Valkey ou Redis OSS (mode cluster désactivé) disponible à utiliser comme nœud principal du cluster, ou si vous souhaitez créer un cluster Valkey ou Redis OSS (mode cluster activé). Consultez [Création d'un groupe de réplication Valkey ou Redis OSS à partir de zéro](Replication.CreatingReplGroup.NoExistingCluster.md).
# Création d'un groupe de réplication à l'aide d'un cluster existant
La procédure suivante ajoute un groupe de réplication à votre cluster à nœud unique Valkey ou Redis OSS (mode cluster désactivé), ce qui est nécessaire pour mettre à niveau votre cluster vers la dernière version de Valkey. Il s'agit d'une procédure sur place qui n'implique aucun temps d'arrêt ni aucune perte de données. Lorsque vous créez un groupe de réplication pour votre cluster à nœud unique, le nœud du cluster devient le nœud principal du nouveau cluster. Si vous ne disposez pas d'un cluster Valkey ou Redis OSS (mode cluster désactivé) que vous pouvez utiliser comme cluster principal du nouveau cluster, consultez. [Création d'un groupe de réplication Valkey ou Redis OSS à partir de zéro](Replication.CreatingReplGroup.NoExistingCluster.md)
Un cluster disponible est un cluster Valkey ou Redis OSS à nœud unique existant. Actuellement, Valkey ou Redis OSS (mode cluster activé) ne prennent pas en charge la création d'un cluster avec des répliques à l'aide d'un cluster à nœud unique disponible. Si vous souhaitez créer un cluster Valkey ou Redis OSS (mode cluster activé), consultez. [Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
## Création d'un groupe de réplication à l'aide d'un cluster existant (console)
Consultez la rubrique [À l'aide du ElastiCache AWS Management Console](Clusters.AddNode.md#Clusters.AddNode.CON).
## Création d'un groupe de réplication à l'aide d'un cluster Valkey ou Redis OSS disponible ()AWS CLI
La création d'un groupe de réplication avec des répliques de lecture se fait en deux étapes lorsque vous utilisez un cluster de cache Valkey ou Redis OSS disponible pour le serveur principal lorsque vous utilisez le.AWS CLI
Lorsque vous utilisez le,AWS CLI vous créez un groupe de réplication en spécifiant le nœud autonome disponible comme nœud principal du cluster, `--primary-cluster-id` ainsi que le nombre de nœuds que vous souhaitez dans le cluster à l'aide de la commande CLI,`create-replication-group`. Incluez les paramètres suivants.
**--replication-group-id**
Le nom du groupe de réplication que vous créez. La valeur de ce paramètre sert de base pour les noms des nœuds ajoutés avec une séquence de 3 chiffres ajoutés à la fin du `--replication-group-id`. Par exemple, `sample-repl-group-001`.
Les contraintes de dénomination des groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**--replication-group-description**
Description du groupe de réplication.
**--num-node-groups**
Nombre de nœuds que vous souhaitez dans ce cluster. Cette valeur inclut le nœud principal. Ce paramètre a une valeur maximale de six.
**--primary-cluster-id**
Nom du nœud du cluster Valkey ou Redis OSS (mode cluster désactivé) disponible dont vous souhaitez faire le nœud principal de ce groupe de réplication.
La commande suivante crée le groupe de réplication `sample-repl-group` en utilisant le cluster Valkey ou Redis OSS (mode cluster désactivé) disponible `redis01` comme nœud principal du groupe de réplication. Cela crée 2 nœuds qui sont des réplicas en lecture seule. Les paramètres de `redis01` (c'est-à-dire, le groupe de paramètres, le groupe de sécurité, le type de nœud, la version du moteur, etc.) seront appliqués à tous les nœuds du groupe de réplication.
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "demo cluster with replicas" \
--num-cache-clusters 3 \
--primary-cluster-id redis01
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "demo cluster with replicas" ^
--num-cache-clusters 3 ^
--primary-cluster-id redis01
```
Pour plus d'informations et de paramètres que vous pourriez vouloir utiliser, consultez la AWS CLI rubrique[create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html).
**Ajoutez ensuite des réplicas en lecture à ce groupe de réplication.**
Après la création du groupe de réplication, ajoutez au groupe de un à cinq réplicas en lecture à l'aide de la commande `create-cache-cluster`, sans oublier de définir les paramètres suivants.
**--cache-cluster-id**
Le nom du cluster que vous ajoutez au groupe de réplication.
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**--replication-group-id**
Nom du groupe de réplication auquel vous ajoutez ce cluster.
Répétez cette commande pour chaque réplica en lecture que vous souhaitez ajouter au groupe de réplication, en modifiant seulement du paramètre `--cache-cluster-id`.
**Note**
Rappelez-vous qu'un groupe de réplication ne peut pas avoir plus de cinq réplicas en lecture. Si vous essayez d'ajouter un réplica en lecture à un groupe de réplication qui en contient déjà cinq, l'opération échoue.
Le code suivant ajoute le réplica en lecture `my-replica01` au groupe de réplication `sample-repl-group`. Les paramètres du cluster principal (groupe de paramètres, groupe de sécurité, type de nœud, etc.) seront appliqués aux nœuds à mesure qu'ils sont ajoutés au groupe de réplication.
Pour Linux, macOS ou Unix :
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-replica01 \
--replication-group-id sample-repl-group
```
Pour Windows :
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-replica01 ^
--replication-group-id sample-repl-group
```
Le résultat de cette commande doit être semblable à ce qui suit.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "00:00-01:00",
"SnapshottingClusterId": "redis01",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"redis01"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations, consultez les AWS CLI rubriques suivantes :
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
+ [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)
## Ajouter des répliques à un cluster (API) autonome Valkey ou Redis OSS (mode cluster désactivé) ElastiCache
Lorsque vous utilisez l' ElastiCache API, vous créez un groupe de réplication en spécifiant le nœud autonome disponible en tant que nœud principal du cluster, `PrimaryClusterId` ainsi que le nombre de nœuds que vous souhaitez inclure dans le cluster à l'aide de la commande CLI,`CreateReplicationGroup`. Incluez les paramètres suivants.
**ReplicationGroupId**
Le nom du groupe de réplication que vous créez. La valeur de ce paramètre sert de base pour les noms des nœuds ajoutés avec une séquence de 3 chiffres ajoutés à la fin du `ReplicationGroupId`. Par exemple, `sample-repl-group-001`.
Les contraintes de dénomination des groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**ReplicationGroupDescription**
Description du cluster avec réplicas.
**NumCacheClusters**
Nombre de nœuds que vous souhaitez dans ce cluster. Cette valeur inclut le nœud principal. Ce paramètre a une valeur maximale de six.
**PrimaryClusterId**
Le nom du cluster Valkey ou Redis OSS disponible (mode cluster désactivé) dont vous souhaitez faire le nœud principal de ce cluster.
La commande suivante crée le cluster avec des répliques `sample-repl-group` en utilisant le cluster Valkey ou Redis OSS (mode cluster désactivé) disponible `redis01` comme nœud principal du groupe de réplication. Cela crée 2 nœuds qui sont des réplicas en lecture seule. Les paramètres de `redis01` (c'est-à-dire, le groupe de paramètres, le groupe de sécurité, le type de nœud, la version du moteur, etc.) seront appliqués à tous les nœuds du groupe de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&Engine=redis
&EngineVersion=6.0
&ReplicationGroupDescription=Demo%20cluster%20with%20replicas
&ReplicationGroupId=sample-repl-group
&PrimaryClusterId=redis01
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez les rubriques relatives aux ElastiCache APL :
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
**Ajoutez ensuite des réplicas en lecture à ce groupe de réplication.**
Après la création du groupe de réplication, ajoutez au groupe de un à cinq réplicas en lecture en utilisant l'opération `CreateCacheCluster`, sans oublier de définir les paramètres ci-dessous.
**CacheClusterId**
Le nom du cluster que vous ajoutez au groupe de réplication.
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**ReplicationGroupId**
Nom du groupe de réplication auquel vous ajoutez ce cluster.
Répétez cette opération pour chaque réplica en lecture que vous souhaitez ajouter au groupe de réplication, en modifiant seulement la valeur du paramètre `CacheClusterId`.
Le code suivant ajouter le réplica en lecture `myReplica01` au groupe de réplication `myReplGroup`. Les paramètres du cluster principal (groupe de paramètres, groupe de sécurité, type de nœud, etc.) seront appliqués aux nœuds à mesure qu'ils sont ajoutés au groupe de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReplica01
&ReplicationGroupId=myReplGroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2015-02-02
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=[your-access-key-id]/20150202/us-west-2/elasticache/aws4_request
&X-Amz-Date=20150202T170651Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=[signature-value]
```
Pour plus d'informations et de paramètres que vous souhaiterez peut-être utiliser, consultez la rubrique ElastiCache API[CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html).
# Création d'un groupe de réplication Valkey ou Redis OSS à partir de zéro
Vous trouverez ci-dessous comment créer un groupe de réplication Valkey ou Redis OSS sans utiliser un cluster Valkey ou Redis OSS existant comme principal. Vous pouvez créer un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) ou Valkey ou Redis OSS (mode cluster activé) à partir de zéro à l'aide de la ElastiCache console, de l'API ou de l'API AWS CLI. ElastiCache
Avant de continuer, décidez si vous souhaitez créer un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) ou un groupe de réplication Valkey ou Redis OSS (mode cluster activé). Pour vous aider à faire votre choix, consultez [Réplication : mode cluster Valkey et Redis OSS désactivé ou activé](Replication.Redis-RedisCluster.md).
**Topics**
+ [Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro](Replication.CreatingReplGroup.NoExistingCluster.Classic.md)
+ [Création d'un groupe de réplication dans Valkey ou Redis OSS (mode cluster activé) à partir de zéro](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md)
# Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro
Vous pouvez créer un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro à l'aide de la ElastiCache console, de l' AWS CLI API ou de l' ElastiCache API. Un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) possède toujours un groupe de nœuds, un cluster principal et jusqu'à cinq répliques de lecture. Les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) ne prennent pas en charge le partitionnement de vos données.
**Note**
La node/shard limite peut être augmentée jusqu'à un maximum de 500 par cluster. Pour demander une augmentation de la limite, veuillez consulter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et indiquez le type d'instance dans la demande.
Pour créer un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro, adoptez l'une des approches suivantes :
## Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro ()AWS CLI
La procédure suivante crée un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à l'aide du. AWS CLI
Lorsque vous créez un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro, vous créez le groupe de réplication et tous ses nœuds en un seul appel à la AWS CLI `create-replication-group` commande. Incluez les paramètres suivants.
**--replication-group-id**
Le nom du groupe de réplication que vous créez.
Les contraintes de dénomination des groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**--replication-group-description**
Description du groupe de réplication.
**--num-cache-clusters**
Le nombre de nœuds que vous souhaitez créer avec ce groupe de réplication, réplica principal et réplicas en lecture combinés.
Si vous activez Multi-AZ (`--automatic-failover-enabled`), la valeur de `--num-cache-clusters` doit être au moins 2.
**--cache-node-type**
Le type de nœud pour chaque nœud dans le groupe de réplication.
ElastiCache prend en charge les types de nœuds suivants. En général, les types de la génération actuelle offrent davantage de mémoire et de puissance de calcul pour un coût inférieur, par rapport à leurs homologues équivalents de la génération précédente.
Pour plus d'informations sur les performances de chaque type de nœud, consultez [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Définissez ce paramètre si vous utilisez un type de nœud r6gd. Si vous ne souhaitez pas effectuer de hiérarchisation des données, définissez `--no-data-tiering-enabled`. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
**--cache-parameter-group**
Spécifiez un groupe de paramètres qui correspond à la version de votre moteur. Si vous exécutez Redis OSS 3.2.4 ou version ultérieure, spécifiez le groupe de `default.redis3.2` paramètres ou un groupe de paramètres dérivé `default.redis3.2` pour créer un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé). Pour de plus amples informations, veuillez consulter [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--network-type**
`ipv4`, `ipv6` ou `dual-stack`. Si vous choisissez la double pile, vous devez définir le paramètre `--IpDiscovery` sur `ipv4` ou `ipv6`.
**--engine**
redis
**--engine-version**
Pour bénéficier de l'ensemble des fonctionnalités, choisissez la dernière version du moteur.
Les noms des nœuds dériveront du nom du groupe de réplication en ajoutant le suffixe `-00`*\$1* au nom du groupe de réplication. Par exemple, en utilisant le nom de groupe de réplication `myReplGroup`, le nom du nœud principal sera `myReplGroup-001` et pour les réplicas en lecture de `myReplGroup-002` jusqu'à `myReplGroup-006`.
Si vous souhaitez activer le chiffrement en transit ou au repos sur ce groupe de réplication, ajoutez l'un ou l'autre ou les deux paramètres `--transit-encryption-enabled` ou `--at-rest-encryption-enabled` et remplissez les conditions suivantes.
+ Votre groupe de réplication doit exécuter Redis OSS version 3.2.6 ou 4.0.10.
+ Le groupe de réplication doit être créé dans un Amazon VPC.
+ Vous devez également inclure le paramètre `--cache-subnet-group`.
+ Vous devez également inclure le paramètre `--auth-token` avec la valeur de chaîne à client spécifié pour votre jeton AUTH (mot de passe) nécessaire à la réalisation des opérations sur ce groupe de réplication.
L'opération suivante crée un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) `sample-repl-group` avec trois nœuds, un nœud principal et deux répliques.
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "Demo cluster with replicas" \
--num-cache-clusters 3 \
--cache-node-type cache.m4.large \
--engine redis
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "Demo cluster with replicas" ^
--num-cache-clusters 3 ^
--cache-node-type cache.m4.large ^
--engine redis
```
Le résultat de la commande ressemble à ceci.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "disabled",
"SnapshotWindow": "01:30-02:30",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"sample-repl-group-003"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations et de paramètres que vous pourriez vouloir utiliser, consultez la AWS CLI rubrique [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html).
## Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro (ElastiCache API)
La procédure suivante crée un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à l'aide de l' ElastiCache API.
Lorsque vous créez un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro, vous créez le groupe de réplication et tous ses nœuds en un seul appel à l'opération d' ElastiCache API`CreateReplicationGroup`. Incluez les paramètres suivants.
**ReplicationGroupId**
Le nom du groupe de réplication que vous créez.
Les contraintes de dénomination des groupes de réplication Valkey ou Redis OSS (mode cluster activé) sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**ReplicationGroupDescription**
La description de votre groupe de sécurité.
**NumCacheClusters**
Le nombre total de nœuds que vous souhaitez créer avec ce groupe de réplication, réplica principal et réplicas en lecture combinés.
Si vous activez Multi-AZ (`AutomaticFailoverEnabled=true`), la valeur de `NumCacheClusters` doit être au moins 2.
**CacheNodeType**
Le type de nœud pour chaque nœud dans le groupe de réplication.
ElastiCache prend en charge les types de nœuds suivants. En général, les types de la génération actuelle offrent davantage de mémoire et de puissance de calcul pour un coût inférieur, par rapport à leurs homologues équivalents de la génération précédente.
Pour plus d'informations sur les performances de chaque type de nœud, consultez [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Définissez ce paramètre si vous utilisez un type de nœud r6gd. Si vous ne souhaitez pas effectuer de hiérarchisation des données, définissez `--no-data-tiering-enabled`. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
**CacheParameterGroup**
Spécifiez un groupe de paramètres qui correspond à la version de votre moteur. Si vous exécutez Redis OSS 3.2.4 ou version ultérieure, spécifiez le groupe de `default.redis3.2` paramètres ou un groupe de paramètres dérivé `default.redis3.2` pour créer un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé). Pour de plus amples informations, veuillez consulter [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--network-type**
`ipv4`, `ipv` ou `dual-stack`. Si vous choisissez la double pile, vous devez définir le paramètre `--IpDiscovery` sur `ipv4` ou `ipv6`.
**Moteur**
redis
**EngineVersion**
6.0
Les noms des nœuds dériveront du nom du groupe de réplication en ajoutant le suffixe `-00`*\$1* au nom du groupe de réplication. Par exemple, en utilisant le nom de groupe de réplication `myReplGroup`, le nom du nœud principal sera `myReplGroup-001` et pour les réplicas en lecture de `myReplGroup-002` jusqu'à `myReplGroup-006`.
Si vous souhaitez activer le chiffrement en transit ou au repos sur ce groupe de réplication, ajoutez l'un ou l'autre ou les deux paramètres `TransitEncryptionEnabled=true` ou `AtRestEncryptionEnabled=true` et remplissez les conditions suivantes.
+ Votre groupe de réplication doit exécuter Redis OSS version 3.2.6 ou 4.0.10.
+ Le groupe de réplication doit être créé dans un Amazon VPC.
+ Vous devez également inclure le paramètre `CacheSubnetGroup`.
+ Vous devez également inclure le paramètre `AuthToken` avec la valeur de chaîne à client spécifié pour votre jeton AUTH (mot de passe) nécessaire à la réalisation des opérations sur ce groupe de réplication.
L'opération suivante crée le groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) `myReplGroup` avec trois nœuds, un nœud principal et deux répliques.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParameterGroup=default.redis6.x
&Engine=redis
&EngineVersion=6.0
&NumCacheClusters=3
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations et de paramètres que vous souhaiterez peut-être utiliser, consultez la rubrique ElastiCache API[CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html).
# Création d'un groupe de réplication dans Valkey ou Redis OSS (mode cluster activé) à partir de zéro
Vous pouvez créer un cluster Valkey ou Redis OSS (mode cluster activé) (API/CLI : *groupe de réplication*) à l'aide de la ElastiCache console, de l'API ou de l' AWS CLI API. ElastiCache Un groupe de réplication Valkey ou Redis OSS (mode cluster activé) comprend de 1 à 500 partitions (API/CLI : groupes de nœuds), un nœud principal dans chaque partition et jusqu'à 5 répliques de lecture dans chaque partition. Vous pouvez créer un cluster contenant un nombre de partitions supérieur et un nombre de réplicas inférieur, qui conduisent à un nombre total de 90 nœuds par cluster. Cette configuration de cluster peut contenir de 90 partitions avec 0 réplica à 15 partitions avec 5 réplicas, ce qui correspond au nombre maximal de réplicas autorisé.
La limite de nœuds ou de partitions peut être augmentée jusqu'à un maximum de 500 par cluster si la version du moteur Valkey ou Redis OSS est 5.0.6 ou supérieure. Par exemple, vous pouvez choisir de configurer un cluster de 500 nœuds compris entre 83 (un principal et 5 réplicas par partition) et 500 partitions (un principal et aucun réplicas). Assurez-vous qu’il y ait suffisamment d’adresses IP disponibles pour faire face à l’augmentation. Les pièges courants incluent les sous-réseaux du groupe de sous-réseaux avec une plage CIDR trop petite ou les sous-réseaux partagés et fortement utilisés par d’autres clusters. Pour de plus amples informations, veuillez consulter [Création d'un groupe de sous-réseaux](SubnetGroups.Creating.md).
Pour les versions antérieures à 5.0.6, la limite est de 250 par cluster.
Pour demander une augmentation de cette limite, veuillez consulter [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et sélectionnez le type de limite **Nœuds par cluster par type d'instance**.
**Topics**
+ [Utilisation de la ElastiCache console](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
+ [Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à partir de zéro ()AWS CLI](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI)
+ [Création d'un groupe de réplication dans Valkey ou Redis OSS (mode cluster activé) à partir de zéro (ElastiCache API)](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.API)
## Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)
Pour créer un cluster Valkey ou Redis OSS (mode cluster activé), consultez. [Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) Veillez à activer le mode de cluster, **Cluster Mode enabled (Scale Out)** et spécifiez au moins deux partitions et un nœud de réplica dans chaque.
## Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à partir de zéro ()AWS CLI
La procédure suivante crée un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à l'aide du. AWS CLI
Lorsque vous créez un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à partir de zéro, vous créez le groupe de réplication et tous ses nœuds en un seul appel à la AWS CLI `create-replication-group` commande. Incluez les paramètres suivants.
**--replication-group-id**
Le nom du groupe de réplication que vous créez.
Les contraintes de dénomination des groupes de réplication Valkey ou Redis OSS (mode cluster activé) sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**--replication-group-description**
Description du groupe de réplication.
**--cache-node-type**
Le type de nœud pour chaque nœud dans le groupe de réplication.
ElastiCache prend en charge les types de nœuds suivants. En général, les types de la génération actuelle offrent davantage de mémoire et de puissance de calcul pour un coût inférieur, par rapport à leurs homologues équivalents de la génération précédente.
Pour plus d'informations sur les performances de chaque type de nœud, consultez [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Définissez ce paramètre si vous utilisez un type de nœud r6gd. Si vous ne souhaitez pas effectuer de hiérarchisation des données, définissez `--no-data-tiering-enabled`. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
**--cache-parameter-group**
Spécifiez le groupe de `default.redis6.x.cluster.on` paramètres ou un groupe de paramètres dérivé `default.redis6.x.cluster.on` pour créer un groupe de réplication Valkey ou Redis OSS (mode cluster activé). Pour de plus amples informations, veuillez consulter [Modifications des paramètres de Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--engine**
redis
**--engine-version**
3.2.4
**--num-node-groups**
Le nombre de groupes de nœuds dans ce groupe de réplication. Valeurs valides : de 1 à 500.
La node/shard limite peut être augmentée jusqu'à un maximum de 500 par cluster. Pour demander une augmentation de cette limite, veuillez consulter [AWS Service Limit ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) et choisissez le type de limite « Nœuds par cluster par type d'instance ».
**--replicas-per-node-group**
Le nombre de nœuds de réplica dans chaque groupe de nœuds. Les valeurs valides sont comprises entre 0 et 5.
**--network-type**
`ipv4`, `ipv` ou `dual-stack`. Si vous choisissez la double pile, vous devez définir le paramètre `--IpDiscovery` sur `ipv4` ou `ipv6`.
Si vous souhaitez activer le chiffrement en transit ou au repos sur ce groupe de réplication, ajoutez l'un ou l'autre ou les deux paramètres `--transit-encryption-enabled` ou `--at-rest-encryption-enabled` et remplissez les conditions suivantes.
+ Votre groupe de réplication doit exécuter Redis OSS version 3.2.6 ou 4.0.10.
+ Le groupe de réplication doit être créé dans un Amazon VPC.
+ Vous devez également inclure le paramètre `--cache-subnet-group`.
+ Vous devez également inclure le paramètre `--auth-token` avec la valeur de chaîne à client spécifié pour votre jeton AUTH (mot de passe) nécessaire à la réalisation des opérations sur ce groupe de réplication.
L'opération suivante crée le groupe de réplication Valkey ou Redis OSS (mode cluster activé) `sample-repl-group` avec trois nœuds groups/shards (--num-node-groups), chacun avec trois nœuds, un principal et deux répliques en lecture (--). replicas-per-node-group
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "Demo cluster with replicas" \
--num-node-groups 3 \
--replicas-per-node-group 2 \
--cache-node-type cache.m4.large \
--engine redis \
--security-group-ids SECURITY_GROUP_ID \
--cache-subnet-group-name SUBNET_GROUP_NAME>
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "Demo cluster with replicas" ^
--num-node-groups 3 ^
--replicas-per-node-group 2 ^
--cache-node-type cache.m4.large ^
--engine redis ^
--security-group-ids SECURITY_GROUP_ID ^
--cache-subnet-group-name SUBNET_GROUP_NAME>
```
La commande précédente génère la sortie suivante.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "enabled",
"SnapshotWindow": "05:30-06:30",
"MemberClusters": [
"sample-repl-group-0001-001",
"sample-repl-group-0001-002",
"sample-repl-group-0001-003",
"sample-repl-group-0002-001",
"sample-repl-group-0002-002",
"sample-repl-group-0002-003",
"sample-repl-group-0003-001",
"sample-repl-group-0003-002",
"sample-repl-group-0003-003"
],
"PendingModifiedValues": {}
}
}
```
Lorsque vous créez un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à partir de zéro, vous pouvez configurer chaque partition du cluster à l'aide du `--node-group-configuration` paramètre illustré dans l'exemple suivant qui configure deux groupes de nœuds (console : partitions). La première partition comporte deux nœuds, un nœud principal et un réplica en lecture. La deuxième partition comporte trois nœuds, un nœud principal et deux réplicas en lecture.
**--node-group-configuration**
La configuration pour chaque groupe de nœuds. Le paramètre `--node-group-configuration` se compose des champs suivants.
+ `PrimaryAvailabilityZone` : la zone de disponibilité où se trouve le nœud primaire de ce groupe de nœuds. Si ce paramètre est omis, ElastiCache choisit la zone de disponibilité pour le nœud principal.
**Par exemple :** us-west-2a.
+ `ReplicaAvailabilityZones` : une liste séparée par des virgules des zones de disponibilité où se trouvent les réplicas en lecture. Le nombre de zones de disponibilité dans cette liste doit correspondre à la valeur `ReplicaCount`. Si ce paramètre est omis, ElastiCache choisit les zones de disponibilité pour les nœuds de réplication.
**Exemple :** « us-west-2a, us-west-2b, us-west-2c »
+ `ReplicaCount` – Le nombre de nœuds de réplica dans ce groupe de nœuds.
+ `Slots` : chaîne qui spécifie l'espace de clés pour le groupe de nœuds. La chaîne est au format `startKey-endKey`. Si ce paramètre est omis, les clés sont réparties ElastiCache de manière égale entre les groupes de nœuds.
**Exemple :** "0-4999"
L'opération suivante crée le groupe de réplication Valkey ou Redis OSS (mode cluster activé) `new-group` avec deux groupes/fragments de nœuds (). `--num-node-groups` À l'inverse de l'exemple précédent, chaque groupe de nœuds est configuré différemment de l'autre groupe de nœuds (`--node-group-configuration`).
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id new-group \
--replication-group-description "Sharded replication group" \
--engine redis \
--snapshot-retention-limit 8 \
--cache-node-type cache.m4.medium \
--num-node-groups 2 \
--node-group-configuration \
"ReplicaCount=1,Slots=0-8999,PrimaryAvailabilityZone='us-east-1c',ReplicaAvailabilityZones='us-east-1b'" \
"ReplicaCount=2,Slots=9000-16383,PrimaryAvailabilityZone='us-east-1a',ReplicaAvailabilityZones='us-east-1a','us-east-1c'"
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id new-group ^
--replication-group-description "Sharded replication group" ^
--engine redis ^
--snapshot-retention-limit 8 ^
--cache-node-type cache.m4.medium ^
--num-node-groups 2 ^
--node-group-configuration \
"ReplicaCount=1,Slots=0-8999,PrimaryAvailabilityZone='us-east-1c',ReplicaAvailabilityZones='us-east-1b'" \
"ReplicaCount=2,Slots=9000-16383,PrimaryAvailabilityZone='us-east-1a',ReplicaAvailabilityZones='us-east-1a','us-east-1c'"
```
L'opération précédente génère la sortie suivante.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Sharded replication group",
"ReplicationGroupId": "rc-rg",
"SnapshotRetentionLimit": 8,
"AutomaticFailover": "enabled",
"SnapshotWindow": "10:00-11:00",
"MemberClusters": [
"rc-rg-0001-001",
"rc-rg-0001-002",
"rc-rg-0002-001",
"rc-rg-0002-002",
"rc-rg-0002-003"
],
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations et de paramètres que vous pourriez vouloir utiliser, consultez la AWS CLI rubrique[create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html).
## Création d'un groupe de réplication dans Valkey ou Redis OSS (mode cluster activé) à partir de zéro (ElastiCache API)
La procédure suivante crée un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à l'aide de l' ElastiCache API.
Lorsque vous créez un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à partir de zéro, vous créez le groupe de réplication et tous ses nœuds en un seul appel à l'opération d' ElastiCache API`CreateReplicationGroup`. Incluez les paramètres suivants.
**ReplicationGroupId**
Le nom du groupe de réplication que vous créez.
Les contraintes de dénomination des groupes de réplication Valkey ou Redis OSS (mode cluster activé) sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
**ReplicationGroupDescription**
Description du groupe de réplication.
**NumNodeGroups**
Le nombre de groupes de nœuds que vous souhaitez créer avec ce groupe de réplication. Valeurs valides : de 1 à 500.
**ReplicasPerNodeGroup**
Le nombre de nœuds de réplica dans chaque groupe de nœuds. Les valeurs valides sont comprises entre 1 et 5.
**NodeGroupConfiguration**
La configuration pour chaque groupe de nœuds. Le paramètre `NodeGroupConfiguration` se compose des champs suivants.
+ `PrimaryAvailabilityZone` : la zone de disponibilité où se trouve le nœud primaire de ce groupe de nœuds. Si ce paramètre est omis, ElastiCache choisit la zone de disponibilité pour le nœud principal.
**Par exemple :** us-west-2a.
+ `ReplicaAvailabilityZones` : une liste des zones de disponibilité dans lesquelles se trouvent les réplicas en lecture. Le nombre de zones de disponibilité dans cette liste doit correspondre à la valeur `ReplicaCount`. Si ce paramètre est omis, ElastiCache choisit les zones de disponibilité pour les nœuds de réplication.
+ `ReplicaCount` : le nombre de nœuds de réplica dans ce groupe de nœuds.
+ `Slots` : chaîne qui spécifie l'espace de clés pour le groupe de nœuds. La chaîne est au format `startKey-endKey`. Si ce paramètre est omis, les clés sont réparties ElastiCache de manière égale entre les groupes de nœuds.
**Exemple :** "0-4999"
**CacheNodeType**
Le type de nœud pour chaque nœud dans le groupe de réplication.
ElastiCache prend en charge les types de nœuds suivants. En général, les types de la génération actuelle offrent davantage de mémoire et de puissance de calcul pour un coût inférieur, par rapport à leurs homologues équivalents de la génération précédente.
Pour plus d'informations sur les performances de chaque type de nœud, consultez [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Définissez ce paramètre si vous utilisez un type de nœud r6gd. Si vous ne souhaitez pas effectuer de hiérarchisation des données, définissez `--no-data-tiering-enabled`. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
**CacheParameterGroup**
Spécifiez le groupe de `default.redis6.x.cluster.on` paramètres ou un groupe de paramètres dérivé `default.redis6.x.cluster.on` pour créer un groupe de réplication Valkey ou Redis OSS (mode cluster activé). Pour de plus amples informations, veuillez consulter [Modifications des paramètres de Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--network-type**
`ipv4`, `ipv` ou `dual-stack`. Si vous choisissez la double pile, vous devez définir le paramètre `--IpDiscovery` sur `ipv4` ou `ipv6`.
**Moteur**
redis
**EngineVersion**
6.0
Si vous souhaitez activer le chiffrement en transit ou au repos sur ce groupe de réplication, ajoutez l'un ou l'autre ou les deux paramètres `TransitEncryptionEnabled=true` ou `AtRestEncryptionEnabled=true` et remplissez les conditions suivantes.
+ Votre groupe de réplication doit exécuter Redis OSS version 3.2.6 ou 4.0.10.
+ Le groupe de réplication doit être créé dans un Amazon VPC.
+ Vous devez également inclure le paramètre `CacheSubnetGroup`.
+ Vous devez également inclure le paramètre `AuthToken` avec la valeur de chaîne à client spécifié pour votre jeton AUTH (mot de passe) nécessaire à la réalisation des opérations sur ce groupe de réplication.
Des sauts de ligne sont ajoutés pour faciliter la lecture.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParemeterGroup=default.redis6.xcluster.on
&Engine=redis
&EngineVersion=6.0
&NumNodeGroups=3
&ReplicasPerNodeGroup=2
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations et de paramètres que vous souhaiterez peut-être utiliser, consultez la rubrique ElastiCache API[CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html).
# Affichage des détails d'un groupe de réplication
Selon vos besoins, vous pouvez afficher les détails d'un groupe de réplication. Vous pouvez utiliser la ElastiCache console, le AWS CLI for ElastiCache ou l' ElastiCache API. Le processus de console est différent pour Valkey ou Redis OSS (mode cluster désactivé) et Valkey ou Redis OSS (mode cluster activé).
**Contents**
+ [Affichage d'un système d'exploitation Valkey ou Redis (mode cluster désactivé) avec des répliques](Replication.ViewDetails.Redis.md)
+ [Utilisation de la ElastiCache console](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CON)
+ [À l'aide du AWS CLI](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CLI)
+ [Utilisation de l' ElastiCache API](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.API)
+ [Affichage d'un groupe de réplication : Valkey ou Redis OSS (mode cluster activé)](Replication.ViewDetails.RedisCluster.md)
+ [Utilisation de la ElastiCache console](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CON)
+ [À l'aide du AWS CLI](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CLI)
+ [Utilisation de l' ElastiCache API](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.API)
+ [Affichage des détails d'un groupe de réplication (AWS CLI)](Replication.ViewDetails.CLI.md)
+ [Afficher les détails d'un groupe de réplication (ElastiCache API)](Replication.ViewDetails.API.md)
# Affichage d'un système d'exploitation Valkey ou Redis (mode cluster désactivé) avec des répliques
Vous pouvez afficher les détails d'un cluster Valkey ou Redis OSS (mode cluster désactivé) avec des répliques (API/CLI : *groupe de réplication*) à l'aide de la ElastiCache console, du AWS CLI for ElastiCache ou de l'API. ElastiCache
**Contents**
+ [Utilisation de la ElastiCache console](#Replication.ViewDetails.Redis.CON)
+ [À l'aide du AWS CLI](#Replication.ViewDetails.Redis.CLI)
+ [Utilisation de l' ElastiCache API](#Replication.ViewDetails.Redis.API)
## Affichage d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) (console)
Pour afficher les détails d'un cluster Valkey ou Redis OSS (mode cluster désactivé) avec des répliques à l'aide de la ElastiCache console, consultez la rubrique. [Affichage des détails de Valkey ou Redis OSS (mode cluster désactivé) (console)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.Redis)
## Affichage d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) ()AWS CLI
Pour un AWS CLI exemple qui affiche les détails d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé), consultez. [Affichage des détails d'un groupe de réplication (AWS CLI)](Replication.ViewDetails.CLI.md)
## Affichage d'un groupe de réplication (API) Valkey ou Redis OSS (ElastiCache mode cluster désactivé)
Pour un exemple d' ElastiCache API qui affiche les détails d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé), consultez. [Afficher les détails d'un groupe de réplication (ElastiCache API)](Replication.ViewDetails.API.md)
# Affichage d'un groupe de réplication : Valkey ou Redis OSS (mode cluster activé)
## Affichage d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)
Pour afficher les détails d'un cluster Valkey ou Redis OSS (mode cluster activé) à l'aide de la ElastiCache console, consultez. [Affichage des détails d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.RedisCluster)
## Affichage d'un cluster Valkey ou Redis OSS (mode cluster activé) ()AWS CLI
Pour un exemple de ElastiCache CLI qui affiche les détails d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé), consultez. [Affichage des détails d'un groupe de réplication (AWS CLI)](Replication.ViewDetails.CLI.md)
## Affichage d'un cluster (API) Valkey ou Redis OSS (mode cluster activé) ElastiCache
Pour un exemple d' ElastiCache API qui affiche les détails d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé), consultez. [Afficher les détails d'un groupe de réplication (ElastiCache API)](Replication.ViewDetails.API.md)
# Affichage des détails d'un groupe de réplication (AWS CLI)
Vous pouvez consulter les détails d'un groupe de réplication à l'aide de la AWS CLI `describe-replication-groups` commande. Utilisez les paramètres facultatifs suivants pour affiner la liste. Si les paramètres ne sont pas spécifiés, vous obtenez les détails de 100 groupes de réplication maximum.
**Paramètres facultatifs**
+ `--replication-group-id` – Utilisez ce paramètre pour afficher les détails d'un groupe de réplication spécifique. Si le groupe de réplication spécifié comprend plus d'un groupe de nœuds, les résultats obtenus sont regroupés par groupe de nœuds.
+ `--max-items` – Utilisez ce paramètre pour limiter le nombre de groupes de réplication répertoriés. La valeur de `--max-items` doit être comprise entre 20 et 100.
**Example**
Le code suivant répertorie les détails de 100 groupes de réplication maximum.
```
aws elasticache describe-replication-groups
```
Le code suivant répertorie les détails de `sample-repl-group`.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
Le code suivant répertorie les détails de `sample-repl-group`.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
Le code suivant répertorie les détails de 25 groupes de réplication maximum.
```
aws elasticache describe-replication-groups --max-items 25
```
Le résultat de cette opération doit ressembler à cet exemple (format JSON).
```
{
"ReplicationGroups": [
{
"Status": "available",
"Description": "test",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-001.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-002.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-003.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "rg-name.1abc4d.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "rg-name",
"AutomaticFailover": "enabled",
"SnapshottingClusterId": "rg-name-002",
"MemberClusters": [
"rg-name-001",
"rg-name-002",
"rg-name-003"
],
"PendingModifiedValues": {}
},
{
... some output omitted for brevity
}
]
}
```
Pour plus d'informations, consultez AWS CLI la ElastiCache rubrique dédiée[describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html).
# Afficher les détails d'un groupe de réplication (ElastiCache API)
Vous pouvez consulter les détails d'une réplication à l'aide de l' AWS CLI `DescribeReplicationGroups`opération. Utilisez les paramètres facultatifs suivants pour affiner la liste. Si les paramètres ne sont pas spécifiés, vous obtenez les détails de 100 groupes de réplication maximum.
**Paramètres facultatifs**
+ `ReplicationGroupId` – Utilisez ce paramètre pour afficher les détails d'un groupe de réplication spécifique. Si le groupe de réplication spécifié comprend plus d'un groupe de nœuds, les résultats obtenus sont regroupés par groupe de nœuds.
+ `MaxRecords` – Utilisez ce paramètre pour limiter le nombre de groupes de réplication répertoriés. La valeur de `MaxRecords` doit être comprise entre 20 et 100. La valeur par défaut est 100.
**Example**
Le code suivant répertorie les détails de 100 groupes de réplication maximum.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Le code suivant répertorie les détails de `myReplGroup`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Le code suivant affiche les détails de 25 clusters maximum.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&MaxRecords=25
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez la rubrique de référence sur les ElastiCache API[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html).
# Recherche des points de terminaison du groupe de réplication
Une application peut se connecter à n'importe quel nœud du groupe de réplication, à condition qu'elle dispose du point de terminaison DNS et du numéro de port de ce nœud. Selon que vous utilisez un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) ou un groupe de réplication Valkey ou Redis OSS (mode cluster activé), différents points de terminaison vous intéresseront.
**Valkey ou Redis OSS (mode cluster désactivé)**
*Les clusters Valkey ou Redis OSS (mode cluster désactivé) dotés de répliques ont trois types de points de terminaison : le point de *terminaison principal, le point de terminaison* du *lecteur et les points de terminaison* du nœud.* Le point de terminaison principal est un nom DNS qui est toujours résolu dans le nœud principal du cluster. Le point de terminaison principal n'est pas affecté par les changements apportés à votre cluster, tels que la promotion d'un réplica en lecture au rang de réplica principal. Pour l'activité d'écriture, il est préférable que vos applications se connectent au point de terminaison principal.
Un point de terminaison de lecteur répartira de manière égale les connexions entrantes vers le point de terminaison entre toutes les répliques de lecture d'un ElastiCache cluster. Des facteurs supplémentaires, comme le moment où l'application crée les connexions ou la façon dont l'application utilise ou réutilise les connexions, détermineront la distribution du trafic. Les points de terminaison du lecteur suivent les changements de cluster en temps réel au fur et à mesure que des réplicas sont ajoutés ou supprimés. Vous pouvez placer ElastiCache les multiples répliques de lecture de votre cluster Redis OSS dans différentes zones de AWS disponibilité (AZ) afin de garantir la haute disponibilité des points de terminaison des lecteurs.
**Note**
Un point de terminaison du lecteur n'est pas un équilibreur de charge. Il s'agit d'un enregistrement DNS qui se résoudra à une adresse IP de l'un des nœuds de réplica en mode round robin.
Pour l'activité de lecture, les applications peuvent également se connecter à n'importe quel nœud du cluster. Contrairement au point de terminaison principal, les points de terminaison des nœuds sont résolus dans des points de terminaison spécifiques. En cas de modification dans votre cluster, comme l'ajout ou la suppression d'un réplica, vous devez mettre à jour les points de terminaison des nœuds de votre application.
**Valkey ou Redis OSS (mode cluster activé)**
Les clusters Valkey ou Redis OSS (mode cluster activé) avec des répliques, parce qu'ils comportent plusieurs partitions (API/CLI : groupes de nœuds), ce qui signifie qu'ils possèdent également plusieurs nœuds principaux, ont une structure de point de terminaison différente de celle des clusters Valkey ou Redis OSS (mode cluster désactivé). Valkey ou Redis OSS (mode cluster activé) possède un point de *terminaison de configuration* qui « connaît » tous les points de terminaison principaux et nœuds du cluster. Votre application se connecte au point de terminaison de configuration. Chaque fois que votre application écrit ou lit depuis le point de terminaison de configuration du cluster, Valkey et Redis OSS déterminent en arrière-plan à quelle partition appartient la clé et quel point de terminaison de cette partition utiliser. Ce processus est transparent pour votre application.
Vous pouvez trouver les points de terminaison d'un cluster à l'aide de la ElastiCache console AWS CLI, de ou de l' ElastiCache API.
**Recherche des points de terminaison du groupe de réplication**
Pour trouver les points de terminaison de votre groupe de réplication, consultez l'une des rubriques suivantes :
+ [Trouver les points de terminaison d'un cluster Valkey ou Redis OSS (mode cluster désactivé) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Recherche de points de terminaison pour un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Endpoints.md#Endpoints.Find.RedisCluster)
+ [Recherche des points de terminaison pour les groupes de réplication Valkey ou Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Recherche de points de terminaison pour les groupes de réplication (API) Valkey ou Redis OSS ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
# Modification d'un groupe de réplication
**Contraintes importantes**
Actuellement, ElastiCache prend en charge des modifications limitées d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé), par exemple la modification de la version du moteur à l'aide de l'opération API (`ModifyReplicationGroup`CLI :`modify-replication-group`). Vous pouvez modifier le nombre de partitions (groupes de nœuds) dans un cluster Valkey ou Redis OSS (mode cluster activé) à l'aide de l'opération API ([https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)CLI :). [https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html) Pour de plus amples informations, veuillez consulter [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md).
Les autres modifications apportées à un cluster Valkey ou Redis OSS (mode cluster activé) nécessitent que vous créiez un cluster avec le nouveau cluster incorporant les modifications.
Vous pouvez mettre à niveau les clusters et groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) et Valkey ou Redis OSS (mode cluster activé) vers des versions de moteur plus récentes. Cependant, vous ne pouvez pas mettre à niveau vers des versions antérieures du moteur, sauf en supprimant le cluster existant ou le groupe de réplication et en le créant à nouveau. Pour de plus amples informations, veuillez consulter [Gestion des versions pour ElastiCache](VersionManagement.md).
Vous pouvez mettre à niveau un cluster existant ElastiCache pour Valkey ou Redis OSS qui utilise le mode cluster désactivé pour utiliser le mode cluster activé, à l'aide de la console, de l'[ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)API ou de la commande [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)CLI, comme indiqué dans l'exemple ci-dessous. Vous pouvez également suivre les étapes décrites dans [Modifying cluster mode](modify-cluster-mode.md) (Modification du mode cluster).
Vous pouvez modifier les paramètres d'un cluster Valkey ou Redis OSS (mode cluster désactivé) à l'aide de la ElastiCache console, de l' AWS CLI API ou de l' ElastiCache API. Actuellement, ElastiCache prend en charge un nombre limité de modifications sur un groupe de réplication Valkey ou Redis OSS (mode cluster activé). D'autres modifications nécessitent que vous créiez une sauvegarde du groupe de réplication actuel, puis que vous utilisiez cette sauvegarde pour démarrer un nouveau groupe de réplication Valkey ou Redis OSS (mode cluster activé).
**Topics**
+ [À l'aide du AWS Management Console](#Replication.Modify.CON)
+ [À l'aide du AWS CLI](#Replication.Modify.CLI)
+ [Utilisation de l' ElastiCache API](#Replication.Modify.API)
## À l'aide du AWS Management Console
Pour modifier un cluster Valkey ou Redis OSS (mode cluster désactivé), consultez. [Modification d'un ElastiCache cluster](Clusters.Modify.md)
## À l'aide du AWS CLI
Voici des AWS CLI exemples de `modify-replication-group` commande. Vous pouvez utiliser la même commande pour apporter d'autres modifications à un groupe de réplication.
**Activez le Multi-AZ sur un groupe de réplication Valkey ou Redis OSS existant :**
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--multi-az-enabled = true
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--multi-az-enabled
```
**Modifier le mode cluster de désactivé à activé :**
Pour modifier le mode cluster de *Désactivé* à *Activé*, vous devez d'abord définir le mode cluster comme *Compatible*. Le mode de compatibilité permet à vos clients Valkey ou Redis OSS de se connecter tant avec le mode cluster activé qu’avec le mode cluster désactivé. *Après avoir migré tous les clients Valkey ou Redis OSS pour utiliser le mode cluster activé, vous pouvez terminer la configuration du mode cluster et définir le mode cluster sur activé.*
Pour Linux, macOS ou Unix :
Définissez le mode cluster sur *Compatible*.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cache-parameter-group-name myParameterGroupName \
--cluster-mode compatible
```
Définissez le mode cluster sur *Activé*.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cluster-mode enabled
```
Pour Windows :
Définissez le mode cluster sur *Compatible*.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cache-parameter-group-name myParameterGroupName ^
--cluster-mode compatible
```
Définissez le mode cluster sur *Activé*.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cluster-mode enabled
```
Pour plus d'informations sur la AWS CLI `modify-replication-group` commande, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) la section [Modification du mode cluster]() dans le *Guide de l'ElastiCache utilisateur de Redis OSS*.
## Utilisation de l' ElastiCache API
L'opération ElastiCache d'API suivante active le multi-AZ sur un groupe de réplication Valkey ou Redis OSS existant. Vous pouvez utiliser la même opération pour apporter d'autres modifications à un groupe de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&AutomaticFailoverEnabled=true
&Mutli-AZEnabled=true
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Pour plus d'informations sur le `ModifyReplicationGroup` fonctionnement de l' ElastiCache API, consultez[ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html).
# Suppression d'un groupe de réplication
Si vous n'avez plus besoin d'un de vos clusters avec réplicas (appelés *groupes de réplication* dans l'API/CLI), vous pouvez le supprimer. Lorsque vous supprimez un groupe de réplication, tous ElastiCache les nœuds de ce groupe sont supprimés.
Une fois que vous avez commencé cette opération, elle ne peut être ni interrompue ni annulée.
**Avertissement**
Lorsque vous supprimez un ElastiCache cluster Redis OSS, vos instantanés manuels sont conservés. Vous avez également la possibilité de créer un instantané final avant la suppression du cluster. Les instantanés mis en cache automatiquement ne sont pas conservés.
`CreateSnapshot`une autorisation est requise pour créer un instantané final. Sans cette autorisation, l'appel d'API échouera avec une `Access Denied` exception.
## Suppression d'un groupe de réplication (console)
Pour supprimer un cluster qui contient des réplicas, consultez [Supprimer un cluster dans ElastiCache](Clusters.Delete.md).
## Suppression d'un groupe de réplication (AWS CLI)
Utilisez la commande [delete-replication-group](https://docs.aws.amazon.com/AmazonElastiCache/latest/CommandLineReference/CLIReference-cmd-DeleteReplicationGroup.html) pour supprimer un groupe de réplication.
```
aws elasticache delete-replication-group --replication-group-id my-repgroup
```
Une invite vous demande de confirmer votre décision. Entrez *y* (oui) pour démarrer l'opération immédiatement. Une fois le processus entamé, il est irréversible.
```
After you begin deleting this replication group, all of its nodes will be deleted as well.
Are you sure you want to delete this replication group? [Ny]y
REPLICATIONGROUP my-repgroup My replication group deleting
```
## Supprimer un groupe de réplication (ElastiCache API)
Appelez [DeleteReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteReplicationGroup.html) avec le paramètre `ReplicationGroup`.
**Example**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteReplicationGroup
&ReplicationGroupId=my-repgroup
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
**Note**
Si vous définissez le paramètre `RetainPrimaryCluster` sur `true`, tous les réplicas en lecture seront supprimés, mais le cluster principal sera conservé.
# Modification du nombre de réplicas
Vous pouvez augmenter ou diminuer dynamiquement le nombre de répliques de lecture dans votre groupe de réplication Valkey ou Redis OSS à l'aide de l'API AWS Management Console, de ou de l' AWS CLI API. ElastiCache Si votre groupe de réplication est un groupe de réplication Valkey ou Redis OSS (mode cluster activé), vous pouvez choisir les partitions (groupes de nœuds) pour augmenter ou diminuer le nombre de répliques.
Pour modifier dynamiquement le nombre de répliques dans votre groupe de réplication, choisissez l'opération adaptée à votre situation dans le tableau suivant.
| Pour ce faire | Pour Valkey ou Redis OSS (mode cluster activé) | Pour Valkey ou Redis OSS (mode cluster désactivé) |
| --- | --- | --- |
| Ajouter des réplicas | [Augmentation du nombre de réplicas dans une partition](increase-replica-count.md) | [Augmentation du nombre de réplicas dans une partition](increase-replica-count.md) [Ajouter une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé)](Replication.AddReadReplica.md) |
| Supprimer des réplicas | [Diminution du nombre de réplicas dans une partition](decrease-replica-count.md) | [Diminution du nombre de réplicas dans une partition](decrease-replica-count.md) [Suppression d'une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé)](Replication.RemoveReadReplica.md) |
# Augmentation du nombre de réplicas dans une partition
Vous pouvez augmenter le nombre de répliques dans une partition Valkey ou Redis OSS (mode cluster activé) ou dans un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) jusqu'à un maximum de cinq. Vous pouvez le faire à l'aide de AWS Management Console, de AWS CLI, ou de l' ElastiCache API.
**Topics**
+ [À l'aide du AWS Management Console](#increase-replica-count-con)
+ [À l'aide du AWS CLI](#increase-replica-count-cli)
+ [Utilisation de l' ElastiCache API](#increase-replica-count-api)
## À l'aide du AWS Management Console
La procédure suivante utilise la console pour augmenter le nombre de répliques dans un groupe de réplication Valkey ou Redis OSS (mode cluster activé).
**Pour augmenter le nombre de répliques dans les partitions**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**, puis choisissez le nom du groupe de réplication auquel vous souhaitez ajouter des répliques.
1. Cochez la case correspondant à chaque partition à laquelle vous souhaitez ajouter des réplicas.
1. Choisissez **Add replicas (Ajouter des réplicas)**.
1. Renseignez la page **Add Replicas to Shards (Ajouter des réplicas à des partitions)** :
+ Dans **New number of replicas/shard (Nouveau nombre de réplicas par partition)**, saisissez le nombre de réplicas que doivent avoir chacune des partitions sélectionnées. Cette valeur doit être supérieure ou égale à la valeur de **Current Number of Replicas per shard (Nombre actuel de réplicas par partition)**, et inférieure ou égale à cinq. Nous vous recommandons d'utiliser au moins deux réplicas.
+ Pour les **zones de disponibilité**, sélectionnez **Aucune préférence** pour avoir ElastiCache choisi une zone de disponibilité pour chaque nouvelle réplique, ou **Spécifier les zones de disponibilité** pour choisir une zone de disponibilité pour chaque nouvelle réplique.
Si vous choisissez **Specify Availability Zones (Spécifier les zones de disponibilité)**, spécifiez une zone de disponibilité à l'aide de la liste pour chaque nouveau réplica.
1. Choisissez **Add (Ajouter)** pour ajouter les réplicas ou **Cancel (Annuler)** pour annuler l'opération.
## À l'aide du AWS CLI
Pour augmenter le nombre de répliques dans une partition Valkey ou Redis OSS, utilisez la `increase-replica-count` commande avec les paramètres suivants :
+ `--replication-group-id` – Obligatoire. Identifie le groupe de réplication dans lequel vous souhaitez augmenter le nombre de réplicas.
+ `--apply-immediately` ou `--no-apply-immediately` – Obligatoire. Spécifie si le nombre de réplicas doit être augmenté immédiatement (`--apply-immediately`) ou lors du prochain créneau de maintenance (`--no-apply-immediately`). Actuellement, `--no-apply-immediately` n'est pas pris en charge.
+ `--new-replica-count` : facultatif. Spécifie le nombre de nœuds de réplica que vous souhaitez avoir une fois l'opération terminée, dans la limite de 5 maximum. Utilisez ce paramètre pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) où il n'existe qu'un seul groupe de nœuds ou pour les groupes Valkey ou Redis OSS (mode cluster activé), ou pour lesquels vous souhaitez que tous les groupes de nœuds aient le même nombre de répliques. Si cette valeur n'est pas supérieure au nombre de réplicas actuel du groupe de nœuds, l'appel échoue avec une exception.
+ `--replica-configuration` : facultatif. Vous permet de définir le nombre de réplicas et de zones de disponibilité pour chaque groupe de nœuds indépendamment. Utilisez ce paramètre pour les groupes Valkey ou Redis OSS (mode cluster activé) dans lesquels vous souhaitez configurer chaque groupe de nœuds indépendamment.
`--replica-configuration` comporte trois chiffre facultatifs :
+ `NodeGroupId` : ID de quatre chiffres pour le groupe de nœud que vous configurez. Pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé), l'ID de partition est toujours. `0001` Pour trouver l'ID d'un groupe de nœuds (partition) Valkey ou Redis OSS (mode cluster activé), consultez. [Recherche de l'ID d'une partition](Shards.md#shard-find-id)
+ `NewReplicaCount` – Nombre de réplicas que vous souhaitez dans ce groupe de nœuds à la fin de cette opération. La valeur doit être supérieure au nombre actuel de réplicas, dans la limite de cinq maximum. Si cette valeur n'est pas supérieure au nombre de réplicas actuel du groupe de nœuds, l'appel échoue avec une exception.
+ `PreferredAvailabilityZones` – Liste de chaînes `PreferredAvailabilityZone` qui spécifie dans quelles zones de disponibilité les nœuds des groupes de réplication doivent se trouver. Le nombre de valeurs `PreferredAvailabilityZone` doit être égal à la valeur de `NewReplicaCount` plus 1 afin de prendre en compte le nœud principal. Si ce membre de `--replica-configuration` est omis, ElastiCache pour Redis OSS, il choisit la zone de disponibilité pour chacune des nouvelles répliques.
**Important**
Vous devez inclure le paramètre `--new-replica-count` ou le paramètre `--replica-configuration`, mais pas les deux, dans votre appel.
**Example**
L'exemple suivant fait passer à 3 le nombre de réplicas du groupe de réplication `sample-repl-group`. À la fin de cet exemple, il y a trois réplicas dans chaque groupe de nœuds. Ce numéro s'applique qu'il s'agisse d'un groupe Valkey ou Redis OSS (mode cluster désactivé) avec un seul groupe de nœuds ou d'un groupe Valkey ou Redis OSS (mode cluster activé) avec plusieurs groupes de nœuds.
Pour Linux, macOS ou Unix :
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--new-replica-count 3 \
--apply-immediately
```
Pour Windows :
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 3 ^
--apply-immediately
```
L'exemple suivant fait passer le nombre de réplicas du groupe de réplication `sample-repl-group` à la valeur spécifiée pour les deux groupes de nœuds spécifiés. Étant donné qu'il existe plusieurs groupes de nœuds, il s'agit d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé). Lorsque vous spécifiez le paramètre `PreferredAvailabilityZones` facultatif, le nombre de zones de disponibilité indiqué doit correspondre à la valeur de `NewReplicaCount` plus 1. Cette approche prend en compte le nœud principal pour le groupe identifié par `NodeGroupId`.
Pour Linux, macOS ou Unix :
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--replica-configuration \
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c,us-east-1b \
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c,us-east-1c \
--apply-immediately
```
Pour Windows :
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--replica-configuration ^
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c,us-east-1b ^
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c,us-east-1c \
--apply-immediately
```
Pour plus d'informations sur l'augmentation du nombre de répliques à l'aide de la CLI, consultez le [increase-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-replica-count.html)manuel *Amazon ElastiCache Command Line Reference*.
## Utilisation de l' ElastiCache API
Pour augmenter le nombre de répliques dans une partition Valkey ou Redis OSS, utilisez l'`IncreaseReplicaCount`action avec les paramètres suivants :
+ `ReplicationGroupId` – Obligatoire. Identifie le groupe de réplication dans lequel vous souhaitez augmenter le nombre de réplicas.
+ `ApplyImmediately` – Obligatoire. Spécifie si le nombre de réplicas doit être augmenté immédiatement (`ApplyImmediately=True`) ou lors du prochain créneau de maintenance (`ApplyImmediately=False`). Actuellement, `ApplyImmediately=False` n'est pas pris en charge.
+ `NewReplicaCount` : facultatif. Spécifie le nombre de nœuds de réplica que vous souhaitez avoir une fois l'opération terminée, dans la limite de 5 maximum. Utilisez ce paramètre pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé) où il n'existe qu'un seul groupe de nœuds, ou pour les groupes Valkey ou Redis OSS (mode cluster activé) où vous souhaitez que tous les groupes de nœuds aient le même nombre de répliques. Si cette valeur n'est pas supérieure au nombre de réplicas actuel du groupe de nœuds, l'appel échoue avec une exception.
+ `ReplicaConfiguration` : facultatif. Vous permet de définir le nombre de réplicas et de zones de disponibilité pour chaque groupe de nœuds indépendamment. Utilisez ce paramètre pour les groupes Valkey ou Redis OSS (mode cluster activé) dans lesquels vous souhaitez configurer chaque groupe de nœuds indépendamment.
`ReplicaConfiguraion` comporte trois chiffre facultatifs :
+ `NodeGroupId` : ID de quatre chiffres pour le groupe de nœud que vous configurez. Pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé), l'ID du groupe de nœuds (partition) est toujours. `0001` Pour trouver l'ID d'un groupe de nœuds (partition) Valkey ou Redis OSS (mode cluster activé), consultez. [Recherche de l'ID d'une partition](Shards.md#shard-find-id)
+ `NewReplicaCount` – Nombre de réplicas que vous souhaitez dans ce groupe de nœuds à la fin de cette opération. La valeur doit être supérieure au nombre actuel de réplicas, dans la limite de cinq maximum. Si cette valeur n'est pas supérieure au nombre de réplicas actuel du groupe de nœuds, l'appel échoue avec une exception.
+ `PreferredAvailabilityZones` – Liste de chaînes `PreferredAvailabilityZone` qui spécifie dans quelles zones de disponibilité les nœuds des groupes de réplication doivent se trouver. Le nombre de valeurs `PreferredAvailabilityZone` doit être égal à la valeur de `NewReplicaCount` plus 1 afin de prendre en compte le nœud principal. Si ce membre de `ReplicaConfiguration` est omis, ElastiCache pour Redis OSS, il choisit la zone de disponibilité pour chacune des nouvelles répliques.
**Important**
Vous devez inclure le paramètre `NewReplicaCount` ou le paramètre `ReplicaConfiguration`, mais pas les deux, dans votre appel.
**Example**
L'exemple suivant fait passer à 3 le nombre de réplicas du groupe de réplication `sample-repl-group`. À la fin de cet exemple, il y a trois réplicas dans chaque groupe de nœuds. Ce numéro s'applique qu'il s'agisse d'un groupe Valkey ou Redis OSS (mode cluster désactivé) avec un seul groupe de nœuds, ou d'un groupe Valkey ou Redis OSS (mode cluster activé) avec plusieurs groupes de nœuds.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=3
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
L'exemple suivant fait passer le nombre de réplicas du groupe de réplication `sample-repl-group` à la valeur spécifiée pour les deux groupes de nœuds spécifiés. Étant donné qu'il existe plusieurs groupes de nœuds, il s'agit d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé). Lorsque vous spécifiez le paramètre `PreferredAvailabilityZones` facultatif, le nombre de zones de disponibilité indiqué doit correspondre à la valeur de `NewReplicaCount` plus 1. Cette approche prend en compte le nœud principal pour le groupe identifié par `NodeGroupId`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1c
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=3
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-east-1c
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations sur l'augmentation du nombre de répliques à l'aide de l'API, consultez [IncreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_IncreaseReplicaCount.html)le *Amazon ElastiCache API Reference*.
# Diminution du nombre de réplicas dans une partition
Vous pouvez réduire le nombre de répliques dans une partition pour Valkey ou Redis OSS (mode cluster activé), ou dans un groupe de réplication pour Valkey ou Redis OSS (mode cluster désactivé) :
+ Pour Valkey ou Redis OSS (mode cluster désactivé), vous pouvez réduire le nombre de répliques à un si le mode multi-AZ est activé, et à zéro s'il n'est pas activé.
+ Pour Valkey ou Redis OSS (mode cluster activé), vous pouvez réduire le nombre de répliques à zéro. Cependant, vous ne pouvez pas basculer vers un réplica en cas d'échec du nœud principal.
Vous pouvez utiliser l' AWS Management Console API AWS CLI ou l' ElastiCache API pour réduire le nombre de répliques dans un groupe de nœuds (partition) ou un groupe de réplication.
**Topics**
+ [En utilisant le AWS Management Console](#decrease-replica-count-con)
+ [En utilisant le AWS CLI](#decrease-replica-count-cli)
+ [Utilisation de l' ElastiCache API](#decrease-replica-count-api)
## En utilisant le AWS Management Console
La procédure suivante utilise la console pour diminuer le nombre de répliques dans un groupe de réplication Valkey ou Redis OSS (mode cluster activé).
**Pour réduire le nombre de répliques dans une partition Valkey ou Redis OSS**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey** ou **Redis OSS**, puis choisissez le nom du groupe de réplication dont vous souhaitez supprimer les répliques.
1. Cochez la case correspondant à chaque partition dont vous souhaitez supprimer un nœud de réplica.
1. Choisissez **Delete replicas (Supprimer des réplicas)**.
1. Renseignez la page **Delete Replicas from Shards (Supprimer des réplicas de partitions)** :
1. Dans **New number of replicas/shard (Nouveau nombre de réplicas par partition)**, saisissez le nombre de réplicas que doivent avoir chacune des partitions sélectionnées. Cette valeur doit être supérieure ou égale à 1. Nous vous recommandons d'utiliser au moins deux réplicas par partition.
1. Choisissez **Delete (Supprimer)** pour supprimer les réplicas ou **Cancel (Annuler)** pour annuler l'opération.
**Important**
Si vous ne spécifiez pas les nœuds de réplication à supprimer, ElastiCache Redis OSS sélectionne automatiquement les nœuds de réplication à supprimer. Ce faisant, ElastiCache Redis OSS tente de conserver l'architecture multi-AZ de votre groupe de réplication, puis de conserver les répliques avec un délai de réplication minimal par rapport au principal.
Vous ne pouvez pas supprimer le nœud primaire ou le nœud maître dans un groupe de réplication. Si vous spécifiez un nœud principal afin qu'il soit supprimé, l'opération échoue et une erreur indique que le nœud principal a été sélectionné pour être supprimé.
## En utilisant le AWS CLI
Pour réduire le nombre de répliques dans une partition Valkey ou Redis OSS, utilisez la `decrease-replica-count` commande avec les paramètres suivants :
+ `--replication-group-id` – Obligatoire. Identifie le groupe de réplication dans lequel vous souhaitez diminuer le nombre de réplicas.
+ `--apply-immediately` ou `--no-apply-immediately` : obligatoire. Spécifie si le nombre de réplicas doit être diminué immédiatement (`--apply-immediately`) ou lors du prochain créneau de maintenance (`--no-apply-immediately`). Actuellement, `--no-apply-immediately` n'est pas pris en charge.
+ `--new-replica-count` : facultatif. Spécifie le nombre de nœuds de réplica souhaité. La valeur de `--new-replica-count` doit être une valeur valide inférieure au nombre de réplicas actuel dans les groupes de nœuds. Pour consulter les valeurs minimum autorisées, consultez [Diminution du nombre de réplicas dans une partition](#decrease-replica-count). Si la valeur de `--new-replica-count` ne répond pas à cette exigence, l'appel échoue.
+ `--replicas-to-remove` : facultatif. Contient une liste de nœuds IDs spécifiant les nœuds répliques à supprimer.
+ `--replica-configuration` : facultatif. Vous permet de définir le nombre de réplicas et de zones de disponibilité pour chaque groupe de nœuds indépendamment. Utilisez ce paramètre pour les groupes Valkey ou Redis OSS (mode cluster activé) dans lesquels vous souhaitez configurer chaque groupe de nœuds indépendamment.
`--replica-configuration` comporte trois chiffre facultatifs :
+ `NodeGroupId` : ID de quatre chiffres pour le groupe de nœud que vous configurez. Pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé), l'ID de partition est toujours. `0001` Pour trouver l'ID d'un groupe de nœuds (partition) Valkey ou Redis OSS (mode cluster activé), consultez. [Recherche de l'ID d'une partition](Shards.md#shard-find-id)
+ `NewReplicaCount` : paramètre facultatif qui spécifie le nombre de nœuds de réplica souhaité. La valeur de `NewReplicaCount` doit être une valeur valide inférieure au nombre de réplicas actuel dans les groupes de nœuds. Pour consulter les valeurs minimum autorisées, consultez [Diminution du nombre de réplicas dans une partition](#decrease-replica-count). Si la valeur de `NewReplicaCount` ne répond pas à cette exigence, l'appel échoue.
+ `PreferredAvailabilityZones` : liste de chaînes `PreferredAvailabilityZone` qui spécifie dans quelles zones de disponibilité les nœuds des groupes de réplication doivent se trouver. Le nombre de valeurs `PreferredAvailabilityZone` doit être égal à la valeur de `NewReplicaCount` plus 1 afin de prendre en compte le nœud principal. Si ce membre de `--replica-configuration` est omis, ElastiCache pour Redis OSS, il choisit la zone de disponibilité pour chacune des nouvelles répliques.
**Important**
Vous devez uniquement inclure l'un des paramètres suivants : `--new-replica-count`, `--replicas-to-remove` ou `--replica-configuration`.
**Example**
L'exemple suivant utilise `--new-replica-count` pour abaisser à 1 le nombre de réplicas du groupe de réplication `sample-repl-group`. À la fin de cet exemple, il y a un réplica dans chaque groupe de nœuds. Ce numéro s'applique qu'il s'agisse d'un groupe Valkey ou Redis OSS (mode cluster désactivé) avec un seul groupe de nœuds ou d'un groupe Valkey ou Redis OSS (mode cluster activé) avec plusieurs groupes de nœuds.
Pour Linux, macOS ou Unix :
```
aws elasticache decrease-replica-count
--replication-group-id sample-repl-group \
--new-replica-count 1 \
--apply-immediately
```
Pour Windows :
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 1 ^
--apply-immediately
```
L'exemple suivant diminue le nombre de réplicas du groupe de réplication `sample-repl-group` en supprimant deux réplicas spécifiés (`0001` et `0003`) du groupe de nœuds.
Pour Linux, macOS ou Unix :
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replicas-to-remove 0001,0003 \
--apply-immediately
```
Pour Windows :
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replicas-to-remove 0001,0003 \
--apply-immediately
```
L'exemple suivant utilise `--replica-configuration` pour diminuer le nombre de réplicas du groupe de réplication `sample-repl-group` à la valeur spécifiée pour les deux groupes de nœuds spécifiés. Étant donné qu'il existe plusieurs groupes de nœuds, il s'agit d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé). Lorsque vous spécifiez le paramètre `PreferredAvailabilityZones` facultatif, le nombre de zones de disponibilité indiqué doit correspondre à la valeur de `NewReplicaCount` plus 1. Cette approche prend en compte le nœud principal pour le groupe identifié par `NodeGroupId`.
Pour Linux, macOS ou Unix :
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replica-configuration \
NodeGroupId=0001,NewReplicaCount=1,PreferredAvailabilityZones=us-east-1a,us-east-1c \
NodeGroupId=0003,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
--apply-immediately
```
Pour Windows :
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replica-configuration ^
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c ^
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
--apply-immediately
```
Pour plus d'informations sur la réduction du nombre de répliques à l'aide de la CLI, consultez le [decrease-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-replica-count.html)manuel *Amazon ElastiCache Command Line Reference*.
## Utilisation de l' ElastiCache API
Pour réduire le nombre de répliques dans une partition Valkey ou Redis OSS, utilisez l'`DecreaseReplicaCount`action avec les paramètres suivants :
+ `ReplicationGroupId` – Obligatoire. Identifie le groupe de réplication dans lequel vous souhaitez diminuer le nombre de réplicas.
+ `ApplyImmediately` : obligatoire. Spécifie si le nombre de réplicas doit être diminué immédiatement (`ApplyImmediately=True`) ou lors du prochain créneau de maintenance (`ApplyImmediately=False`). Actuellement, `ApplyImmediately=False` n'est pas pris en charge.
+ `NewReplicaCount` : facultatif. Spécifie le nombre de nœuds de réplica souhaité. La valeur de `NewReplicaCount` doit être une valeur valide inférieure au nombre de réplicas actuel dans les groupes de nœuds. Pour consulter les valeurs minimum autorisées, consultez [Diminution du nombre de réplicas dans une partition](#decrease-replica-count). Si la valeur de `--new-replica-count` ne répond pas à cette exigence, l'appel échoue.
+ `ReplicasToRemove` : facultatif. Contient une liste de nœuds IDs spécifiant les nœuds répliques à supprimer.
+ `ReplicaConfiguration` : facultatif. Contient une liste de groupes de nœuds qui vous permet de définir le nombre de réplicas et de zones de disponibilité pour chaque groupe de nœuds indépendamment. Utilisez ce paramètre pour les groupes Valkey ou Redis OSS (mode cluster activé) dans lesquels vous souhaitez configurer chaque groupe de nœuds indépendamment.
`ReplicaConfiguraion` comporte trois chiffre facultatifs :
+ `NodeGroupId` : ID de quatre chiffres pour le groupe de nœud que vous configurez. Pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé), l'ID du groupe de nœuds est toujours. `0001` Pour trouver l'ID d'un groupe de nœuds (partition) Valkey ou Redis OSS (mode cluster activé), consultez. [Recherche de l'ID d'une partition](Shards.md#shard-find-id)
+ `NewReplicaCount` : nombre de réplicas que vous souhaitez dans ce groupe de nœuds à la fin de cette opération. La valeur doit être inférieure au nombre actuel de réplicas et être de 1 minimum si l'option Multi-AZ est activée, ou de 0 si cette option n'est pas activée. Si cette valeur n'est pas inférieure au nombre de réplicas actuel du groupe de nœuds, l'appel échoue avec une exception.
+ `PreferredAvailabilityZones` : liste de chaînes `PreferredAvailabilityZone` qui spécifie dans quelles zones de disponibilité les nœuds des groupes de réplication doivent se trouver. Le nombre de valeurs `PreferredAvailabilityZone` doit être égal à la valeur de `NewReplicaCount` plus 1 afin de prendre en compte le nœud principal. Si ce membre de `ReplicaConfiguration` est omis, ElastiCache pour Redis OSS, il choisit la zone de disponibilité pour chacune des nouvelles répliques.
**Important**
Vous devez uniquement inclure l'un des paramètres suivants : `NewReplicaCount`, `ReplicasToRemove` ou `ReplicaConfiguration`.
**Example**
L'exemple suivant utilise `NewReplicaCount` pour abaisser à 1 le nombre de réplicas du groupe de réplication `sample-repl-group`. À la fin de cet exemple, il y a un réplica dans chaque groupe de nœuds. Ce numéro s'applique qu'il s'agisse d'un groupe Valkey ou Redis OSS (mode cluster désactivé) avec un seul groupe de nœuds ou d'un groupe Valkey ou Redis OSS (mode cluster activé) avec plusieurs groupes de nœuds.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=1
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
L'exemple suivant diminue le nombre de réplicas du groupe de réplication `sample-repl-group` en supprimant deux réplicas spécifiés (`0001` et `0003`) du groupe de nœuds.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicasToRemove.ReplicaToRemove.1=0001
&ReplicasToRemove.ReplicaToRemove.2=0003
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
L'exemple suivant utilise `ReplicaConfiguration` pour diminuer le nombre de réplicas du groupe de réplication `sample-repl-group` à la valeur spécifiée pour les deux groupes de nœuds spécifiés. Étant donné qu'il existe plusieurs groupes de nœuds, il s'agit d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé). Lorsque vous spécifiez le paramètre `PreferredAvailabilityZones` facultatif, le nombre de zones de disponibilité indiqué doit correspondre à la valeur de `NewReplicaCount` plus 1. Cette approche prend en compte le nœud principal pour le groupe identifié par `NodeGroupId`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=1
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1c
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations sur la réduction du nombre de répliques à l'aide de l'API, consultez [DecreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DecreaseReplicaCount.html)le *Amazon ElastiCache API Reference*.
# Ajouter une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé)
Les informations de la rubrique suivante s'appliquent uniquement aux groupes de réplication Valkey ou Redis OSS (mode cluster désactivé).
À mesure que la charge de lecture augmente, vous pouvez avoir besoin de répartir ces lectures sur plusieurs nœuds et réduire la charge sur chaque nœud individuellement. Dans cette rubrique, vous découvrirez comment ajouter une réplique en lecture à un cluster Valkey ou Redis OSS (mode cluster désactivé).
Un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) peut avoir un maximum de cinq répliques en lecture. Si vous essayez d'ajouter un réplica en lecture à un groupe de réplication qui en contient déjà cinq, l'opération échoue.
Pour plus d'informations sur l'ajout de répliques à un groupe de réplication Valkey ou Redis OSS (mode cluster activé), consultez ce qui suit :
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md)
+ [Augmentation du nombre de réplicas dans une partition](increase-replica-count.md)
Vous pouvez ajouter une réplique en lecture à un cluster Valkey ou Redis OSS (mode cluster désactivé) à l'aide de la ElastiCache console, de l'API ou de l' AWS CLI API. ElastiCache
**Rubriques en relation**
+ [Ajouter des nœuds à un ElastiCache cluster](Clusters.AddNode.md)
+ [Ajout d'un réplica en lecture à un groupe de réplication (AWS CLI)](#Replication.AddReadReplica.CLI)
+ [Ajout d'un réplica en lecture à un groupe de réplication à l'aide de l'API](#Replication.AddReadReplica.API)
## Ajout d'un réplica en lecture à un groupe de réplication (AWS CLI)
Pour ajouter une réplique en lecture à un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé), utilisez la AWS CLI `create-cache-cluster` commande, avec le paramètre `--replication-group-id` pour spécifier le groupe de réplication auquel ajouter le cluster (nœud).
L'exemple suivant crée le cluster `my-read replica` et l'ajoute au groupe de réplication `my-replication-group`. Les types de nœud, les groupes de paramètres, les groupes de sécurité, le créneau de maintenance et les autres paramètres du réplica en lecture seront les mêmes que ceux des autres nœuds dans `my-replication-group`.
Pour Linux, macOS ou Unix :
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-read-replica \
--replication-group-id my-replication-group
```
Pour Windows :
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-read-replica ^
--replication-group-id my-replication-group
```
Pour plus d'informations sur l'ajout d'une réplique en lecture à l'aide de la CLI, consultez [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html) le manuel *Amazon ElastiCache Command Line Reference.*
## Ajout d'un réplica en lecture à un groupe de réplication à l'aide de l'API
Pour ajouter une réplique en lecture à un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé), utilisez l' ElastiCache `CreateCacheCluster`opération, avec le paramètre `ReplicationGroupId` pour spécifier le groupe de réplication auquel ajouter le cluster (nœud).
L'exemple suivant crée le cluster `myReadReplica` et l'ajoute au groupe de réplication `myReplicationGroup`. Les types de nœud, les groupes de paramètres, les groupes de sécurité, le créneau de maintenance et les autres paramètres du réplica en lecture seront les mêmes que ceux des autres nœuds `myReplicationGroup`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReadReplica
&ReplicationGroupId=myReplicationGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations sur l'ajout d'une réplique en lecture à l'aide de l'API, consultez [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html) le *Amazon ElastiCache API Reference.*
# Suppression d'une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé)
Les informations de la rubrique suivante s'appliquent uniquement aux groupes de réplication Valkey ou Redis OSS (mode cluster désactivé).
À mesure que le trafic de lecture sur votre groupe de réplication Valkey ou Redis OSS change, vous souhaiterez peut-être ajouter ou supprimer des répliques de lecture. La suppression d'un nœud d'un groupe de réplication équivaut à supprimer un cluster, avec les restrictions suivantes :
+ Vous ne pouvez pas supprimer le réplica principal d'un groupe de réplication. Si vous souhaitez supprimer le réplica principal, procédez comme suit :
1. Promouvez un réplica en lecture en réplica principal. Pour plus d'informations sur la promotion d'un réplica en lecture en réplica principal, consultez [Promouvoir une réplique en lecture au statut principal, pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé)](Replication.PromoteReplica.md).
1. Supprimez l'ancienne réplica principal. Reportez-vous au point suivant pour consulter une restriction à cette méthode.
+ Si l'option Multi-AZ est activée sur un groupe de réplication, vous ne pouvez pas supprimer le dernier réplica en lecture de ce groupe de réplication. Dans ce cas, procédez comme suit :
1. Modifiez le groupe de réplication en désactivant Multi-AZ. Pour de plus amples informations, veuillez consulter [Modification d'un groupe de réplication](Replication.Modify.md).
1. Supprimez le réplica en lecture.
Vous pouvez supprimer une réplique en lecture d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à l'aide de la ElastiCache console, du AWS CLI for ElastiCache ou de l' ElastiCache API.
Pour savoir comment supprimer un cluster d'un groupe de réplication Valkey ou Redis OSS, consultez ce qui suit :
+ [En utilisant le AWS Management Console](Clusters.Delete.md#Clusters.Delete.CON)
+ [Utilisation du AWS CLI pour supprimer un ElastiCache cluster](Clusters.Delete.md#Clusters.Delete.CLI)
+ [Utilisation de l' ElastiCache API](Clusters.Delete.md#Clusters.Delete.API)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md)
+ [Diminution du nombre de réplicas dans une partition](decrease-replica-count.md)
# Promouvoir une réplique en lecture au statut principal, pour les groupes de réplication Valkey ou Redis OSS (mode cluster désactivé)
Les informations de la rubrique suivante s'appliquent uniquement aux groupes de réplication Valkey ou Redis OSS (mode cluster désactivé).
Vous pouvez promouvoir une réplique de lecture Valkey ou Redis OSS (mode cluster désactivé) en tant que réplique principale à l'aide de l'API AWS Management Console, de ou de l' ElastiCache API. AWS CLI Vous ne pouvez pas promouvoir un réplica en lecture en réplica principal lorsque l'option Multi-AZ avec basculement automatique est activée sur le groupe de réplication . Pour faire d'une réplique Valkey ou Redis OSS (mode cluster désactivé) une réplique principale sur un groupe de réplication compatible multi-AZ, procédez comme suit :
1. Modifiez le groupe de réplication pour désactiver le mode Multi-AZ (pour cela, tous les clusters ne doivent pas obligatoirement se trouver dans la même zone de disponibilité). Pour de plus amples informations, veuillez consulter [Modification d'un groupe de réplication](Replication.Modify.md).
1. Promouvez le réplica en lecture en réplica principal.
1. Modifiez le groupe de réplication pour réactiver Multi-AZ.
Le mode multi-AZ n'est pas disponible sur les groupes de réplication exécutant Redis OSS 2.6.13 ou une version antérieure.
## À l'aide du AWS Management Console
La procédure suivante utilise la console pour promouvoir un nœud de réplica et nœud principal.
**Pour promouvoir un réplica en lecture en réplica principal (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Si le réplica que vous souhaitez promouvoir est membre d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) dans lequel le mode multi-AZ est activé, modifiez le groupe de réplication pour désactiver le mode multi-AZ avant de continuer. Pour de plus amples informations, veuillez consulter [Modification d'un groupe de réplication](Replication.Modify.md).
1. Choisissez **Valkey** ou **Redis OSS**, puis dans la liste des clusters, choisissez le groupe de réplication que vous souhaitez modifier. Ce groupe de réplication doit exécuter le moteur « Redis », et non le moteur « Clustered Redis », et doit avoir au moins 2 nœuds.
1. Dans la liste des nœuds, choisissez le nœud de réplica que vous souhaitez promouvoir en nœud principal, puis, dans **Actions**, choisissez **Promote (Promouvoir)**.
1. Dans la boîte de dialogue **Promote Read Replica (Promouvoir le réplica en lecture)**, exécutez l'une des actions suivantes :
1. Pour **Apply Immediately (Appliquer immédiatement)**, choisissez **Yes (Oui)** pour promouvoir immédiatement le réplica en lecture, ou **No (Non)** pour le promouvoir au créneau de maintenance suivant du cluster.
1. Choisissez **Promote** pour promouvoir le réplica en lecture ou **Cancel** pour annuler l'opération.
1. Si l'option Multi-AZ est activée pour le cluster avant que vous ne commenciez le processus de promotion, patientez jusqu'à ce que le statut du groupe de réplication soit **available (disponible)**, puis modifiez le cluster pour activer à nouveau Multi-AZ. Pour de plus amples informations, veuillez consulter [Modification d'un groupe de réplication](Replication.Modify.md).
## À l'aide du AWS CLI
Il est impossible de promouvoir un réplica en lecture en réplica principal si Multi-AZ est activé pour le groupe de réplication. Dans certains cas, le réplica que vous souhaitez promouvoir peut appartenir à un groupe de réplication pour lequel le mode Multi-AZ est activé. Dans ces cas, vous devez modifier le groupe de réplication pour pouvoir désactiver le mode Multi-AZ avant de continuer. Pour cela, tous les clusters ne doivent pas obligatoirement se trouver dans la même zone de disponibilité. Pour plus d'informations sur la modification d'un groupe de réplication, consultez [Modification d'un groupe de réplication](Replication.Modify.md).
La AWS CLI commande suivante modifie le groupe de réplication`sample-repl-group`, faisant de la réplique en lecture `my-replica-1` le principal du groupe de réplication.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id sample-repl-group \
--primary-cluster-id my-replica-1
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id sample-repl-group ^
--primary-cluster-id my-replica-1
```
Pour plus d'informations sur la modification d'un groupe de réplication, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) le manuel *Amazon ElastiCache Command Line Reference.*
## Utilisation de l' ElastiCache API
Il est impossible de promouvoir un réplica en lecture en réplica principal si Multi-AZ est activé pour le groupe de réplication. Dans certains cas, le réplica que vous souhaitez promouvoir peut appartenir à un groupe de réplication pour lequel le mode Multi-AZ est activé. Dans ces cas, vous devez modifier le groupe de réplication pour pouvoir désactiver le mode Multi-AZ avant de continuer. Pour cela, tous les clusters ne doivent pas obligatoirement se trouver dans la même zone de disponibilité. Pour plus d'informations sur la modification d'un groupe de réplication, consultez [Modification d'un groupe de réplication](Replication.Modify.md).
L'action d' ElastiCache API suivante modifie le groupe de réplication`myReplGroup`, faisant de la réplique en lecture `myReplica-1` le principal du groupe de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ReplicationGroupId=myReplGroup
&PrimaryClusterId=myReplica-1
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Pour plus d'informations sur la modification d'un groupe de réplication, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) le *Amazon ElastiCache API Reference.*
# Gestion de la maintenance des ElastiCache clusters
Chaque cluster a un créneau de maintenance hebdomadaire au cours duquel toutes les modifications systèmes seront appliquées. Avec Valkey et Redis OSS, les groupes de réplication ont le même créneau de maintenance hebdomadaire. Si vous ne spécifiez pas de fenêtre de maintenance préférée lorsque vous créez ou modifiez un cluster ou un groupe de réplication, ElastiCache assignez une fenêtre de maintenance de 60 minutes dans le créneau de maintenance de votre région, un jour de la semaine choisi au hasard.
Ce créneau de maintenance de 60 minutes est choisi de manière aléatoire sur un bloc horaire de 8 heures par région. Le tableau suivant répertorie pour les différentes régions les blocs de temps à partir desquels les créneaux de maintenance par défaut sont alloués. Vous pouvez choisir un créneau de maintenance préféré en dehors du créneau de maintenance de votre région.
| Code région | Nom de la région | Fenêtre de maintenance régionale |
| --- | --- | --- |
| ap-northeast-1 | Région Asie-Pacifique (Tokyo) | 13:00–21:00 UTC |
| ap-northeast-2 | Région Asie-Pacifique (Séoul) | 12:00–20:00 UTC |
| ap-northeast-3 | Région Asie-Pacifique (Osaka) | 12:00–20:00 UTC |
| ap-southeast-3 | Région Asie-Pacifique (Jakarta) | 14:00–22:00 UTC |
| ap-south-1 | Région Asie-Pacifique (Mumbai) | 17:30–01:30 UTC |
| ap-southeast-1 | Région Asie-Pacifique (Singapour) | 14:00–22:00 UTC |
| cn-north-1 | Région Chine (Beijing) | 14:00–22:00 UTC |
| cn-northwest-1 | Région Chine (Ningxia) | 14:00–22:00 UTC |
| ap-east-1 | Région Asie-Pacifique (Hong Kong) | 13:00–21:00 UTC |
| ap-southeast-2 | Région Asie-Pacifique (Sydney) | 12:00–20:00 UTC |
| eu-west-3 | Région Europe (Paris) | 23:59–07:29 UTC |
| af-south-1 | Région Afrique (Le Cap) | 13:00–21:00 UTC |
| eu-central-1 | Région Europe (Francfort) | 23:00–07:00 UTC |
| eu-west-1 | Région Europe (Irlande) | 22:00–06:00 UTC |
| eu-west-2 | Région Europe (Londres) | 23:00–07:00 UTC |
| me-south-1 | Middle East (Bahrain) Region | 13:00–21:00 UTC |
| me-central-1 | Région du Moyen-Orient (EAU) | 13:00–21:00 UTC |
| eu-south-1 | Europe (Milan) Region | 21:00–05:00 UTC |
| sa-east-1 | Région Amérique du Sud (São Paulo) | 01:00–09:00 UTC |
| us-east-1 | Région USA Est (Virginie du Nord) | 03:00–11:00 UTC |
| us-east-2 | Région USA Est (Ohio) | 04:00–12:00 UTC |
| us-gov-west-1 | AWS GovCloud (US) région | 06:00–14:00 UTC |
| us-west-1 | Région US West (N. California) | 06:00–14:00 UTC |
| us-west-2 | Région USA Ouest (Oregon) | 06:00–14:00 UTC |
**Modification de la fenêtre de maintenance de votre cluster ou de votre groupe de réplication**
Le créneau de maintenance doit intervenir au moment où l'utilisation est la plus faible et peut donc nécessiter d'être modifié de temps en temps. Vous pouvez modifier votre cluster ou groupe de réplication en spécifiant une plage de temps de 24 heures au cours de laquelle toutes les opérations de maintenance demandées doivent avoir lieu. Toute modification de cluster en suspens ou différé demandée doit avoir lieu au cours de cette période.
**Note**
Si vous souhaitez appliquer les modifications de type de nœud, mettez immédiatement à niveau le and/or moteur à l'aide de la AWS Management Console case « **Appliquer maintenant** ». Sinon, ces modifications seront appliquées au cours de votre prochaine fenêtre de maintenance planifiée. Pour utiliser l'API, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)ou [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html).
**En savoir plus**
Pour plus d'informations sur votre créneau de maintenance et le remplacement des nœuds, veuillez consulter :
+ [ElastiCache Maintenance](https://aws.amazon.com/elasticache/elasticache-maintenance/) : FAQ sur la maintenance et le remplacement des nœuds
+ [Remplacement de nœuds (Memcached)](CacheNodes.NodeReplacement-mc.md)—Gestion du remplacement des nœuds pour Memcached
+ [Modification d'un ElastiCache cluster](Clusters.Modify.md) — Modification du créneau de maintenance d'un cluster
+ [Remplacement de nœuds (Valkey et Redis OSS)](CacheNodes.NodeReplacement.md) — Gestion du remplacement des nœuds
+ [Modification d'un groupe de réplication](Replication.Modify.md) — Modification du créneau de maintenance d'un groupe de réplication
# Configuration des paramètres du moteur à l'aide de groupes de ElastiCache paramètres
Amazon ElastiCache utilise des paramètres pour contrôler les propriétés d'exécution de vos nœuds et clusters. Habituellement, les dernières versions de moteurs comprennent des paramètres supplémentaires pour prendre en charge une fonctionnalité plus récente. Pour les tableaux des paramètres Memcached, consultez. [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached) Pour les tableaux des paramètres Valkey et Redis OSS, consultez. [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis)
Bien entendu, certaines valeurs de paramètres telles que `maxmemory` sont déterminées par le type de nœud de et de moteur. Pour un tableau de ces valeurs de paramètres Memcached par type de nœud, consultez. [Paramètres propres au type de nœud Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached.NodeSpecific) Pour un tableau de ces valeurs de paramètres Valkey et Redis OSS par type de nœud, consultez. [Paramètres spécifiques au type de nœud Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific)
**Note**
Pour obtenir la liste des paramètres spécifiques à Memcached, consultez [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached).
**Topics**
+ [Gestion des paramètres dans ElastiCache](ParameterGroups.Management.md)
+ [Le groupe de paramètres du cache intègre des niveaux ElastiCache](ParameterGroups.Tiers.md)
+ [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md)
+ [Répertorier les groupes de ElastiCache paramètres par nom](ParameterGroups.ListingGroups.md)
+ [Lister les valeurs d'un groupe de ElastiCache paramètres](ParameterGroups.ListingValues.md)
+ [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md)
+ [Supprimer un groupe ElastiCache de paramètres](ParameterGroups.Deleting.md)
+ [Paramètres spécifiques au moteur](ParameterGroups.Engine.md)
# Gestion des paramètres dans ElastiCache
ElastiCache les paramètres sont regroupés dans des groupes de paramètres nommés pour faciliter la gestion des paramètres. Un groupe de paramètres représente une combinaison de valeurs spécifiques pour les paramètres qui sont transmis au logiciel de moteur de au moment du démarrage. Ces valeurs déterminent le comportement des processus du moteur sur chaque nœud au moment de l'exécution. Les valeurs des paramètres sur un groupe de paramètres spécifiques s'appliquent à tous les nœuds associés au groupe, indépendamment du cluster auquel ils appartiennent.
Pour affiner les performances de votre cluster, vous pouvez modifier certaines valeurs des paramètres ou modifier le groupe de paramètres du cluster.
+ Vous ne pouvez pas modifier, ni supprimer les groupes de paramètres par défaut. Si vous avez besoin de valeurs des paramètres personnalisés, vous devez créer un groupe de paramètres personnalisés.
+ Pour Memcached, la famille de groupes de paramètres et le cluster auquel vous l'attribuez doivent être compatibles. Par exemple, si votre cluster utilise Memcached version 1.4.8, vous pouvez utiliser uniquement des groupes de paramètres par défaut ou personnalisés de la famille Memcached 1.4.
Pour Redis OSS, la famille de groupes de paramètres et le cluster auquel vous l'attribuez doivent être compatibles. Par exemple, si votre cluster exécute Redis OSS version 3.2.10, vous ne pouvez utiliser que des groupes de paramètres, par défaut ou personnalisés, de la famille Redis OSS 3.2.
+ Si vous modifiez le groupe de paramètres d'un cluster, les valeurs de n'importe quel paramètre modifiable sous certaines conditions doivent être les mêmes dans les deux groupes de paramètre actuel et nouveau.
+ Pour Memcached, lorsque vous modifiez les paramètres d'un cluster, les modifications sont immédiatement appliquées au cluster. C'est vrai si vous changez le groupe de paramètres même du cluster ou une valeur de paramètre dans le groupe de paramètres du cluster. Pour déterminer quand une modification de paramètre particulier sera appliquée, consultez la colonne **Application des modifications** dans les tableaux de [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached). Pour en savoir plus sur le redémarrage des nœuds d’un cluster, consultez [Redémarrage de clusters](Clusters.html#Rebooting).
+ Pour Redis OSS, lorsque vous modifiez les paramètres d'un cluster, la modification est appliquée au cluster soit immédiatement, soit, avec les exceptions indiquées ci-dessous, après le redémarrage des nœuds du cluster. C'est vrai si vous changez le groupe de paramètres même du cluster ou une valeur de paramètre dans le groupe de paramètres du cluster. Pour déterminer quand une modification de paramètre particulier sera appliquée, consultez la colonne **Application des modifications** dans les tableaux de [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis).
Pour plus d'informations sur le redémarrage des nœuds Valkey ou Redis OSS, consultez. [Redémarrage des nœuds](nodes.rebooting.md)
**Modifications des paramètres Valkey ou Redis OSS (mode cluster activé)**
Si vous modifiez les paramètres suivants sur un cluster Valkey ou Redis OSS (mode cluster activé), suivez les étapes suivantes.
activerehachage
bases de données
Créez une sauvegarde manuelle de votre cluster. Consultez [Réalisation de sauvegardes manuelles](backups-manual.md).
Supprimez le cluster. Consultez [Suppression de clusters](Clusters.html#Delete).
Restaurez le cluster grâce au groupe de paramètres modifiés et à la sauvegarde pour alimenter le nouveau cluster. Consultez [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
Les modifications apportées à d'autres paramètres ne nécessitent pas cela.
+ Vous pouvez associer des groupes de paramètres aux banques de données globales Valkey et Redis OSS. Les *banques de données globales sont* un ensemble d'un ou de plusieurs clusters qui s'étendent sur AWS plusieurs régions. Dans ce cas, le groupe de paramètres est partagé par tous les clusters qui composent le magasin de données global. Toute modification apportée au groupe de paramètres du cluster principal est répliquée vers tous les autres clusters restants du magasin de données global. Pour de plus amples informations, veuillez consulter [Réplication entre AWS régions à l'aide de banques de données mondiales](Redis-Global-Datastore.md).
Vous pouvez vérifier si un groupe de paramètres fait partie d'un magasin de données global en effectuant une recherche aux emplacements suivants :
+ Sur la ElastiCache console, sur la page **Groupes de paramètres**, l'attribut yes/no **Global**
+ La yes/no `IsGlobal` propriété de l'opération [CacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CacheParameterGroup.html)d'API
# Le groupe de paramètres du cache intègre des niveaux ElastiCache
Amazon ElastiCache dispose de trois niveaux de groupes de paramètres de cache, comme indiqué ci-dessous.
![\[Image : niveaux du groupe de ElastiCache paramètres Amazon\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-ParameterGroups-Tiers.png)
*Niveaux ElastiCache du groupe de paramètres Amazon*
**Par défaut global**
Le groupe de paramètres racine de premier niveau pour tous les ElastiCache clients Amazon de la région.
Le groupe de paramètres de cache par défaut global :
+ Est réservé au client ElastiCache et n'est pas disponible pour celui-ci.
**Par défaut client**
Une copie du groupe de paramètres de cache par défaut global qui est créée pour être utilisée par le client.
Le groupe de paramètres de cache par défaut client :
+ Est créé et détenu par ElastiCache.
+ Est disponible pour être utilisé par le client comme groupe de paramètres de cache pour tous les clusters qui exécutent une version de moteur prise en charge par ce groupe de paramètres de cache.
+ Ne peut pas être modifié par le client.
**Appartient au client**
Une copie du groupe de paramètres de cache par défaut client. Un groupe de paramètres de cache appartenant au client est créé chaque fois que le client crée un groupe de paramètres de cache.
Le groupe de paramètres de cache par appartenant au client :
+ Est créé par le client et lui appartient.
+ Peut être affecté à tout cluster compatible du client.
+ Peut être modifié par le client pour créer un groupe de paramètres de cache personnalisé.
Toutes les valeurs de paramètre ne peuvent pas être modifiées. Pour plus d'informations sur les valeurs Memcached, consultez. [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached) Pour plus d'informations sur les valeurs Valkey et Redis OSS, consultez. [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis)
# Création d'un groupe ElastiCache de paramètres
Vous devez créer un groupe de paramètres s'il existe une ou plusieurs valeurs de paramètre que vous voulez changer par rapport aux valeurs par défaut. Vous pouvez créer un groupe de paramètres à l'aide de la ElastiCache console, de AWS CLI, ou de l' ElastiCache API.
## Création d'un groupe de ElastiCache paramètres (console)
La procédure suivante montre comment créer un groupe de paramètres à l'aide de la console ElastiCache.
**Pour créer un groupe de paramètres à l'aide de la ElastiCache console**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Groupes de paramètres** pour consulter la liste des groupes de paramètres disponibles.
1. Pour créer un groupe de paramètres, choisissez **Créer un groupe de paramètres**.
L'écran **Create Parameter Group (Créer un groupe de paramètres)** s'affiche.
1. A partir de la liste **Famille**, choisissez la famille groupe de paramètres qui sera le modèle de votre groupe de paramètres.
La famille de groupes de paramètres, telle que *memcached1.4* ou *redis3.2*, définit les paramètres réels de votre groupe de paramètres ainsi que leurs valeurs initiales. La famille de groupe de paramètres doit correspondre avec le moteur du cluster et sa version.
1. Dans la zone **Name**, tapez un nom unique pour ce groupe de paramètres.
Lors de création d'un cluster ou de la modification d'un groupe de paramètres d'un cluster, vous choisissez le groupe de paramètres par son nom. Par conséquent, nous recommandons que le nom soit informatif et permette d'identifier la famille du groupe de paramètres.
Contraintes d'attribution de nom à un groupe de paramètres :
+ Doit commencer par une lettre ASCII.
+ Elle ne peut contenir que des lettres ASCII, des chiffres et des tirets ('-').
+ Doit être comprise entre 1 et 255 caractères.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
1. Dans la zone **Description**, saisissez une description du groupe de paramètres.
1. Choisissez **Créer** pour créer le groupe de paramètres.
Pour terminer le processus sans créer le groupe de paramètres, choisissez **Annuler**.
1. Lorsque le groupe de paramètres est créé, il a les valeurs par défaut de la famille. Pour modifier les valeurs par défaut, vous devez modifier le groupe de paramètres. Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
## Création d'un groupe de ElastiCache paramètres (AWS CLI)
Pour créer un groupe de paramètres à l'aide de AWS CLI, utilisez la commande `create-cache-parameter-group` avec ces paramètres.
+ `--cache-parameter-group-name` – Le nom du groupe de paramètres.
Contraintes d'attribution de nom à un groupe de paramètres :
+ Doit commencer par une lettre ASCII.
+ Elle ne peut contenir que des lettres ASCII, des chiffres et des tirets ('-').
+ Doit être comprise entre 1 et 255 caractères.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
+ `--cache-parameter-group-family` – La famille du moteur et de version pour le groupe de paramètres.
+ `--description` – Une description fourni par l'utilisateur pour le groupe de paramètres.
**Example**
L'exemple suivant crée un paramètre nommé *myMem14* à l'aide de la famille memcached1.4 comme modèle.
Pour Linux, macOS ou Unix :
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--cache-parameter-group-family memcached1.4 \
--description "My first parameter group"
```
Pour Windows :
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--cache-parameter-group-family memcached1.4 ^
--description "My first parameter group"
```
Le résultat de cette commande devrait ressembler à cet exemple.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
}
```
**Example**
L'exemple suivant crée un paramètre nommé *myRed28* à l'aide de la famille redis2.8 comme modèle.
Pour Linux, macOS ou Unix :
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myRed28 \
--cache-parameter-group-family redis2.8 \
--description "My first parameter group"
```
Pour Windows :
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myRed28 ^
--cache-parameter-group-family redis2.8 ^
--description "My first parameter group"
```
Le résultat de cette commande devrait ressembler à cet exemple.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
}
```
Lorsque le groupe de paramètres est créé, il a les valeurs par défaut de la famille. Pour modifier les valeurs par défaut, vous devez modifier le groupe de paramètres. Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-parameter-group.html).
## Création d'un groupe de ElastiCache paramètres (ElastiCache API)
Pour créer un groupe de paramètres à l'aide de l' ElastiCache API, utilisez l'`CreateCacheParameterGroup`action avec ces paramètres.
+ `ParameterGroupName` – Le nom du groupe de paramètres.
Contraintes d'attribution de nom à un groupe de paramètres :
+ Doit commencer par une lettre ASCII.
+ Elle ne peut contenir que des lettres ASCII, des chiffres et des tirets ('-').
+ Doit être comprise entre 1 et 255 caractères.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
+ `CacheParameterGroupFamily` – La famille du moteur et de version pour le groupe de paramètres. Par exemple, `memcached1.4`.
+ `CacheParameterGroupFamily` – La famille du moteur et de version pour le groupe de paramètres. Par exemple, `redis2.8`.
+ `Description` – Une description fourni par l'utilisateur pour le groupe de paramètres.
**Example**
L'exemple suivant crée un paramètre nommé *myMem14* à l'aide de la famille memcached1.4 comme modèle.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheParameterGroup
&CacheParameterGroupFamily=memcached1.4
&CacheParameterGroupName=myMem14
&Description=My%20first%20parameter%20group
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à partir de cette action devrait se présenter comme suit.
```
myMem14memcached1.4My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
**Example**
L'exemple suivant crée un paramètre nommé *myRed28* à l'aide de la famille redis2.8 comme modèle.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheParameterGroup
&CacheParameterGroupFamily=redis2.8
&CacheParameterGroupName=myRed28
&Description=My%20first%20parameter%20group
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à partir de cette action devrait se présenter comme suit.
```
myRed28redis2.8My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
Lorsque le groupe de paramètres est créé, il a les valeurs par défaut de la famille. Pour modifier les valeurs par défaut, vous devez modifier le groupe de paramètres. Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md).
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html).
# Répertorier les groupes de ElastiCache paramètres par nom
Vous pouvez répertorier les groupes de paramètres à l'aide de la ElastiCache console, de AWS CLI, ou de l' ElastiCacheAPI.
## Liste des groupes de paramètres par nom (console)
La procédure suivante montre comment afficher la liste des groupes de paramètres à l'aide de la console ElastiCache .
**Pour répertorier les groupes de paramètres à l'aide de la ElastiCache console**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Groupes de paramètres** pour consulter la liste des groupes de paramètres disponibles.
## Répertorier les groupes de ElastiCache paramètres par nom (AWS CLI)
Pour générer une liste de groupes de paramètres à l'aide de AWS CLI, utilisez la commande`describe-cache-parameter-groups`. Si vous fournissez le nom d'un groupe de paramètres, seul ce groupe de paramètres sera répertorié. Si vous ne fournissez pas de nom d'un groupe de paramètres, un maximum de `--max-records` groupes de paramètres sera répertorié. Dans les deux cas, le nom, la famille et la description du groupe de paramètres sont répertoriés.
**Example**
L'exemple de code suivant répertorie le groupe de paramètres *myMem14*.
Pour Linux, macOS ou Unix :
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myMem14
```
Pour Windows :
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myMem14
```
Le résultat de cette commande se présentera de la façon suivante, avec le nom, la famille et la description du groupe de paramètres.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
]
}
```
**Example**
L'exemple de code suivant répertorie le groupe de paramètres *myRed28*.
Pour Linux, macOS ou Unix :
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed28
```
Pour Windows :
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed28
```
Le résultat de cette commande se présentera de la façon suivante, avec le nom, la famille et la description du groupe de paramètres.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
]
}
```
**Example**
L'exemple de code suivant répertorie le groupe de paramètres *MyRed56* pour les groupes de paramètres exécutés sur le moteur Redis OSS version 5.0.6 et ultérieure. Si le groupe de paramètres fait partie d'un [Réplication entre AWS régions à l'aide de banques de données mondiales](Redis-Global-Datastore.md), la valeur de la propriété `IsGlobal` renvoyée dans la sortie sera `Yes`.
Pour Linux, macOS ou Unix :
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed56
```
Pour Windows :
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed56
```
Le résultat de cette commande se présentera de la façon suivante, avec le nom, la famille, isGlobal et la description du groupe de paramètres.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed56",
"CacheParameterGroupFamily": "redis5.0",
"Description": "My first parameter group",
"IsGlobal": "yes"
}
]
}
```
**Example**
L'exemple de code suivant répertorie jusqu'à 10 groupes de paramètres.
```
aws elasticache describe-cache-parameter-groups --max-records 10
```
La sortie JSON de cette commande se présentera de la façon suivante, indiquant le nom, la famille, la description et, dans le cas de redis5.6, si le groupe de paramètres fait partie d'un entrepôt de données global (isGlobal), pour chaque groupe de paramètres.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "custom-redis32",
"CacheParameterGroupFamily": "redis3.2",
"Description": "custom parameter group with reserved-memory > 0"
},
{
"CacheParameterGroupName": "default.memcached1.4",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "Default parameter group for memcached1.4"
},
{
"CacheParameterGroupName": "default.redis2.6",
"CacheParameterGroupFamily": "redis2.6",
"Description": "Default parameter group for redis2.6"
},
{
"CacheParameterGroupName": "default.redis2.8",
"CacheParameterGroupFamily": "redis2.8",
"Description": "Default parameter group for redis2.8"
},
{
"CacheParameterGroupName": "default.redis3.2",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Default parameter group for redis3.2"
},
{
"CacheParameterGroupName": "default.redis3.2.cluster.on",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Customized default parameter group for redis3.2 with cluster mode on"
},
{
"CacheParameterGroupName": "default.redis5.6.cluster.on",
"CacheParameterGroupFamily": "redis5.0",
"Description": "Customized default parameter group for redis5.6 with cluster mode on",
"isGlobal": "yes"
},
]
}
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameter-groups.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameter-groups.html).
## Répertorier les groupes de ElastiCache paramètres par nom (ElastiCache API)
Pour générer une liste de groupes de paramètres à l'aide de l' ElastiCache API, utilisez l'`DescribeCacheParameterGroups`action. Si vous fournissez le nom d'un groupe de paramètres, seul ce groupe de paramètres sera répertorié. Si vous ne fournissez pas de nom d'un groupe de paramètres, un maximum de `MaxRecords` groupes de paramètres sera répertorié. Dans les deux cas, le nom, la famille et la description du groupe de paramètres sont répertoriés.
**Example**
L'exemple de code suivant répertorie le groupe de paramètres *myMem14*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à partir de cette action se présentera de la façon suivante, avec le nom, la famille et la description de chaque groupe de paramètres.
```
myMem14memcached1.4My custom Memcached 1.4 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
L'exemple de code suivant répertorie jusqu'à 10 groupes de paramètres.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&MaxRecords=10
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à cette action se présentera de la façon suivante, indiquant le nom, la famille, la description et, dans le cas de redis5.6, si le groupe de paramètres appartient à un entrepôt de données global (isGlobal), pour chaque groupe de paramètres.
```
myRedis28redis2.8My custom Redis 2.8 parameter groupmyMem14memcached1.4My custom Memcached 1.4 parameter groupmyRedis56redis5.0My custom redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
L'exemple de code suivant répertorie le groupe de paramètres *myRed28*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à cette action se présentera de la façon suivante, avec le nom, la famille et la description.
```
myRed28redis2.8My custom Redis 2.8 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
L'exemple de code suivant répertorie le groupe de paramètres *myRed56*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed56
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à cette action se présentera de la façon suivante, indiquant le nom, la famille, la description et si le groupe de paramètres fait partie d'un entrepôt de données global (isGlobal).
```
myRed56redis5.0My custom Redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html).
# Lister les valeurs d'un groupe de ElastiCache paramètres
Vous pouvez répertorier les paramètres et leurs valeurs pour un groupe de paramètres à l'aide de la ElastiCache console, de l' AWS CLI API ou de l' ElastiCache API.
## Lister les valeurs d'un groupe de ElastiCache paramètres (console)
La procédure suivante indique comment répertorier les paramètres et leurs valeurs pour un groupe de paramètres à l'aide de la ElastiCache console.
**Pour afficher les paramètres d'un groupe de paramètres et leurs valeurs à l'aide de la console ElastiCache**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Groupes de paramètres** pour consulter la liste des groupes de paramètres disponibles.
1. Choisissez le groupe de paramètres dont vous souhaitez afficher les paramètres et les valeurs en cochant la case située à gauche du nom du groupe de paramètres.
Les paramètres et leurs valeurs figureront au bas de l'écran. En raison du nombre de paramètres, vous devrez peut-être faire défiler la liste vers le haut et en bas pour trouver le paramètre souhaité.
## Affichage des valeurs d'un groupe de paramètres (AWS CLI)
Pour répertorier les paramètres d'un groupe de paramètres et leurs valeurs à l'aide de AWS CLI, utilisez la commande`describe-cache-parameters`.
**Example**
*L'exemple de code suivant répertorie tous les paramètres Memcached et leurs valeurs pour le groupe de paramètres MyMem14.*
Pour Linux, macOS ou Unix :
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myMem14
```
Pour Windows :
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myMem14
```
**Example**
L'exemple de code suivant affiche tous les paramètres et leurs valeurs pour le groupe de paramètres *myRedis28*.
Pour Linux, macOS ou Unix :
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myRedis28
```
Pour Windows :
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myRed28
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameters.html).
## Lister les valeurs d'un groupe de paramètres (ElastiCache API)
Pour répertorier les paramètres d'un groupe de paramètres et leurs valeurs à l'aide de l' ElastiCache API, utilisez l'`DescribeCacheParameters`action.
**Example**
*L'exemple de code suivant répertorie tous les paramètres Memcached pour le groupe de paramètres MyMem14.*
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à partir de cette action devra se présenter comme suit. La réponse à cette a été tronquée.
```
integersystemfalseThe maximum configurable amount of memory to use to store items, in megabytes.1000cache.c1.medium6000cache.c1.xlarge7100cache.m1.large1300cache.m1.small
...output omitted...
6d355589-af49-11e0-97f9-279771c4477e
```
**Example**
L'exemple de code suivant affiche tous les paramètres du groupe de paramètres *myRed28*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La réponse à partir de cette action devra se présenter comme suit. La réponse à cette a été tronquée.
```
integersystemfalseThe maximum configurable amount of memory to use to store items, in megabytes.1000cache.c1.medium6000cache.c1.xlarge7100cache.m1.large1300cache.m1.small
...output omitted...
6d355589-af49-11e0-97f9-279771c4477e
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html).
# Modification d'un groupe ElastiCache de paramètres
**Important**
Vous ne pouvez pas modifier un groupe de paramètres par défaut.
Vous pouvez modifier certaines valeurs des paramètres dans un groupe de paramètres. Ces valeurs de ces paramètres sont appliquées aux clusters associés au groupe de paramètres. Pour plus d'informations sur le moment où une modification de valeur de paramètre est appliquée à un groupe de paramètres, reportez-vous aux [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis) sections et[Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached).
## Modification d'un groupe de paramètres
La procédure suivante montre comment modifier la valeur du `cluster-enabled` paramètre à l'aide de la ElastiCache console. Vous devez utiliser la même procédure pour modifier la valeur de tout paramètre.
**Pour modifier la valeur d'un paramètre à l'aide de la ElastiCache console**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Groupes de paramètres** pour consulter la liste des groupes de paramètres disponibles.
1. Choisissez le groupe de paramètres à modifier en cochant la case située à gauche du nom du groupe de paramètres.
Les paramètres du groupe de paramètres figureront au bas de l'écran. Vous devrez peut-être parcourir la liste pour afficher tous les paramètres.
1. Pour modifier un ou plusieurs paramètres, choisissez **Modifier les paramètres**.
1. Sur l'écran **Edit Parameter Group:** faites défiler, à l'aide des flèches gauche et droite, pour rechercher le paramètre `binding_protocol`, puis tapez `ascii` dans la colonne **Value**.
1. Choisissez **Save Changes (Enregistrer les modifications)**.
1. Pour Memcached, pour trouver le nom du paramètre que vous avez modifié, consultez. [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached) Si des modifications apportées au paramètre prennent effet *après le redémarrage*, redémarrez chaque cluster qui utilise ce groupe de paramètres. Pour plus d’informations, consultez [Redémarrage de clusters](Clusters.html#Rebooting).
1. Avec Valkey et Redis OSS, pour trouver le nom du paramètre que vous avez modifié, consultez. [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis) Si vous avez un cluster Valkey ou Redis OSS (mode cluster désactivé) et que vous modifiez les paramètres suivants, vous devez redémarrer les nœuds du cluster :
+ activerehachage
+ bases de données
Pour plus d'informations sur le redémarrage, veuillez consulter [Redémarrage des nœuds](nodes.rebooting.md).
**Modifications des paramètres Valkey ou Redis OSS (mode cluster activé)**
Si vous modifiez les paramètres suivants sur un cluster Valkey ou Redis OSS (mode cluster activé), suivez les étapes suivantes.
activerehachage
bases de données
Avec Redis OSS, vous pouvez créer une sauvegarde manuelle de votre cluster. Consultez [Réalisation de sauvegardes manuelles](backups-manual.md).
Supprimez le cluster. Consultez [Suppression de clusters](Clusters.html#Delete).
Restaurez le cluster grâce au groupe de paramètres modifiés et à la sauvegarde pour alimenter le nouveau cluster. Consultez [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
Les modifications apportées à d'autres paramètres ne nécessitent pas cela.
## Modification d'un groupe de paramètres (AWS CLI)
Pour modifier la valeur d'un paramètre à l'aide de AWS CLI, utilisez la commande`modify-cache-parameter-group`.
**Example**
Avec Memcached, pour trouver le nom et les valeurs autorisées du paramètre que vous souhaitez modifier, consultez [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached)
L'exemple de code suivant définir la valeur de deux paramètres, *chunk\$1size* et *chunk\$1size\$1growth\$1fact* sur le groupe de paramètres `myMem14`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--parameter-name-values \
ParameterName=chunk_size,ParameterValue=96 \
ParameterName=chunk_size_growth_fact,ParameterValue=1.5
```
Pour Windows :
```
aws elasticache modify-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--parameter-name-values ^
ParameterName=chunk_size,ParameterValue=96 ^
ParameterName=chunk_size_growth_fact,ParameterValue=1.5
```
Le résultat de cette commande doit être semblable à ce qui suit.
```
{
"CacheParameterGroupName": "myMem14"
}
```
**Example**
Avec Valkey et Redis OSS, pour trouver le nom et les valeurs autorisées du paramètre que vous souhaitez modifier, voir [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis)
L'exemple de code suivant définit la valeur de deux paramètres *reserved-memory-percent*et *active le cluster sur le groupe* de paramètres. `myredis32-on-30` Nous avons réglé *reserved-memory-percent*sur `30` (30 %) et *activé le cluster* sur `yes` afin que le groupe de paramètres puisse être utilisé avec les clusters Valkey ou Redis OSS (mode cluster activé) (groupes de réplication).
Pour Linux, macOS ou Unix :
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name myredis32-on-30 \
--parameter-name-values \
ParameterName=reserved-memory-percent,ParameterValue=30 \
ParameterName=cluster-enabled,ParameterValue=yes
```
Pour Windows :
```
aws elasticache modify-cache-parameter-group ^
--cache-parameter-group-name myredis32-on-30 ^
--parameter-name-values ^
ParameterName=reserved-memory-percent,ParameterValue=30 ^
ParameterName=cluster-enabled,ParameterValue=yes
```
Le résultat de cette commande doit être semblable à ce qui suit.
```
{
"CacheParameterGroupName": "my-redis32-on-30"
}
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-parameter-group.html).
Pour rechercher le nom du paramètre que vous avez modifié, consultez [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis).
Si vous avez un cluster Valkey ou Redis OSS (mode cluster désactivé) et que vous modifiez les paramètres suivants, vous devez redémarrer les nœuds du cluster :
+ activerehachage
+ bases de données
Pour plus d'informations sur le redémarrage, veuillez consulter [Redémarrage des nœuds](nodes.rebooting.md).
**Modifications des paramètres Valkey ou Redis OSS (mode cluster activé)**
Si vous modifiez les paramètres suivants sur un cluster Valkey ou Redis OSS (mode cluster activé), suivez les étapes suivantes.
activerehachage
bases de données
Créez une sauvegarde manuelle de votre cluster. Consultez [Réalisation de sauvegardes manuelles](backups-manual.md).
Supprimez le cluster. Consultez [Suppression de clusters](Clusters.html#Delete).
Restaurez le cluster grâce au groupe de paramètres modifiés et à la sauvegarde pour alimenter le nouveau cluster. Consultez [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
Les modifications apportées à d'autres paramètres ne nécessitent pas cela.
## Modification d'un groupe de paramètres (ElastiCache API)
Pour modifier les valeurs des paramètres d'un groupe de paramètres à l'aide de l' ElastiCache API, utilisez l'`ModifyCacheParameterGroup`action.
**Example**
Avec Memcached, pour trouver le nom et les valeurs autorisées du paramètre que vous souhaitez modifier, consultez [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached)
L'exemple de code suivant définir la valeur de deux paramètres, *chunk\$1size* et *chunk\$1size\$1growth\$1fact* sur le groupe de paramètres `myMem14`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheParameterGroup
&CacheParameterGroupName=myMem14
&ParameterNameValues.member.1.ParameterName=chunk_size
&ParameterNameValues.member.1.ParameterValue=96
&ParameterNameValues.member.2.ParameterName=chunk_size_growth_fact
&ParameterNameValues.member.2.ParameterValue=1.5
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
**Example**
Avec Valkey et Redis OSS, pour trouver le nom et les valeurs autorisées du paramètre que vous souhaitez modifier, voir [Paramètres OSS Valkey et Redis](ParameterGroups.Engine.md#ParameterGroups.Redis)
L'exemple de code suivant définit la valeur de deux paramètres *reserved-memory-percent*et *active le cluster sur le groupe* de paramètres. `myredis32-on-30` Nous avons réglé *reserved-memory-percent*sur `30` (30 %) et *activé le cluster* sur `yes` afin que le groupe de paramètres puisse être utilisé avec les clusters Valkey ou Redis OSS (mode cluster activé) (groupes de réplication).
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheParameterGroup
&CacheParameterGroupName=myredis32-on-30
&ParameterNameValues.member.1.ParameterName=reserved-memory-percent
&ParameterNameValues.member.1.ParameterValue=30
&ParameterNameValues.member.2.ParameterName=cluster-enabled
&ParameterNameValues.member.2.ParameterValue=yes
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html).
Si vous avez un cluster Valkey ou Redis OSS (mode cluster désactivé) et que vous modifiez les paramètres suivants, vous devez redémarrer les nœuds du cluster :
+ activerehachage
+ bases de données
Pour de plus amples informations, veuillez consulter [Redémarrage des nœuds](nodes.rebooting.md).
**Modifications des paramètres Valkey ou Redis OSS (mode cluster activé)**
Si vous modifiez les paramètres suivants sur un cluster Valkey ou Redis OSS (mode cluster activé), suivez les étapes suivantes.
activerehachage
bases de données
Créez une sauvegarde manuelle de votre cluster. Consultez [Réalisation de sauvegardes manuelles](backups-manual.md).
Supprimez le cluster. Consultez [Supprimer un cluster dans ElastiCache](Clusters.Delete.md).
Restaurez le cluster grâce au groupe de paramètres modifiés et à la sauvegarde pour alimenter le nouveau cluster. Consultez [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
Les modifications apportées à d'autres paramètres ne nécessitent pas cela.
# Supprimer un groupe ElastiCache de paramètres
Vous pouvez supprimer un groupe de paramètres personnalisé à l'aide de la ElastiCache console, de AWS CLI, ou de l'ElastiCache API.
Vous ne pouvez pas supprimer un groupe de paramètres s'il est associé à n'importe quel clusters de Vous ne pouvez pas supprimer non plus les groupes de paramètres par défaut.
## Suppression d'un groupe de paramètres (console)
La procédure suivante montre comment supprimer un groupe de paramètres à l'aide de la console ElastiCache.
**Pour supprimer un groupe de paramètres à l'aide de la ElastiCache console**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation de gauche, choisissez **Groupes de paramètres** pour consulter la liste des groupes de paramètres disponibles.
1. Choisissez les groupes de paramètres à supprimer en cochant la case située à gauche du nom du groupe de paramètres.
Le bouton **Supprimer** devient actif.
1. Sélectionnez **Delete (Supprimer)**.
L'écran de confirmation **Delete Parameter Groups** s'affichera.
1. Pour supprimer les groupes de paramètres, sur l'écran de confirmation **Supprimer les groupes de paramètres** , choisissez **Supprimer**.
Pour conserver les groupes de paramètres, choisissez **Annuler**.
## Suppression d'un groupe de paramètres (AWS CLI)
Pour supprimer un groupe de paramètres à l'aide de AWS CLI, utilisez la commande`delete-cache-parameter-group`. Pour le groupe de paramètres à supprimer, le groupe de paramètres spécifié par `--cache-parameter-group-name` ne peut pas avoir de clusters associés, et ne peut pas être non plus un groupe de paramètres par défaut.
L'exemple de code suivant supprime le groupe de paramètres *myMem14*.
**Example**
Pour Linux, macOS ou Unix :
```
aws elasticache delete-cache-parameter-group \
--cache-parameter-group-name myRed28
```
Pour Windows :
```
aws elasticache delete-cache-parameter-group ^
--cache-parameter-group-name myRed28
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-parameter-group.html).
## Supprimer un groupe de paramètres (ElastiCache API)
Pour supprimer un groupe de paramètres à l'aide de l' ElastiCache API, utilisez l'`DeleteCacheParameterGroup`action. Pour le groupe de paramètres à supprimer, le groupe de paramètres spécifié par `CacheParameterGroupName` ne peut pas avoir de clusters associés, et ne peut pas être non plus un groupe de paramètres par défaut.
**Example**
Avec Memcached, l'exemple de code suivant supprime le groupe de paramètres *MyMem14*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheParameterGroup
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
**Example**
L'exemple de code suivant supprime le groupe de paramètres *myRed28*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheParameterGroup
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Pour de plus amples informations, veuillez consulter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html).
# Paramètres spécifiques au moteur
**Valkey et Redis OSS**
La plupart des paramètres Valkey 8 sont compatibles avec les paramètres Redis OSS 7.1. Les paramètres Valkey 7.2 sont les mêmes que ceux de Redis OSS 7.
Si vous ne spécifiez aucun groupe de paramètres pour votre cluster Valkey ou Redis OSS, un groupe de paramètres par défaut adapté à la version de votre moteur sera utilisé. Vous ne pouvez pas modifier les valeurs des paramètres dans le groupe de paramètres par défaut. Vous pouvez cependant créer un groupe de paramètres personnalisés et l'assigner à votre cluster à tout moment, tant que les valeurs des paramètres modifiables sous conditions sont les mêmes dans les deux groupes de paramètres. Pour de plus amples informations, veuillez consulter [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md).
**Topics**
+ [Paramètres OSS Valkey et Redis](#ParameterGroups.Redis)
+ [Paramètres spécifiques Memcached](#ParameterGroups.Memcached)
## Paramètres OSS Valkey et Redis
**Topics**
+ [Modifications des paramètres de Valkey 8.2](#ParameterGroups.Valkey.8.2)
+ [Modifications des paramètres de Valkey 8.1](#ParameterGroups.Valkey.8.1)
+ [Modifications des paramètres de Valkey 8.0](#ParameterGroups.Valkey.8)
+ [Modifications des paramètres de Valkey 7.2 et Redis OSS 7](#ParameterGroups.Redis.7)
+ [Modifications des paramètres de Redis OSS 6.x](#ParameterGroups.Redis.6-x)
+ [Modifications des paramètres de Redis OSS 5.0.3](#ParameterGroups.Redis.5-0-3)
+ [Modifications des paramètres de Redis OSS 5.0.0](#ParameterGroups.Redis.5.0)
+ [Modifications des paramètres de Redis OSS 4.0.10](#ParameterGroups.Redis.4-0-10)
+ [Modifications des paramètres de Redis OSS 3.2.10](#ParameterGroups.Redis.3-2-10)
+ [Modifications des paramètres de Redis OSS 3.2.6](#ParameterGroups.Redis.3-2-6)
+ [Modifications des paramètres de Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4)
+ [Paramètres ajoutés à Redis OSS 2.8.24 (amélioré)](#ParameterGroups.Redis.2-8-24)
+ [Paramètres ajoutés à Redis OSS 2.8.23 (amélioré)](#ParameterGroups.Redis.2-8-23)
+ [Paramètres ajoutés à Redis OSS 2.8.22 (amélioré)](#ParameterGroups.Redis.2-8-22)
+ [Paramètres ajoutés à Redis OSS 2.8.21](#ParameterGroups.Redis.2-8-21)
+ [Paramètres ajoutés à Redis OSS 2.8.19](#ParameterGroups.Redis.2-8-19)
+ [Paramètres ajoutés à Redis OSS 2.8.6](#ParameterGroups.Redis.2-8-6)
+ [Paramètres de Redis OSS 2.6.13](#ParameterGroups.Redis.2-6-13)
+ [Paramètres spécifiques au type de nœud Redis OSS](#ParameterGroups.Redis.NodeSpecific)
### Modifications des paramètres de Valkey 8.2
**Famille de groupes de paramètres : valkey8**
**Note**
Les modifications des paramètres de Valkey 8.2 ne s'appliquent pas à Valkey 8.1
Les groupes de paramètres Valkey 8.0 et versions ultérieures sont incompatibles avec Redis OSS 7.2.4.
dans Valkey 8.2, les commandes suivantes ne sont pas disponibles pour les caches sans serveur :`commandlog`,,`commandlog get`, et `commandlog help` `commandlog len` `commandlog reset.`
**Nouveaux groupes de paramètres dans Valkey 8.2**
| Name | Détails | Description |
| --- | --- | --- |
| search-fanout-target-mode (ajouté en 8.2) | Par défaut : client Type : chaîne Modifiable : oui Les modifications entrent en vigueur : immédiatement | Le paramètre search-fanout-target-mode de configuration contrôle la manière dont les requêtes de recherche sont distribuées entre les nœuds d'un environnement de cluster Valkey. Ce paramètre accepte deux valeurs : « débit » qui optimise le débit maximal en répartissant les requêtes de recherche de manière aléatoire sur tous les nœuds du cluster, quel que soit le type de client ou le statut READONLY, et « client » qui respecte les caractéristiques de connexion client en acheminant les clients non READONLY vers les nœuds principaux uniquement, les clients READONLY sur les connexions principales de manière aléatoire sur tous les nœuds. Le comportement par défaut est le mode « client », ce qui signifie que le système respectera les types de connexion client et le statut READONLY pour les décisions relatives au routage des requêtes. Utilisez le mode débit pour les charges de travail de recherche à volume élevé où une utilisation maximale des ressources du cluster est souhaitée, et le mode client lorsque vous souhaitez maintenir la read/write séparation et respecter les modèles de connexion READONLY au niveau de l'application. |
| search-default-timeout-ms | Par défaut : 50000 Valeurs autorisées : 1 à 60 000 Type : entier Modifiable : oui Les modifications entrent en vigueur : immédiatement | Le délai d'expiration par défaut de la requête de recherche Valkey (en millisecondes). |
| search-enable-partial-results | Par défaut : oui Valeurs autorisées : oui, non Type : valeur booléenne Modifiable : oui Les modifications entrent en vigueur : immédiatement | Configure le comportement d'échec des requêtes pour Valkey Search. Lorsque cette option est activée, les requêtes de recherche renvoient des résultats partiels si des délais d'attente se produisent sur une ou plusieurs partitions. Lorsqu'elle est désactivée, tout délai d'expiration de la partition entraîne l'échec de l'ensemble de la requête de recherche et renvoie une erreur. |
### Modifications des paramètres de Valkey 8.1
**Famille de groupes de paramètres : valkey8**
**Note**
Les modifications des paramètres de Valkey 8.1 ne s'appliquent pas à Valkey 8.0
Les groupes de paramètres Valkey 8.0 et versions ultérieures sont incompatibles avec Redis OSS 7.2.4.
dans Valkey 8.1, les commandes suivantes ne sont pas disponibles pour les caches sans serveur :`commandlog`,,`commandlog get`, et `commandlog help` `commandlog len` `commandlog reset.`
**Nouveaux groupes de paramètres dans Valkey 8.1**
| Name | Détails | Description |
| --- | --- | --- |
| commandlog-large-request-max-len (ajouté dans la version 8.1) | Par défaut: 1048576 Type : entier Modifiable : oui Les modifications entrent en vigueur : immédiatement | La taille maximale, en octets, des requêtes à enregistrer par la fonctionnalité Valkey Command Log. |
| commandlog-large-request-max-len (ajouté dans la version 8.1) | Valeur par défaut : 128 Valeurs autorisées : 0 à 1024 Type : entier Modifiable : oui Les modifications entrent en vigueur : immédiatement | La longueur maximale du journal des commandes Valkey pour les demandes. |
| commandlog-reply-larger-than (ajouté dans la version 8.1) | Par défaut: 1048576 Type : entier Modifiable : oui Les modifications entrent en vigueur : immédiatement | Taille maximale, en octets, des réponses à enregistrer par la fonctionnalité Valkey Command Log. |
| commandlog-large-reply-max-len (ajouté dans la version 8.1) | Valeur par défaut : 128 Valeurs autorisées : 0 à 1024 Type : entier Modifiable : oui Les modifications entrent en vigueur : immédiatement | La longueur maximale du journal des commandes Valkey pour les réponses. |
### Modifications des paramètres de Valkey 8.0
**Famille de groupes de paramètres : valkey8**
**Note**
Redis OSS 7.2.4 est incompatible avec les groupes de paramètres Valkey 8 et supérieurs.
**Changements de paramètres spécifiques dans Valkey 8.0**
| Name | Détails | Description |
| --- | --- | --- |
| repl-backlog-size | Par défaut : 10485760 Type : entier Modifiable : oui Les modifications entrent en vigueur : immédiatement | La taille, en octets, de la mémoire tampon du journal des éléments en attente de nœud principal. Le journal des éléments en attente est utilisé pour enregistrer des mises à jour dans les données sur le nœud principal. Lorsqu'une réplique de lecture se connecte au nœud principal, elle tente d'effectuer une synchronisation partielle (psync), au cours de laquelle elle applique les données du backlog pour rattraper le nœud principal. Si le psync échoue, une synchronisation complète est requise. La valeur minimale pour ce paramètre est 16384. Remarque : à partir de Redis OSS 2.8.22, ce paramètre s'applique au cluster principal ainsi qu'aux répliques de lecture. |
| nombre maximum d'échantillons de mémoire | Valeur par défaut : 3 Valeurs autorisées : 1 à 64 Type : entier Modifiable : oui Les modifications entrent en vigueur : immédiatement | Pour les calculs least-recently-used (LRU) et time-to-live (TTL), ce paramètre représente la taille de l'échantillon des clés à vérifier. Par défaut, Redis OSS choisit 3 clés et utilise celle qui a été utilisée le moins récemment. |
**Nouveaux groupes de paramètres dans Valkey 8.0**
| Name | Détails | Description |
| --- | --- | --- |
| extended-redis-compatibility | Valeurs autorisées : oui, non Par défaut : oui Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Le mode de compatibilité étendue de Redis OSS fait que Valkey se fait passer pour Redis OSS 7.2. Activez cette option uniquement si vous rencontrez des problèmes avec les outils ou les clients. Impacts sur le client : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
**Groupes de paramètres supprimés dans Valkey 8.0**
| Name | Détails | Description |
| --- | --- | --- |
| lazyfree-lazy-eviction | Valeurs autorisées : oui, non Par défaut : non Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Effectue une suppression asynchrone des évictions. |
| lazyfree-lazy-expire | Valeurs autorisées : oui, non Par défaut : non Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Effectue une suppression asynchrone des clés expirées. |
| lazyfree-lazy-server-del | Valeurs autorisées : oui, non Par défaut : non Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Effectue une suppression asynchrone des commandes qui mettent à jour les valeurs. |
| lazyfree-lazy-user-del | Par défaut : non Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster | Lorsque la valeur est définie sur yes, la commande DEL agit de la même manière que UNLINK. |
| replica-lazy-flush | Par défaut : oui Type : valeur booléenne Modifiable : non Ancien nom : slave-lazy-flush | Exécute une commande flushDB asynchrone pendant la synchronisation du réplica. |
### Modifications des paramètres de Valkey 7.2 et Redis OSS 7
**Famille de groupes de paramètres : valkey7**
Les groupes de paramètres par défaut de Valkey 7.2 sont les suivants :
+ `default.valkey7`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey (mode cluster désactivé) et les groupes de réplication.
+ `default.valkey7.cluster.on`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey (mode cluster activé) et les groupes de réplication.
**Famille de groupes de paramètres :** redis7
Les groupes de paramètres par défaut de Redis OSS 7 sont les suivants :
+ `default.redis7`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Redis OSS (mode cluster désactivé) et les groupes de réplication.
+ `default.redis7.cluster.on`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Redis OSS (mode cluster activé) et les groupes de réplication.
**Modifications de paramètres spécifiques**
Les paramètres ajoutés dans Redis OSS 7 sont les suivants. Valkey 7.2 prend également en charge ces paramètres.
| Name | Détails | Description |
| --- | --- | --- |
| cluster-allow-pubsubshard-when-down | Valeurs autorisées : `yes`, `no` Valeur par défaut : `yes` Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Lorsque la valeur par défaut est yes, elle autorise les nœuds à traiter le trafic de partition pubsub lorsque le cluster est inactif, à condition qu'il pense être propriétaire des emplacements. |
| cluster-preferred-endpoint-type | Valeurs autorisées : `ip`, `tls-dynamic` Valeur par défaut : `tls-dynamic` Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Cette valeur contrôle le point de terminaison renvoyé pour les requêtes MOVED/ASKING ainsi que le champ de point de terminaison pour `CLUSTER SLOTS` et `CLUSTER SHARDS`. Lorsque la valeur est définie sur ip, le nœud annonce son adresse IP. Lorsque la valeur est définie sur tls-dynamic, le nœud annonce un nom d'hôte lorsqu'il encryption-in-transit est activé et une adresse IP dans le cas contraire. |
| latency-tracking | Valeurs autorisées : `yes`, `no` Valeur par défaut : `no` Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Lorsque ce paramètre est défini sur yes, il suit les latences par commande et permet d'exporter la distribution percentile via la commande de statistiques de latence `INFO` et les distributions de latence cumulées (histogrammes) via la commande `LATENCY`. |
| hash-max-listpack-entries | Valeurs autorisées : `0+` Valeur par défaut : `512` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Nombre maximum d'entrées de hachage pour que le jeu de données soit compressé. |
| hash-max-listpack-value | Valeurs autorisées : `0+` Valeur par défaut : `64` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Le seuil des entrées de hachage les plus importantes pour que le jeu de données soit compressé. |
| zset-max-listpack-entries | Valeurs autorisées : `0+` Valeur par défaut : `128` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Nombre maximum d'entrées de jeu triées pour que le jeu de données soit compressé. |
| zset-max-listpack-value | Valeurs autorisées : `0+` Valeur par défaut : `64` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Le seuil des entrées de jeu triées les plus importantes pour que le jeu de données soit compressé. |
Les paramètres modifiés dans Redis OSS 7 sont les suivants.
| Name | Détails | Description |
| --- | --- | --- |
| activerehashing | Modifiable : `no`. Dans Redis OSS 7, ce paramètre est masqué et activé par défaut. Pour le désactiver, vous devez créer un [cas de support](https://console.aws.amazon.com/support/home). | Modifiable était sur oui. |
Les paramètres supprimés dans Redis OSS 7 sont les suivants.
| Name | Détails | Description |
| --- | --- | --- |
| hash-max-ziplist-entries | Valeurs autorisées : `0+` Valeur par défaut : `512` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Utilisez `listpack` plutôt que `ziplist` pour représenter un petit encodage à hachage |
| hash-max-ziplist-value | Valeurs autorisées : `0+` Valeur par défaut : `64` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Utilisez `listpack` plutôt que `ziplist` pour représenter un petit encodage à hachage |
| zset-max-ziplist-entries | Valeurs autorisées : `0+` Valeur par défaut : `128` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Utilisez `listpack` plutôt que `ziplist` pour représenter un petit encodage à hachage. |
| zset-max-ziplist-value | Valeurs autorisées : `0+` Valeur par défaut : `64` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Utilisez `listpack` plutôt que `ziplist` pour représenter un petit encodage à hachage. |
| list-max-ziplist-size | Valeurs autorisées : Valeur par défaut : `-2` Type : entier Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster. | Nombre d'entrées autorisées par nœud de liste interne. |
### Modifications des paramètres de Redis OSS 6.x
**Famille de groupes de paramètres :** redis6.x
Les groupes de paramètres par défaut de Redis OSS 6.x sont les suivants :
+ `default.redis6.x`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster désactivé) et les groupes de réplication.
+ `default.redis6.x.cluster.on`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster activé) et les groupes de réplication.
**Note**
Dans la version 6.2 du moteur Redis OSS, lorsque la famille de nœuds r6gd a été introduite pour être utilisée avec, seules les politiques de mémoire maximale *noeviction [Hiérarchisation des données ElastiCache](data-tiering.md)*, *volatile-lru et *allkeys-lru** sont prises en charge avec les types de nœuds r6gd.
Pour plus d’informations, consultez [ElastiCache version 6.2 pour Redis OSS (améliorée)](engine-versions.md#redis-version-6.2) et [ElastiCache version 6.0 pour Redis OSS (améliorée)](engine-versions.md#redis-version-6.0).
Les paramètres ajoutés dans Redis OSS 6.x sont les suivants.
| Détails | Description |
| --- | --- |
| acl-pubsub-default (added in 6.2) | Valeurs autorisées : `resetchannels`, `allchannels` Valeur par défaut : `allchannels` Type : chaîne Modifiable : oui Les modifications prennent effet : les utilisateurs Redis OSS existants associés au cluster continueront à disposer des autorisations existantes. Mettez à jour les utilisateurs ou redémarrez le cluster pour mettre à jour les utilisateurs Redis OSS existants. | Autorisations de canal Pubsub par défaut pour les utilisateurs ACL déployés sur ce cluster. |
| cluster-allow-reads-when-down (added in 6.0) | Par défaut : non Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster | Lorsqu'il est défini sur yes, un groupe de réplication Redis OSS (mode cluster activé) continue de traiter les commandes de lecture même lorsqu'un nœud n'est pas en mesure d'atteindre un quorum de primaires. Lorsque la valeur par défaut est no, le groupe de réplication rejette toutes les commandes. Nous vous recommandons de définir cette valeur sur yes si vous utilisez un cluster avec moins de trois groupes de nœuds ou si votre application peut gérer des lectures obsolètes en toute sécurité. |
| tracking-table-max-keys (added in 6.0) | Par défaut: 1 000 000 Type : nombre Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster | Pour faciliter la mise en cache côté client, Redis OSS permet de suivre quels clients ont accédé à quelles clés. Lorsque la clé suivie est modifiée, des messages d'invalidation sont envoyés à tous les clients pour les avertir que leurs valeurs mises en cache ne sont plus valides. Cette valeur vous permet de spécifier la limite supérieure de cette table. Une fois que cette valeur de paramètre est dépassée, les clients reçoivent une invalidation aléatoire. Cette valeur doit être réglée pour limiter l'utilisation de la mémoire tout en gardant une trace de suffisamment de clés. Les clés sont également invalidées dans des conditions de mémoire faible. |
| acllog-max-len (added in 6.0) | Valeur par défaut : 128 Type : nombre Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster | Cette valeur correspond au nombre maximal d'entrées dans le journal ACL. |
| active-expire-effort (added in 6.0) | Valeur par défaut : 1 Type : nombre Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster | Redis OSS supprime les clés qui ont dépassé leur durée de vie par deux mécanismes. Dans l'un, une clé est accessible et a expiré. Dans l'autre, un travail périodique échantillonne les clés et provoque l'expiration de celles qui ont dépassé leur time-to-live. Ce paramètre définit l'effort déployé par Redis OSS pour faire expirer les éléments du travail périodique. La valeur par défaut de 1 tente d'éviter que plus de 10 % des clés expirées restent en mémoire. Il essaie également d'éviter de consommer plus de 25 % de la mémoire totale et d'ajouter une latence au système. Vous pouvez augmenter cette valeur jusqu'à 10 pour augmenter l'effort consacré aux clés d'expiration. Le compromis est une utilisation CPU plus élevée et une latence potentiellement plus élevée. Nous recommandons une valeur de 1, sauf si vous constatez une utilisation élevée de la mémoire et que vous pouvez tolérer une augmentation de l'utilisation du processeur. |
| lazyfree-lazy-user-del (added in 6.0) | Par défaut : non Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster | Lorsque la valeur est définie sur yes, la propriété `DEL` agit de la même manière que `UNLINK`. |
Les paramètres supprimés dans Redis OSS 6.x sont les suivants.
| Name | Détails | Description |
| --- | --- | --- |
| lua-replicate-commands | Valeurs autorisées : yes / no Par défaut : oui Type : valeur booléenne Modifiable : oui Les modifications prennent effet : immédiatement | Active ou non la réplication de l'effet Lua dans les scripts Lua |
### Modifications des paramètres de Redis OSS 5.0.3
**Famille de groupes de paramètres :** redis5.0
Groupes de paramètres par défaut de Redis OSS 5.0
+ `default.redis5.0`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster désactivé) et les groupes de réplication.
+ `default.redis5.0.cluster.on`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster activé) et les groupes de réplication.
**Paramètres ajoutés dans Redis OSS 5.0.3**
| Name | Détails | Description |
| --- | --- | --- |
| rename-commands | Par défaut: Aucun Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement sur tous les nœuds du cluster | Liste séparée par des espaces de commandes Redis OSS renommées. Voici une liste limitée de commandes disponibles pour le changement de nom : `APPEND AUTH BITCOUNT BITFIELD BITOP BITPOS BLPOP BRPOP BRPOPLPUSH BZPOPMIN BZPOPMAX CLIENT CLUSTER COMMAND DBSIZE DECR DECRBY DEL DISCARD DUMP ECHO EVAL EVALSHA EXEC EXISTS EXPIRE EXPIREAT FLUSHALL FLUSHDB GEOADD GEOHASH GEOPOS GEODIST GEORADIUS GEORADIUSBYMEMBER GET GETBIT GETRANGE GETSET HDEL HEXISTS HGET HGETALL HINCRBY HINCRBYFLOAT HKEYS HLEN HMGET HMSET HSET HSETNX HSTRLEN HVALS INCR INCRBY INCRBYFLOAT INFO KEYS LASTSAVE LINDEX LINSERT LLEN LPOP LPUSH LPUSHX LRANGE LREM LSET LTRIM MEMORY MGET MONITOR MOVE MSET MSETNX MULTI OBJECT PERSIST PEXPIRE PEXPIREAT PFADD PFCOUNT PFMERGE PING PSETEX PSUBSCRIBE PUBSUB PTTL PUBLISH PUNSUBSCRIBE RANDOMKEY READONLY READWRITE RENAME RENAMENX RESTORE ROLE RPOP RPOPLPUSH RPUSH RPUSHX SADD SCARD SCRIPT SDIFF SDIFFSTORE SELECT SET SETBIT SETEX SETNX SETRANGE SINTER SINTERSTORE SISMEMBER SLOWLOG SMEMBERS SMOVE SORT SPOP SRANDMEMBER SREM STRLEN SUBSCRIBE SUNION SUNIONSTORE SWAPDB TIME TOUCH TTL TYPE UNSUBSCRIBE UNLINK UNWATCH WAIT WATCH ZADD ZCARD ZCOUNT ZINCRBY ZINTERSTORE ZLEXCOUNT ZPOPMAX ZPOPMIN ZRANGE ZRANGEBYLEX ZREVRANGEBYLEX ZRANGEBYSCORE ZRANK ZREM ZREMRANGEBYLEX ZREMRANGEBYRANK ZREMRANGEBYSCORE ZREVRANGE ZREVRANGEBYSCORE ZREVRANK ZSCORE ZUNIONSTORE SCAN SSCAN HSCAN ZSCAN XINFO XADD XTRIM XDEL XRANGE XREVRANGE XLEN XREAD XGROUP XREADGROUP XACK XCLAIM XPENDING GEORADIUS_RO GEORADIUSBYMEMBER_RO LOLWUT XSETID SUBSTR` |
Pour de plus amples informations, veuillez consulter [ElastiCache version 5.0.6 pour Redis OSS (améliorée)](engine-versions.md#redis-version-5-0.6).
### Modifications des paramètres de Redis OSS 5.0.0
**Famille de groupes de paramètres :** redis5.0
Groupes de paramètres par défaut de Redis OSS 5.0
+ `default.redis5.0`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster désactivé) et les groupes de réplication.
+ `default.redis5.0.cluster.on`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster activé) et les groupes de réplication.
**Paramètres ajoutés dans Redis OSS 5.0**
| Name | Détails | Description |
| --- | --- | --- |
| stream-node-max-bytes | Valeurs autorisées : 0\$1 Par défaut: 4096 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | La structure des données du flux est une arborescence de nœuds radix qui encodent plusieurs éléments à l'intérieur. Utilisez cette configuration pour spécifier la taille maximale d'un nœud unique dans une arborescence radix, exprimée en octets. Si la taille du nœud de l'arborescence est définie sur 0, elle n'est pas limitée. |
| stream-node-max-entries | Valeurs autorisées : 0\$1 Par défaut : 100 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | La structure des données du flux est une arborescence de nœuds radix qui encodent plusieurs éléments à l'intérieur. Utilisez cette configuration pour spécifier le nombre maximal d'éléments que peut contenir un même nœud avant le basculement sur un nouveau nœud lors de l'ajout de nouvelles entrées de flux. Si la valeur est définie sur 0, le nombre d'éléments du nœud de l'arborescence n'est pas limité. |
| active-defrag-max-scan-fields | Valeurs autorisées : de 1 à 1000000 Par défaut: 1000 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | Nombre maximum de set/hash/zset/list champs qui seront traités à partir de l'analyse du dictionnaire principal |
| lua-replicate-commands | Valeurs autorisées : yes / no Par défaut : oui Type : valeur booléenne Modifiable : oui Les modifications prennent effet : immédiatement | Active ou non la réplication de l'effet Lua dans les scripts Lua |
| replica-ignore-maxmemory | Par défaut : oui Type : valeur booléenne Modifiable : non | Détermine si le réplica ignore le paramètre maxmemory en ne supprimant pas les éléments indépendants du principal |
Redis OSS a renommé plusieurs paramètres dans la version 5.0 du moteur en réponse aux commentaires de la communauté. Pour plus d'informations, consultez [Quoi de neuf dans Redis OSS 5 ?](https://aws.amazon.com/redis/Whats_New_Redis5/) . Le tableau suivant répertorie les nouveaux noms et montre leur correspondance avec les versions précédentes.
**Paramètres renommés dans Redis OSS 5.0**
| Name | Détails | Description |
| --- | --- | --- |
| replica-lazy-flush | Par défaut : oui Type : valeur booléenne Modifiable : non Ancien nom : slave-lazy-flush | Exécute une commande flushDB asynchrone pendant la synchronisation du réplica. |
| client-output-buffer-limit-replica-hard-limit | Par défaut : pour connaître les valeurs, consultez [Paramètres spécifiques au type de nœud Redis OSS](#ParameterGroups.Redis.NodeSpecific) Type : entier Modifiable : non Ancien nom : client-output-buffer-limit - slave-hard-limit | Pour les répliques de lecture Redis OSS : si le tampon de sortie d'un client atteint le nombre d'octets spécifié, le client sera déconnecté. |
| client-output-buffer-limit-replica-soft-limit | Par défaut : pour connaître les valeurs, consultez [Paramètres spécifiques au type de nœud Redis OSS](#ParameterGroups.Redis.NodeSpecific) Type : entier Modifiable : non Ancien nom : client-output-buffer-limit - slave-soft-limit | Pour les répliques de lecture Redis OSS : si la mémoire tampon de sortie d'un client atteint le nombre d'octets spécifié, le client sera déconnecté, mais uniquement si cette condition persiste pendant. client-output-buffer-limit-replica-soft-seconds |
| client-output-buffer-limit-replica-soft-seconds | Par défaut : 60 Type : entier Modifiable : non Ancien nom : client-output-buffer-limit - slave-soft-seconds | Pour les répliques de lecture de Redis OSS : si la mémoire tampon de sortie d'un client reste en client-output-buffer-limit-replica-soft-limit octets pendant plus de secondes, le client sera déconnecté. |
| replica-allow-chaining | Par défaut : non Type : chaîne Modifiable : non Ancien nom : slave-allow-chaining | Détermine si une réplique en lecture dans Redis OSS peut avoir ses propres répliques en lecture. |
| min-replicas-to-write | Par défaut : 0 Type : entier Modifiable : oui Ancien nom : min-slaves-to-write Les modifications prennent effet : immédiatement | Le nombre minimum de réplicas en lecture qui doivent être disponibles pour que le nœud principal puisse accepter des écritures des clients. Si le nombre de réplicas disponibles est inférieur à ce nombre, alors le nœud principal n'acceptera plus de demandes d'écriture. Si ce paramètre min-replicas-max-lag est égal à 0, le nœud principal acceptera toujours les demandes d'écriture, même si aucune réplique n'est disponible. |
| min-replicas-max-lag | Par défaut: 10 Type : entier Modifiable : oui Ancien nom : min-slaves-max-lag Les modifications prennent effet : immédiatement | Le nombre de secondes au cours desquelles le nœud principal doit suivre une requête ping à partir d'un réplica en lecture. Si ce laps de temps s'écoule et que le nœud principal ne reçoit pas un message ping, alors le réplica n'est plus considéré comme étant disponible. Si le nombre de répliques disponibles tombe en dessous min-replicas-to-write, le serveur principal cessera d'accepter les écritures à ce moment-là. Si ce paramètre min-replicas-to-write est égal à 0, le nœud principal acceptera toujours les demandes d'écriture, même si aucune réplique n'est disponible. |
| close-on-replica-write | Par défaut : oui Type : valeur booléenne Modifiable : oui Ancien nom : close-on-slave-write Les modifications prennent effet : immédiatement | Si activé, les clients qui tentent d'écrire sur un réplica en lecture seule seront déconnectés. |
**Paramètres supprimés dans Redis OSS 5.0**
| Name | Détails | Description |
| --- | --- | --- |
| repl-timeout | Par défaut : 60 Modifiable : non | Ce paramètre n'est pas disponible dans cette version. |
### Modifications des paramètres de Redis OSS 4.0.10
**Famille de groupes de paramètres :** redis4.0
Groupes de paramètres par défaut de Redis OSS 4.0.x
+ `default.redis4.0`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster désactivé) et les groupes de réplication.
+ `default.redis4.0.cluster.on`— Utilisez ce groupe de paramètres, ou un groupe dérivé de celui-ci, pour les clusters Valkey ou Redis OSS (mode cluster activé) et les groupes de réplication.
**Paramètres modifiés dans Redis OSS 4.0.10**
| Name | Détails | Description |
| --- | --- | --- |
| maxmemory-policy | Valeurs autorisées : `allkeys-lru`, `volatile-lru`, **allkeys-lfu**, **volatile-lfu**, `allkeys-random`, `volatile-random`, `volatile-ttl`, `noeviction` Par défaut : volatile-lru Type : chaîne Modifiable : oui Quant a lieu la modification : Immédiatement | La rubrique maxmemory-policy a été ajoutée dans la version 2.6.13. Dans la version 4.0.10, deux nouvelles valeurs autorisées ont été ajoutées : allkeys-lfu (qui élimine toute clé utilisant une LFU approximative) et volatile-lfu (qui élimine l'utilisation de LFU approximatives parmi les clés avec un ensemble d'expiration). Dans la version 6.2, lorsque la famille de nœuds r6gd a été introduite pour être utilisée avec la hiérarchisation des données, seules les politiques de mémoire maximale noeviction, volatile-lru et allkeys-lru sont prises en charge avec les types de nœuds r6gd. |
**Paramètres ajoutés dans Redis OSS 4.0.10**
| Name | Détails | Description |
| --- |--- |--- |
| **Paramètres de suppression asynchrones** |
| --- |
| lazyfree-lazy-eviction | Valeurs autorisées : yes / no Par défaut : non Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Effectue une suppression asynchrone des évictions. |
| lazyfree-lazy-expire | Valeurs autorisées : yes / no Par défaut : non Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Effectue une suppression asynchrone des clés expirées. |
| lazyfree-lazy-server-del | Valeurs autorisées : yes / no Par défaut : non Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Effectue une suppression asynchrone des commandes qui mettent à jour les valeurs. |
| slave-lazy-flush | Valeurs autorisées : N/A Par défaut : non Type : valeur booléenne Modifiable : non Quant a lieu la modification : N/A | Exécute une commande flushDB asynchrone pendant la synchronisation esclave. |
| **Paramètres d'LFU** |
| --- |
| lfu-log-factor | Valeurs autorisées : tous les entiers > 0 Par défaut: 10 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Définissez le facteur journal qui détermine le nombre d'accès à une clé pour en saturer le compteur. |
| lfu-decay-time | Valeurs autorisées : Tous les entiers Valeur par défaut : 1 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Le temps nécessaire en minutes pour réduire le compteur de clé. |
| **Paramètres de défragmentation active** |
| --- |
| activedefrag | Valeurs autorisées : yes / no Par défaut : non Type : valeur booléenne Modifiable : oui Quant a lieu la modification : Immédiatement | Permet une défragmentation active. Dans les versions 7.0 et supérieures de Valkey et Redis OSS, il est AWS possible d'effectuer automatiquement la défragmentation lorsque cela est nécessaire sur le plan opérationnel, quel que soit ce paramètre. |
| active-defrag-ignore-bytes | Valeurs autorisées : 10485760-104857600 Par défaut: 104857600 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Quantité minimum de fragmentation perdue pour lancer une défragmentation active. |
| active-defrag-threshold-lower | Valeurs autorisées : 1-100 Par défaut: 10 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Pourcentage minimum de fragmentation pour lancer une défragmentation active. |
| active-defrag-threshold-upper | Valeurs autorisées : 1-100 Par défaut : 100 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Pourcentage maximum de fragmentation à partir duquel nous utilisons l'effort maximum. |
| active-defrag-cycle-min | Valeurs autorisées : 1-75 Par défaut: 25 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Effort minimum pour défragmenter en pourcentage d'UC. |
| active-defrag-cycle-max | Valeurs autorisées : 1-75 Par défaut: 75 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Effort maximum pour défragmenter en pourcentage d'UC. |
| **Paramètres du tampon de sortie client** |
| --- |
| client-query-buffer-limit | Valeurs autorisées : 1048576-1073741824 Par défaut: 1073741824 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Taille maximum d'un seul tampon de requête client. |
| proto-max-bulk-len | Valeurs autorisées : 1048576-536870912 Par défaut: 536870912 Type : entier Modifiable : oui Quant a lieu la modification : Immédiatement | Taille maximum d'une seule demande d'élément. |
### Modifications des paramètres de Redis OSS 3.2.10
**Famille de groupes de paramètres :** redis3.2
ElastiCache pour Redis OSS 3.2.10, aucun paramètre supplémentaire n'est pris en charge.
### Modifications des paramètres de Redis OSS 3.2.6
**Famille de groupes de paramètres :** redis3.2
Pour Redis OSS 3.2.6, aucun paramètre supplémentaire n'est pris en charge.
### Modifications des paramètres de Redis OSS 3.2.4
**Famille de groupes de paramètres :** redis3.2
À partir de Redis OSS 3.2.4, il existe deux groupes de paramètres par défaut.
+ `default.redis3.2`— Lorsque vous exécutez Redis OSS 3.2.4, spécifiez ce groupe de paramètres ou un groupe dérivé de celui-ci, si vous souhaitez créer un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) tout en utilisant les fonctionnalités supplémentaires de Redis OSS 3.2.4.
+ `default.redis3.2.cluster.on`— Spécifiez ce groupe de paramètres ou un groupe dérivé de celui-ci lorsque vous souhaitez créer un groupe de réplication Valkey ou Redis OSS (mode cluster activé).
**Topics**
+ [Nouveaux paramètres pour Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4.New)
+ [Paramètres modifiés dans Redis OSS 3.2.4 (amélioré)](#ParameterGroups.Redis.3-2-4.Changed)
#### Nouveaux paramètres pour Redis OSS 3.2.4
**Famille de groupes de paramètres :** redis3.2
Pour Redis OSS 3.2.4, les paramètres supplémentaires suivants sont pris en charge.
****
| Name | Détails | Description |
| --- | --- | --- |
| list-max-ziplist-size | Par défaut : -2 Type : entier Modifiable : non | Les listes sont codées de manière spécifique pour économiser de l'espace. Le nombre d'entrées autorisées par le nœud de liste interne peut être spécifié comme une taille maximale fixe ou sous forme d'un nombre maximal d'éléments. Pour une taille maximale fixe, utilisez -5 à -1, ce qui signifie : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| list-compress-depth | Par défaut : 0 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | Les listes peuvent également être compressées. La profondeur de compression correspond au nombre de nœuds des listes compressées et rapides de chaque côté de la liste à exclure de la compression. La tête et la queue de liste ne sont jamais compressées pour les opérations push et pop. Les paramètres sont : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| cluster-enabled | Par défaut : no/yes \$1 Type : chaîne Modifiable : non | Indique s'il s'agit d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé) en mode cluster (oui) ou d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé) en mode non-cluster (non). Les groupes de réplication Valkey ou Redis OSS (mode cluster activé) en mode cluster peuvent partitionner leurs données sur un maximum de 500 groupes de nœuds. \$1 Redis OSS 3.2. *x* possède deux groupes de paramètres par défaut. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html). |
| cluster-require-full-coverage | Par défaut : non Type : valeur booléenne Modifiable : oui Les modifications prennent effet : immédiatement | Lorsqu'ils sont définis sur`yes`, les nœuds Valkey ou Redis OSS (mode cluster activé) en mode cluster cessent d'accepter les requêtes s'ils détectent qu'au moins un emplacement de hachage est découvert (aucun nœud disponible ne le dessert). De cette façon, si le cluster est partiellement défaillant, le cluster n'est pas disponible. Il redevient automatiquement disponible dès que tous les emplacements sont couverts à nouveau. Cependant, vous souhaitez parfois que le sous-ensemble du cluster qui fonctionne continue à accepter des requêtes pour la partie de l'espace de clé qui est toujours couverte. Pour cela, il suffit de définir l'option `cluster-require-full-coverage` sur `no`. |
| hll-sparse-max-bytes | Par défaut: 3000 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | HyperLogLog limite d'octets de représentation clairsemée. La limite inclut l'en-tête de 16 octets. Lorsqu'une HyperLogLog représentation clairsemée dépasse cette limite, elle est convertie en représentation dense. Une valeur supérieure à 16 000 n'est pas recommandée car à ce stade, la représentation dense est plus efficace en termes de mémoire. Nous recommandons une valeur d'environ 3 000 afin de bénéficier des avantages du codage efficace en espace sans trop ralentir PFADD, qui est O(N) avec le codage fragmenté. La valeur peut être portée à environ 10000 lorsque le processeur n'est pas un problème, mais que l'espace l'est, et que l'ensemble de données est composé de nombreuses données HyperLogLogs dont la cardinalité se situe entre 0 et 15 000. |
| reserved-memory-percent | Par défaut: 25 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | Pourcentage de mémoire d'un nœud réservé à des fins autres que le traitement des données. Par défaut, l'empreinte de données Redis OSS augmente jusqu'à ce qu'elle consomme toute la mémoire du nœud. Si cela se produit, les performances du nœud seront probablement affectées en raison d'une pagination de mémoire excessive. En réservant de la mémoire, vous pouvez réserver une partie de la mémoire disponible à des fins autres que REDIS OSS afin de réduire la quantité de pagination. Ce paramètre est spécifique à la ElastiCache distribution standard de Redis OSS et ne fait pas partie de celle-ci. Pour plus d’informations, consultez `reserved-memory` et [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md). |
#### Paramètres modifiés dans Redis OSS 3.2.4 (amélioré)
**Famille de groupes de paramètres :** redis3.2
Pour Redis OSS 3.2.4, les paramètres suivants ont été modifiés.
****
| Name | Détails | Modifier |
| --- | --- | --- |
| activerehashing | Modifiable : Oui si le groupe de paramètres n'est associé à aucun cluster. Dans le cas contraire, ce champ n'est pas obligatoire. | Modifiable était défini sur Non. |
| databases | Modifiable : Oui si le groupe de paramètres n'est associé à aucun cluster. Dans le cas contraire, ce champ n'est pas obligatoire. | Modifiable était défini sur Non. |
| appendonly | Valeur par défaut : désactivé Modifiable : non | Si vous souhaitez effectuer une mise à niveau à partir d'une version antérieure de Redis OSS, vous devez d'abord la `appendonly` désactiver. |
| appendfsync | Valeur par défaut : désactivé Modifiable : non | Si vous souhaitez effectuer une mise à niveau à partir d'une version antérieure de Redis OSS, vous devez d'abord la `appendfsync` désactiver. |
| repl-timeout | Par défaut : 60 Modifiable : non | Est désormais non modifiable avec une valeur par défaut de 60. |
| tcp-keepalive | Valeur par défaut : 300 | La valeur par défaut était 0. |
| list-max-ziplist-entries | | Le paramètre n'est plus disponible. |
| list-max-ziplist-value | | Le paramètre n'est plus disponible. |
### Paramètres ajoutés à Redis OSS 2.8.24 (amélioré)
**Famille de groupes de paramètres :** redis2.8
Pour Redis OSS 2.8.24, aucun paramètre supplémentaire n'est pris en charge.
### Paramètres ajoutés à Redis OSS 2.8.23 (amélioré)
**Famille de groupes de paramètres :** redis2.8
Pour Redis OSS 2.8.23, le paramètre supplémentaire suivant est pris en charge.
****
| Name | Détails | Description |
| --- | --- | --- |
| close-on-slave-write | Par défaut : oui Type : chaîne (oui/non) Modifiable : oui Les modifications prennent effet : immédiatement | Si activé, les clients qui tentent d'écrire sur un réplica en lecture seule seront déconnectés. |
#### Fonctionnement d’ close-on-slave-write
`close-on-slave-write`Ce paramètre a été introduit par Amazon ElastiCache pour vous permettre de mieux contrôler la façon dont votre cluster réagit lorsqu'un nœud principal et un nœud de réplique de lecture échangent des rôles en raison de la promotion d'une réplique de lecture vers un nœud principal.
![\[Image : close-on-replica-write, tout fonctionne bien\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-01.png)
Si le cluster réplica en lecture devient cluster réplica principal pour une raison autre qu'un basculement du groupe de réplication avec Multi-AZ activé, le client continuera d'essayer d'écrire sur le point de terminaison A. Etant donné que le point de terminaison A est désormais le point de terminaison d'un réplica en lecture, ces écritures échoueront. C'est le comportement de Redis OSS avant son ElastiCache introduction `close-on-replica-write` et le comportement si vous le désactivez`close-on-replica-write`.
![\[Image : échec close-on-slave-write des écritures\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-02.png)
Avec `close-on-replica-write` activé, à chaque fois qu'un client tente d'écrire dans un réplica en lecture, la connexion client au cluster prend fin. Votre logique d'application doit détecter la déconnexion, vérifiez la table DNS et reconnectez-vous au point de terminaison principal, qui sera désormais le point de terminaison B.
![\[Image : close-on-slave-write, écriture dans le nouveau cluster principal\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-03.png)
#### Quand vous pouvez désactiver close-on-replica-write
Si la désactivation du paramètre `close-on-replica-write` génère des écritures dans le cluster en échec, pourquoi désactiver le paramètre `close-on-replica-write` ?
Comme mentionné précédemment, lorsque ce paramètre `close-on-replica-write` est activé, dès qu'un client tente d'écrire dans un réplica en lecture, la connexion client au cluster s'interrompt. Établir une nouvelle connexion avec le nœud prend du temps. Par conséquent, déconnecter et reconnecter suite à une demande d'écriture sur le réplica affecte également la latence des demandes de lecture diffusées par le biais de la même connexion. Cet effet reste actif jusqu'à ce que la nouvelle connexion soit établie. Si votre application a une charge particulièrement lourde en écriture ou si elle est très sensible au temps de latence, vous souhaiterez peut-être que vos clients restent connectés afin de ne pas dégrader les performances de lecture.
### Paramètres ajoutés à Redis OSS 2.8.22 (amélioré)
**Famille de groupes de paramètres :** redis2.8
Pour Redis OSS 2.8.22, aucun paramètre supplémentaire n'est pris en charge.
**Important**
À partir de la version 2.8.22 de Redis OSS, `repl-backlog-size` elle s'applique au cluster principal ainsi qu'aux clusters de réplication.
À partir de la version 2.8.22 de Redis OSS, le `repl-timeout` paramètre n'est pas pris en charge. S'il est modifié, il ElastiCache sera remplacé par la valeur par défaut (60s), comme nous le faisons avec`appendonly`.
Les paramètres suivants ne sont plus pris en charge.
+ *appendonly*
+ *appendfsync*
+ *repl-timeout*
### Paramètres ajoutés à Redis OSS 2.8.21
**Famille de groupes de paramètres :** redis2.8
Pour Redis OSS 2.8.21, aucun paramètre supplémentaire n'est pris en charge.
### Paramètres ajoutés à Redis OSS 2.8.19
**Famille de groupes de paramètres :** redis2.8
Pour Redis OSS 2.8.19, aucun paramètre supplémentaire n'est pris en charge.
### Paramètres ajoutés à Redis OSS 2.8.6
**Famille de groupes de paramètres :** redis2.8
Pour Redis OSS 2.8.6, les paramètres supplémentaires suivants sont pris en charge.
****
| Name | Détails | Description |
| --- | --- | --- |
| min-slaves-max-lag | Par défaut: 10 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | Le nombre de secondes au cours desquelles le nœud principal doit suivre une requête ping à partir d'un réplica en lecture. Si ce laps de temps s'écoule et que le nœud principal ne reçoit pas un message ping, alors le réplica n'est plus considéré comme étant disponible. Si le nombre de répliques disponibles tombe en dessous min-slaves-to-write, le serveur principal cessera d'accepter les écritures à ce moment-là. Si ce paramètre min-slaves-to-write est égal à 0, le nœud principal acceptera toujours les demandes d'écriture, même si aucune réplique n'est disponible. |
| min-slaves-to-write | Par défaut : 0 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | Le nombre minimum de réplicas en lecture qui doivent être disponibles pour que le nœud principal puisse accepter des écritures des clients. Si le nombre de réplicas disponibles est inférieur à ce nombre, alors le nœud principal n'acceptera plus de demandes d'écriture. Si ce paramètre min-slaves-max-lag est égal à 0, le nœud principal acceptera toujours les demandes d'écriture, même si aucune réplique n'est disponible. |
| notify-keyspace-events | Par défaut : (une chaîne vide) Type : chaîne Modifiable : oui Les modifications prennent effet : immédiatement | Les types d'événements keyspace dont Redis OSS peut informer les clients. Chaque type d'événement est représenté par une lettre unique : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) Vous pouvez avoir une combinaison de ces types d'événements. Par exemple, *AKE* signifie que Redis OSS peut publier des notifications de tous les types d'événements. N'utilisez pas de caractères autres que ceux mentionnés dans la liste ci-dessus, car cela produirait des messages d'erreur. Par défaut, ce paramètre est défini sur une chaîne vide, ce qui signifie que la notification d'événement d'espace de clé est désactivée. |
| repl-backlog-size | Par défaut: 1048576 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | La taille, en octets, de la mémoire tampon du journal des éléments en attente de nœud principal. Le journal des éléments en attente est utilisé pour enregistrer des mises à jour dans les données sur le nœud principal. Lorsqu'un réplica en lecture se connecte au réplica principal, il tente d'effectuer une synchronisation partielle (`psync`), où il applique les données du journal des éléments en attente avec le nœud principal. Si le `psync` échoue, une synchronisation complète doit être effectuée. La valeur minimale pour ce paramètre est 16384. À partir de Redis OSS 2.8.22, ce paramètre s'applique au cluster principal ainsi qu'aux répliques de lecture. |
| repl-backlog-ttl | Par défaut: 3600 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | Le nombre de secondes pendant lesquelles le nœud principal conserve la mémoire tampon du journal des éléments en attente. Dès que le dernier nœud réplica est déconnecté, les données du journal des éléments en attente sont conservées jusqu'à l'expiration du paramètre `repl-backlog-ttl`. Si le réplica n'est pas connecté au réplica principal au cours de cette période, alors le réplica principal libère la mémoire tampon du journal des éléments en attente. Lorsque le réplica se reconnecte, il devra effectuer une synchronisation complète avec le réplica principal. Si ce paramètre est défini sur 0, alors la mémoire tampon du journal des éléments en attente ne sera jamais libérée. |
| repl-timeout | Par défaut : 60 Type : entier Modifiable : oui Les modifications prennent effet : immédiatement | Représente le délai d'expiration, en secondes, pour : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
### Paramètres de Redis OSS 2.6.13
**Famille de groupes de paramètres :** redis2.6
Redis OSS 2.6.13 était la première version de Redis OSS prise en charge par. ElastiCache Le tableau suivant indique les paramètres pris en charge par Redis OSS 2.6.13. ElastiCache
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html)
**Note**
Si vous ne spécifiez aucun groupe de paramètres pour votre cluster Redis OSS 2.6.13, un groupe de paramètres par défaut (`default.redis2.6`) sera utilisé. Vous ne pouvez pas modifier les valeurs des paramètres dans un groupe de paramètres par défaut ; cependant, vous pouvez créer un groupe de paramètres personnalisé et l'affecter à votre cluster à tout moment.
### Paramètres spécifiques au type de nœud Redis OSS
Bien que la plupart des paramètres ont une valeur unique, certains paramètres ont des valeurs différentes en fonction du type de nœud utilisé. Le tableau suivant indique les valeurs par défaut des paramètres `maxmemory`, `client-output-buffer-limit-slave-hard-limit` et `client-output-buffer-limit-slave-soft-limit` pour chaque type de nœud. La valeur de `maxmemory` est le nombre maximal d'octets disponibles que vous pouvez utiliser pour les données et d'autres utilisations, sur le nœud. Pour de plus amples informations, veuillez consulter [Mémoire disponibe](https://aws.amazon.com/premiumsupport/knowledge-center/available-memory-elasticache-redis-node/).
**Note**
Le paramètre `maxmemory` ne peut pas être modifié.
| Type de nœud | Maxmemory | C lient-output-buffer-limit - slave-hard-limit | C lient-output-buffer-limit - slave-soft-limit |
| --- | --- | --- | --- |
| cache.t1.micro | 142606336 | 14260633 | 14260633 |
| cache.t2.micro | 581959680 | 58195968 | 58195968 |
| cache.t2.small | 1665138688 | 166513868 | 166513868 |
| cache.t2.medium | 3461349376 | 346134937 | 346134937 |
| cache.t3.micro | 536870912 | 53687091 | 53687091 |
| cache.t3.small | 1471026299 | 147102629 | 147102629 |
| cache.t3.medium | 3317862236 | 331786223 | 331786223 |
| cache.t4g.micro | 536870912 | 53687091 | 53687091 |
| cache.t4g. petit | 1471026299 | 147102629 | 147102629 |
| cache.t4g.medium | 3317862236 | 331786223 | 331786223 |
| cache.m1.small | 943718400 | 94371840 | 94371840 |
| cache.m1.medium | 3093299200 | 309329920 | 309329920 |
| cache.m1.large | 7025459200 | 702545920 | 702545920 |
| cache.m1.xlarge | 14889779200 | 1488977920 | 1488977920 |
| cache.m2.xlarge | 17091788800 | 1709178880 | 1709178880 |
| cache.m2.2xlarge | 35022438400 | 3502243840 | 3502243840 |
| cache.m2.4xlarge | 70883737600 | 7088373760 | 7088373760 |
| cache.m3.medium | 2988441600 | 309329920 | 309329920 |
| cache.m3.large | 6501171200 | 650117120 | 650117120 |
| cache.m3.xlarge | 14260633600 | 1426063360 | 1426063360 |
| cache.m3.2xlarge | 29989273600 | 2998927360 | 2998927360 |
| cache.m4.large | 6892593152 | 689259315 | 689259315 |
| cache.m4.xlarge | 15328501760 | 1532850176 | 1532850176 |
| cache.m4.2xlarge | 31889126359 | 3188912636 | 3188912636 |
| cache.m4.4xlarge | 65257290629 | 6525729063 | 6525729063 |
| cache.m4.10xlarge | 166047614239 | 16604761424 | 16604761424 |
| cache.m5.large | 6854542746 | 685454275 | 685454275 |
| cache.m5.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m5.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m5.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m5.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m5.24xlarge | 337500562842 | 33750056284 | 33750056284 |
| cache.m6g.large | 6854542746 | 685454275 | 685454275 |
| cache.m6g.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m6g.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m6g.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m6g.8xlarge | 111325552312 | 11132555231 | 11132555231 |
| cache.m6g.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m6g.16xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.c1.xlarge | 6501171200 | 650117120 | 650117120 |
| cache.r3.large | 14470348800 | 1468006400 | 1468006400 |
| cache.r3.xlarge | 30513561600 | 3040870400 | 3040870400 |
| cache.r3.2xlarge | 62495129600 | 6081740800 | 6081740800 |
| cache.r3.4xlarge | 126458265600 | 12268339200 | 12268339200 |
| cache.r3.8xlarge | 254384537600 | 24536678400 | 24536678400 |
| cache.r4.large | 13201781556 | 1320178155 | 1320178155 |
| cache.r4.xlarge | 26898228839 | 2689822883 | 2689822883 |
| cache.r4.2xlarge | 54197537997 | 5419753799 | 5419753799 |
| cache.r4.4xlarge | 108858546586 | 10885854658 | 10885854658 |
| cache.r4.8xlarge | 218255432090 | 21825543209 | 21825543209 |
| cache.r4.16xlarge | 437021573120 | 43702157312 | 43702157312 |
| cache.r5.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r5.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r5.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r5.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r5.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r5.24xlarge | 682485973811 | 68248597381 | 68248597381 |
| cache.r6g.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r6g.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r6g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r6g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r6g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r6g.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r6g.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.r6gd.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r6g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r6g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r6g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r6g.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r6g.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.r7g.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r7g.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r7g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r7g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r7g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r7g.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r7g.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.m7g.large | 6854542746 | 685454275 | 685454275 |
| cache.m7g.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m7g.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m7g.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m7g.8xlarge | 111325552312 | 11132555231 | 11132555231 |
| cache.m7g.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m7g.16xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.c7gn.large | 3317862236 | 1403718103 | 1403718103 |
| cache.c7gn.xlarge | 6854542746 | 2826184970 | 2826184970 |
| cache.c7gn.2xlarge | 13891921715 | 5671118356 | 5671118356 |
| cache.c7gn.4xlarge | 27966669210 | 11360986522 | 11360986522 |
| cache.c7gn.8xlarge | 56116178125 | 22500037523 | 22500037523 |
| cache.c7gn.12xlarge | 84357985997 | 34120634655 | 34120634655 |
| cache.c7gn.16xlarge | 113609865216 | 45000075046 | 45000075046 |
**Note**
Tous les types d'instances de la génération actuelle sont créés dans Amazon Virtual Private Cloud (VPC) par défaut.
Les instances T1 ne prennent pas en charge Multi-AZ.
Les instances T1 et T2 ne prennent pas en charge Redis OSS AOF.
Les variables de configuration Redis OSS ne `appendfsync` sont pas prises en charge sur Redis OSS version 2.8.22 `appendonly` et versions ultérieures.
## Paramètres spécifiques Memcached
**Memcached**
Si vous ne spécifiez pas un groupe de paramètres pour votre cluster Memcached, alors un groupe de paramètres approprié pour votre version de moteur sera utilisé. Vous ne pouvez pas modifier les valeurs des paramètres dans un groupe de paramètres par défaut. Cependant, vous pouvez créer un groupe de paramètres personnalisés et l'assigner à votre cluster à tout moment. Pour de plus amples informations, veuillez consulter [Création d'un groupe ElastiCache de paramètres](ParameterGroups.Creating.md).
**Topics**
+ [Changements apportés à Memcached 1.6.17](#ParameterGroups.Memcached.1.6.17)
+ [Paramètres ajoutés Memcached 1.6.6](#ParameterGroups.Memcached.1-6-6)
+ [Modifications des paramètres Memcached 1.5.10](#ParameterGroups.Memcached.1-5-10)
+ [Paramètres ajoutés Memcached 1.4.34](#ParameterGroups.Memcached.1-4-34)
+ [Paramètres ajoutés Memcached 1.4.33](#ParameterGroups.Memcached.1-4-33)
+ [Paramètres ajoutés Memcached 1.4.24](#ParameterGroups.Memcached.1-4-24)
+ [Paramètres ajoutés Memcached 1.4.14](#ParameterGroups.Memcached.1-4-14)
+ [Paramètres Memcached 1.4.5 pris en charge](#ParameterGroups.Memcached.1-4-5)
+ [Surcharge de la connexion Memcached](#ParameterGroups.Memcached.Overhead)
+ [Paramètres propres au type de nœud Memcached](#ParameterGroups.Memcached.NodeSpecific)
### Changements apportés à Memcached 1.6.17
À partir de Memcached 1.6.17, les commandes administratives `lru_crawler`, `lru` et `slabs` ne sont plus prises en charge. Avec ces modifications, vous ne pourrez pas le faire au enable/disable `lru_crawler` moment de l'exécution via des commandes. Veuillez enable/disable `lru_crawler` modifier votre groupe de paramètres personnalisé.
### Paramètres ajoutés Memcached 1.6.6
Pour Memcached 1.6.6, aucun paramètre supplémentaire n'est pris en charge.
**Famille de groupes de paramètres :** memcached1.6
### Modifications des paramètres Memcached 1.5.10
Pour Memcached 1.5.10, les paramètres supplémentaires suivants sont pris en charge.
**Famille de groupes de paramètres :** memcached1.5
| Name | Détails | Description |
| --- | --- | --- |
| no\$1modern | Valeur par défaut : 1 Type : valeur booléenne Modifiable : oui Valeurs autorisées : 0,1 Les modifications prennent effet : au lancement | Alias pour désactiver`slab_reassign`, `lru_maintainer_thread``lru_segmented`, et `maxconns_fast` les commandes. Lorsque vous utilisez Memcached 1.5 ou version ultérieure, définit `no_modern` également le hash\$1algorithm sur. `jenkins` De plus, lors de l'utilisation de Memcached 1.5.10, `inline_ascii_reponse` est contrôlé par le paramètre. `parallelly` Cela signifie que s'il `no_modern` est désactivé, il `inline_ascii_reponse` est désactivé. À partir de la version 1.5.16 du moteur Memcached, le `inline_ascii_response` paramètre ne s'applique plus, donc le `no_modern` fait d'être activé ou désactivé n'a aucun effet sur. `inline_ascii_reponse` S'`no_modern`il est désactivé`slab_reassign`, alors `lru_maintainer_thread``lru_segmented`,, et `maxconns_fast` SERA activé. Comme `hash_algorithm` les paramètres `slab_automove` et ne sont pas des paramètres SWITCH, leur réglage est basé sur les configurations du groupe de paramètres. Si vous souhaitez désactiver ce paramètre `no_modern` et y revenir`modern`, vous devez configurer un groupe de paramètres personnalisé pour désactiver ce paramètre, puis redémarrer pour que ces modifications prennent effet. La valeur de configuration par défaut de ce paramètre est passée de 0 à 1 à compter du 20 août 2021. La valeur par défaut mise à jour sera automatiquement sélectionnée par ElastiCache les nouveaux utilisateurs pour chaque région après le 20 août 2021. ElastiCache Les utilisateurs existants dans les régions avant le 20 août 2021 doivent modifier manuellement leurs groupes de paramètres personnalisés afin de prendre en compte cette nouvelle modification. |
| inline\$1ascii\$1resp | Par défaut : 0 Type : valeur booléenne Modifiable : oui Valeurs autorisées : 0,1 Les modifications prennent effet : au lancement | Stocke les nombres issus de la réponse `VALUE` dans un élément en utilisant jusqu'à 24 octets. Léger ralentissement pour les ensembles `get` et `faster` ASCII. |
Pour Memcached 1.5.10, les paramètres suivants sont supprimés.
| Name | Détails | Description |
| --- | --- | --- |
| expirezero\$1does\$1not\$1evict | Par défaut : 0 Type : valeur booléenne Modifiable : oui Valeurs autorisées : 0,1 Les modifications prennent effet : au lancement | N'est plus pris en charge dans cette version. |
| modern | Valeur par défaut : 1 Type : valeur booléenne Modifiable : Oui (nécessite de relancer s'il est défini sur `no_modern`) Valeurs autorisées : 0,1 Les modifications prennent effet : au lancement | N'est plus pris en charge dans cette version. À partir de cette version, `no-modern` est activé par défaut à chaque démarrage et redémarrage. |
### Paramètres ajoutés Memcached 1.4.34
Pour Memcached 1.4.34, aucun paramètre supplémentaire n'est pris en charge.
**Famille de groupes de paramètres :** memcached1.4
### Paramètres ajoutés Memcached 1.4.33
Pour Memcached 1.4.33, les paramètres supplémentaires suivants sont pris en charge.
**Famille de groupes de paramètres :** memcached1.4
| Name | Détails | Description |
| --- | --- | --- |
| modern | Par défaut : activé Type : valeur booléenne Modifiable : oui Les modifications prennent effet : au lancement | Un alias pour plusieurs fonctions. Activer `modern` équivaut à activer les commandes suivantes et à utiliser un algorithme de hachage murmur3 : `slab_reassign`, `slab_automove`, `lru_crawler`, `lru_maintainer`, `maxconns_fast` et `hash_algorithm=murmur3`. |
| watch | Par défaut : activé Type : valeur booléenne Modifiable : oui Les modifications prennent effet : immédiatement Des journaux sont supprimés si l'utilisateur atteint ses limites `watcher_logbuf_size` et `worker_logbuf_size`. | Extractions, expulsions ou mutations de journaux. Quand, par exemple, un utilisateur active `watch`, il peut voir des journaux lorsque `get`, `set`, `delete` ou `update` a lieu. |
| idle\$1timeout | Valeurs : 0, 1. Type : entier Modifiable : oui Les modifications prennent effet : au lancement | Nombre minimum de secondes pendant lesquelles un client sera autorisé à rester inactif avant d'être invité à se fermer. Plage de valeurs : 0 à 86400. |
| track\$1sizes | Par défaut : désactivé Type : valeur booléenne Modifiable : oui Les modifications prennent effet : au lancement | Affiche les tailles consommées par chaque groupe de sections. Activer `track_sizes` vous permet d'exécuter `stats sizes` sans avoir à exécuter `stats sizes_enable`. |
| watcher\$1logbuf\$1size | Défaut : 256 (Ko) Type : entier Modifiable : oui Les modifications prennent effet : au lancement | La commande `watch` active la journalisation des flux pour Memcached. Cependant `watch` peut supprimer des journaux si le taux d'expulsions, de mutations ou d'extraction est suffisamment élevé pour que la mémoire tampon du journal soit saturée. Dans de telles situations, les utilisateurs peuvent augmenter la taille de la mémoire tampon pour réduire les risques de perte de journaux. |
| worker\$1logbuf\$1size | Défaut : 64 (Ko) Type : entier Modifiable : oui Les modifications prennent effet : au lancement | La commande `watch` active la journalisation des flux pour Memcached. Cependant `watch` peut supprimer des journaux si le taux d'expulsions, de mutations ou d'extraction est suffisamment élevé pour que la mémoire tampon du journal soit pleine. Dans de telles situations, les utilisateurs peuvent augmenter la taille de la mémoire tampon pour réduire les risques de perte de journaux. |
| slab\$1chunk\$1max | Par défaut : 524288 (octets) Type : entier Modifiable : oui Les modifications prennent effet : au lancement | Spécifie la taille maximale d'une section. La définition de sections plus petites permet d'utiliser plus efficacement la mémoire. Les éléments dont la taille est supérieure à `slab_chunk_max` sont répartis sur plusieurs sections. |
| lru\$1crawler metadump [all\$11\$12\$13] | Par défaut : désactivé Type : valeur booléenne Modifiable : oui Les modifications prennent effet : immédiatement | Si lru\$1crawler est activé, cette commande vide toutes les clés. `all\|1\|2\|3` - toutes les sections, ou spécifiez un numéro de section particulier |
### Paramètres ajoutés Memcached 1.4.24
Pour Memcached 1.4.24, les paramètres supplémentaires suivants sont pris en charge.
**Famille de groupes de paramètres :** memcached1.4
| Name | Détails | Description |
| --- | --- | --- |
| disable\$1flush\$1all | Valeurs : 0, 1. Type : valeur booléenne Modifiable : oui Les modifications prennent effet : au lancement | Ajoutez un paramètre (`-F`) pour désactiver flush\$1all. Utile si vous ne souhaitez jamais effectuer de vidage complet de la mémoire sur les instances de production. Valeurs : 0, 1 (un utilisateur peut lancer un `flush_all` lorsque la valeur est 0). |
| hash\$1algorithm | Valeur par défaut : jenkins Type : chaîne Modifiable : oui Les modifications prennent effet : au lancement | L'algorithme de hachage à utiliser. Valeurs autorisées : murmur3 et jenkins. |
| lru\$1crawler | Valeurs : 0, 1. Type : valeur booléenne Modifiable : oui Les modifications prennent effet : après le redémarrage Vous pouvez activer temporairement `lru_crawler` lors de l'exécution de la ligne de commande. Pour plus d'informations, consultez la colonne Description. | Nettoie les classes de sections des éléments qui ont expiré. Il s'agit d'un processus de faible impact qui s'exécute en arrière-plan. Cela nécessite actuellement de lancer une analyse à l'aide d'une commande manuelle. Pour activer temporairement, exécutez `lru_crawler enable` à la ligne de commande. `lru_crawler 1,3,5` analyse les classes de sections 1, 3 et 5 à la recherche des éléments arrivés à expiration à ajouter à la freelist. Valeurs : 0,1 Activer `lru_crawler` à la ligne de commande permet d'activer le crawler jusqu'à ce qu'il soit désactivé à la ligne de commande ou au prochain redémarrage. Pour activer en permanence, vous devez modifier la valeur du paramètre. Pour de plus amples informations, veuillez consulter [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md). |
| lru\$1maintainer | Valeurs : 0, 1. Type : valeur booléenne Modifiable : oui Les modifications prennent effet : au lancement | Un fil d'arrière-plan qui mélange les éléments entre les deux au LRUs fur et à mesure que les capacités sont atteintes. Valeurs : 0, 1. |
| expirezero\$1does\$1not\$1evict | Valeurs : 0, 1. Type : valeur booléenne Modifiable : oui Les modifications prennent effet : au lancement | Si utilisé avec le paramètre `lru_maintainer`, les éléments ayant une date d'expiration de 0 ne peuvent pas être supprimés. Cela évite d'utiliser la mémoire disponible pour les autres éléments pouvant être supprimés. Peut être paramétré pour ne pas tenir compte de `lru_maintainer`. |
### Paramètres ajoutés Memcached 1.4.14
Pour Memcached 1.4.14, les paramètres supplémentaires suivants sont pris en charge.
**Famille de groupes de paramètres :** memcached1.4
**Paramètres ajoutés dans Memcached 1.4.14**
| Name | Détails | Description |
| --- | --- | --- |
| config\$1max | Par défaut: 16 Type : entier Modifiable : non | Le nombre maximum d'entrées de ElastiCache configuration. |
| config\$1size\$1max | Par défaut: 65536 Type : entier Modifiable : non | La taille maximale des entrées configuration, en octets. |
| hashpower\$1init | Par défaut: 16 Type : entier Modifiable : non | La taille initiale de la table de ElastiCache hachage, exprimée sous la forme d'une puissance de deux. La valeur par défaut est 16 (2 ^ 16) ou 65536 clés. |
| maxconns\$1fast | Par défaut : 0 (faux) Type : Boolean Modifiable : oui Les modifications prennent effet : après le redémarrage | Change la façon dont les nouvelles demandes de connexions sont gérées lorsque la limite de connexion maximale est atteinte. Si ce paramètre est défini sur 0 (zéro), les nouvelles connexions sont ajoutées au journal des éléments en attente et attendront jusqu'à ce que les autres connexions soient terminées. Si le paramètre est défini sur 1, ElastiCache envoie une erreur au client et ferme immédiatement la connexion. |
| slab\$1automove | Par défaut : 0 Type : entier Modifiable : oui Les modifications prennent effet : après le redémarrage | Ajuste l'algorithme slab automove : si ce paramètre est défini sur 0 (zéro), l'algorithme automove est désactivé. Si ce paramètre est défini sur 1, ElastiCache adopte une approche lente et prudente pour déplacer automatiquement les sections. S'il est réglé sur 2, déplace les dalles de ElastiCache manière agressive chaque fois qu'il y a une expulsion. (Ce mode n'est pas recommandé sauf pour effectuer des tests). |
| slab\$1reassign | Par défaut : 0 (faux) Type : Boolean Modifiable : oui Les modifications prennent effet : après le redémarrage | Activer ou désactiver la réaffectation de sections. Si ce paramètre est défini sur 1, vous pouvez utiliser la commande « slab\$1reassign » pour réaffecter manuellement la mémoire. |
### Paramètres Memcached 1.4.5 pris en charge
**Famille de groupes de paramètres :** memcached1.4
Pour Memcached 1.4.5, les paramètres suivants sont pris en charge.
**Paramètres ajoutés dans Memcached 1.4.5**
| Name | Détails | Description |
| --- | --- | --- |
| backlog\$1queue\$1limit | Par défaut: 1024 Type : entier Modifiable : non | La limite de file d'attente de éléments en attente. |
| binding\$1protocol | Valeur par défaut : auto Type : chaîne Modifiable : oui Les modifications prennent effet : après le redémarrage | Le protocole de liaison. Les valeurs autorisées sont : `ascii` et `auto`. Pour une assistance sur la modification de la valeur de `binding_protocol`, consultez [Modification d'un groupe ElastiCache de paramètres](ParameterGroups.Modifying.md). |
| cas\$1disabled | Par défaut : 0 (faux) Type : Boolean Modifiable : oui Les modifications prennent effet : après le redémarrage | Si 1 (vrai), la vérification et la définition des opérations (CAS) seront désactivées, et les éléments stockés consommeront 8 fois moins d'octets que lorsque CAS est activé. |
| chunk\$1size | Par défaut: 48 Type : entier Modifiable : oui Les modifications prennent effet : après le redémarrage | Le montant minimum, en octets, de l'espace à allouer à la clé, à la valeur et aux indicateurs du plus petit élément. |
| chunk\$1size\$1growth\$1factor | Par défaut: 1.25 Type : décimal Modifiable : oui Les modifications prennent effet : après le redémarrage | Le facteur de croissance qui contrôle la taille de chaque segment Memcached successif ; chaque segment sera chunk\$1size\$1growth\$1factor fois plus important que le segment précédent. |
| error\$1on\$1memory\$1exhausted | Par défaut : 0 (faux) Type : Boolean Modifiable : oui Les modifications prennent effet : après le redémarrage | Si 1 (vrai), il n'y a pas plus de mémoire disponible pour stocker les éléments, Memcached retournera une erreur plutôt que d'expulser des éléments. |
| large\$1memory\$1pages | Par défaut : 0 (faux) Type : Boolean Modifiable : non | Si 1 (vrai), j' ElastiCache essaierai d'utiliser de grandes pages de mémoire. |
| lock\$1down\$1paged\$1memory | Par défaut : 0 (faux) Type : Boolean Modifiable : non | Si 1 (vrai), toutes les pages de mémoire ElastiCache seront verrouillées. |
| max\$1item\$1size | Par défaut: 1048576 Type : entier Modifiable : oui Les modifications prennent effet : après le redémarrage | La taille, en octets, de l'élément de plus grand qui peut être stocké dans le cluster. |
| max\$1simultaneous\$1connections | Par défaut: 65000 Type : entier Modifiable : non | Le nombre maximum de connexions simultanées. |
| maximize\$1core\$1file\$1limit | Par défaut : 0 (faux) Type : Boolean Adaptabilité: Les modifications prennent effet : après le redémarrage | Si 1 (vrai), ElastiCache maximisera la limite du fichier principal. |
| memcached\$1connections\$1overhead | Par défaut : 100 Type : entier Modifiable : oui Les modifications prennent effet : après le redémarrage | La quantité de mémoire à réserver pour les connexions Memcached et autre traitement divers. Pour plus d’informations sur ce paramètre, consultez [Surcharge de la connexion Memcached](#ParameterGroups.Memcached.Overhead). |
| requests\$1per\$1event | Valeur par défaut : 20 Type : entier Modifiable : non | Le nombre maximum de requêtes par événement pour une connexion donnée. Cette limite est nécessaire pour éviter une pénurie de ressources. |
### Surcharge de la connexion Memcached
Sur chaque nœud de , la mémoire mise à disposition pour stocker les éléments de est la mémoire disponible totale sur ce nœud (qui est stockée dans le paramètre `max_cache_memory`) moins la mémoire utilisée pour les connexions et autres traitements (qui est stockée dans le paramètre `memcached_connections_overhead`). Par exemple, un nœud de type `cache.m1.small` a un `max_cache_memory` de 1 300 Mo. Avec la valeur par défaut `memcached_connections_overhead` de 100 Mo, le processus de Memcached aura 1 200 Mo disponibles pour stocker les éléments.
Les valeurs par défaut du paramètre `memcached_connections_overhead` conviennent à la plupart des cas d'utilisation ; cependant, le nombre requis d'allocation au surcharge de connexion peut dépendre de plusieurs facteurs, comme le taux de demande, la taille de la charge utile et le nombre de connexions.
Vous pouvez modifier la valeur du paramètre `memcached_connections_overhead` afin de mieux correspondre aux besoins de votre application. Par exemple, l'augmentation de la valeur du paramètre `memcached_connections_overhead` réduira le volume de mémoire disponible pour stocker les éléments de et offrir une plus grande mémoire tampon pour la surcharge de connexion. Diminuer la valeur du paramètre `memcached_connections_overhead` vous permet d'avoir plus de mémoire pour stocker les éléments de , mais peut augmenter l'utilisation de l'espace d'échange et dégrader les performances. Si vous notez qu'il y a utilisation de l'espace d'échange et dégradation des performances, essayez d'augmenter la valeur du paramètre `memcached_connections_overhead`.
**Important**
Pour le type de nœud `cache.t1.micro`, la valeur du paramètre `memcached_connections_overhead` est déterminé comme suit :
Si votre cluster utilise le groupe de paramètres par défaut, la valeur ElastiCache sera définie `memcached_connections_overhead` sur 13 Mo.
Si votre cluster utilise un groupe de paramètres que vous avez créé, vous pouvez attribuer la valeur de votre choix au paramètre `memcached_connections_overhead`.
### Paramètres propres au type de nœud Memcached
Bien que la plupart des paramètres ont une valeur unique, certains paramètres ont des valeurs différentes en fonction du type de nœud utilisé. Le tableau suivant illustre les valeurs par défaut des paramètres `max_cache_memory` et `num_threads` pour chaque type de nœud. Les valeurs de ces paramètres ne peuvent pas être modifiées.
| Type de nœud | max\$1cache\$1memory (en méga-octets) | num\$1threads |
| --- | --- | --- |
| cache.t1.micro | 213 | 1 |
| cache.t2.micro | 555 | 1 |
| cache.t2.small | 1588 | 1 |
| cache.t2.medium | 3301 | 2 |
| cache.t3.micro | 512 | 2 |
| cache.t3.small | 1402 | 2 |
| cache.t3.medium | 3364 | 2 |
| cache.t4g.micro | 512 | 2 |
| cache.t4g. petit | 1402 | 2 |
| cache.t4g.medium | 3164 | 2 |
| cache.m1.small | 1301 | 1 |
| cache.m1.medium | 3350 | 1 |
| cache.m1.large | 7100 | 2 |
| cache.m1.xlarge | 14600 | 4 |
| cache.m2.xlarge | 33800 | 2 |
| cache.m2.2xlarge | 30412 | 4 |
| cache.m2.4xlarge | 68000 | 16 |
| cache.m3.medium | 2850 | 1 |
| cache.m3.large | 6200 | 2 |
| cache.m3.xlarge | 13600 | 4 |
| cache.m3.2xlarge | 28600 | 8 |
| cache.m4.large | 6573 | 2 |
| cache.m4.xlarge | 11496 | 4 |
| cache.m4.2xlarge | 30412 | 8 |
| cache.m4.4xlarge | 62234 | 16 |
| cache.m4.10xlarge | 158355 | 40 |
| cache.m5.large | 6537 | 2 |
| cache.m5.xlarge | 13248 | 4 |
| cache.m5.2xlarge | 26671 | 8 |
| cache.m5.4xlarge | 53516 | 16 |
| cache.m5.12xlarge | 160900 | 48 |
| cache.m5.24xlarge | 321865 | 96 |
| cache.m6g.large | 6537 | 2 |
| cache.m6g.xlarge | 13248 | 4 |
| cache.m6g.2xlarge | 26671 | 8 |
| cache.m6g.4xlarge | 53516 | 16 |
| cache.m6g.8xlarge | 107000 | 32 |
| cache.m6g.12xlarge | 160900 | 48 |
| cache.m6g.16xlarge | 214577 | 64 |
| cache.c1.xlarge | 6600 | 8 |
| cache.r3.large | 13800 | 2 |
| cache.r3.xlarge | 29100 | 4 |
| cache.r3.2xlarge | 59600 | 8 |
| cache.r3.4xlarge | 120600 | 16 |
| cache.r3.8xlarge | 120600 | 32 |
| cache.r4.large | 12590 | 2 |
| cache.r4.xlarge | 25652 | 4 |
| cache.r4.2xlarge | 51686 | 8 |
| cache.r4.4xlarge | 103815 | 16 |
| cache.r4.8xlarge | 208144 | 32 |
| cache.r4.16xlarge | 416776 | 64 |
| cache.r5.large | 13387 | 2 |
| cache.r5.xlarge | 26953 | 4 |
| cache.r5.2xlarge | 54084 | 8 |
| cache.r5.4xlarge | 108347 | 16 |
| cache.r5.12xlarge | 325400 | 48 |
| cache.r5.24xlarge | 650869 | 96 |
| cache.r6g.large | 13387 | 2 |
| cache.r6g.xlarge | 26953 | 4 |
| cache.r6g.2xlarge | 54084 | 8 |
| cache.r6g.4xlarge | 108347 | 16 |
| cache.r6g.8xlarge | 214577 | 32 |
| cache.r6g.12xlarge | 325400 | 48 |
| cache.r6g.16xlarge | 429154 | 64 |
| cache.c7gn.large | 3164 | 2 |
| cache.c7gn.xlarge | 6537 | 4 |
| cache.c7gn.2xlarge | 13248 | 8 |
| cache.c7gn.4xlarge | 26671 | 16 |
| cache.c7gn.8xlarge | 53516 | 32 |
| cache.c7gn.12xlarge | 325400 | 48 |
| cache.c7gn.16xlarge | 108347 | 64 |
**Note**
Toutes les instances T2 sont créées dans un Amazon Virtual Private Cloud (Amazon VPC).
# Connexion automatique d'une EC2 instance et d'un ElastiCache cache
Vous pouvez utiliser la ElastiCache console pour simplifier la configuration d'une connexion entre une instance Amazon Elastic Compute Cloud (Amazon EC2) et un ElastiCache cache. Souvent, votre cache se trouve dans un sous-réseau privé et votre EC2 instance dans un sous-réseau public au sein d'un VPC. Vous pouvez utiliser un client SQL sur votre EC2 instance pour vous connecter à votre ElastiCache cache. L' EC2 instance peut également exécuter des serveurs Web ou des applications qui accèdent à votre ElastiCache cache privé.
![\[Connectez automatiquement un ElastiCache cache à une EC2 instance.\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ec2-elasticache-connect-network_diagram.png)
**Topics**
+ [Connectivité automatique avec une EC2 instance](#ec2-elc-connect-overview)
+ [Affichage des ressources de calcul connectées](#ec2-elc-connect-viewing)
## Connectivité automatique avec une EC2 instance
Lorsque vous configurez une connexion entre une EC2 instance et un ElastiCache cache, configure ElastiCache automatiquement le groupe de sécurité VPC pour EC2 votre instance et pour ElastiCache votre cache.
Les conditions requises pour connecter une EC2 instance à un ElastiCache cache sont les suivantes :
+ L' EC2 instance doit exister dans le même VPC que le ElastiCache cache.
Si aucune EC2 instance n'existe dans le même VPC, la console fournit un lien pour en créer une.
+ L'utilisateur qui configure la connectivité doit être autorisé à effectuer les EC2 opérations Amazon suivantes. Ces autorisations sont généralement ajoutées aux EC2 comptes lors de leur création. Pour plus d'informations sur EC2 les autorisations, consultez la section [Octroi des autorisations requises pour les EC2 ressources Amazon](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html).
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateSecurityGroup`
+ `ec2:DescribeInstances`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:DescribeSecurityGroups`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:RevokeSecurityGroupEgress`
Lorsque vous configurez une connexion à une EC2 instance, ElastiCache agissez conformément à la configuration actuelle des groupes de sécurité associés au ElastiCache cache et à l' EC2 instance, comme décrit dans le tableau suivant.
****
| Configuration actuelle ElastiCache du groupe de sécurité | Configuration actuelle EC2 du groupe de sécurité | ElastiCache action |
| --- | --- | --- |
| Il existe un ou plusieurs groupes de sécurité associés au ElastiCache cache dont le nom correspond au modèle`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Un groupe de sécurité qui correspond au modèle n'a pas été modifié. Ce groupe de sécurité ne possède qu'une seule règle entrante dont le groupe de sécurité VPC de EC2 l'instance est la source. | Un ou plusieurs groupes de sécurité sont associés à l' EC2 instance dont le nom correspond au modèle`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Un groupe de sécurité qui correspond au modèle n'a pas été modifié. Ce groupe de sécurité n'a qu'une seule règle sortante avec le groupe de sécurité VPC ElastiCache du cache comme source. | ElastiCache ne prend aucune mesure. Une connexion a déjà été configurée automatiquement entre l' EC2 instance et le ElastiCache cache. Comme une connexion existe déjà entre l' EC2 instance et le ElastiCache cache, les groupes de sécurité ne sont pas modifiés. |
| L'une des conditions suivantes s'applique : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/compute-connection.html) | L'une des conditions suivantes s'applique : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/compute-connection.html) | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Il existe un ou plusieurs groupes de sécurité associés au ElastiCache cache dont le nom correspond au modèle`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Un groupe de sécurité qui correspond au modèle n'a pas été modifié. Ce groupe de sécurité ne possède qu'une seule règle entrante dont le groupe de sécurité VPC de EC2 l'instance est la source. | Un ou plusieurs groupes de sécurité sont associés à l' EC2 instance dont le nom correspond au modèle`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Cependant, ElastiCache vous ne pouvez utiliser aucun de ces groupes de sécurité pour la connexion avec le ElastiCache cache. ElastiCache ne peut pas utiliser un groupe de sécurité qui n'a pas de règle sortante avec le groupe de sécurité VPC ElastiCache du cache comme source. ElastiCache ne peut pas non plus utiliser un groupe de sécurité qui a été modifié. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Il existe un ou plusieurs groupes de sécurité associés au ElastiCache cache dont le nom correspond au modèle`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Un groupe de sécurité qui correspond au modèle n'a pas été modifié. Ce groupe de sécurité ne possède qu'une seule règle entrante dont le groupe de sécurité VPC de EC2 l'instance est la source. | Un groupe EC2 de sécurité valide existe pour la connexion, mais il n'est pas associé à l' EC2 instance. Le nom de ce groupe de sécurité correspond au modèle `ec2-elasticache-${ec2InstanceId}:${cacheId}`. Il n'a pas été modifié. Il n'a qu'une seule règle sortante avec le groupe de sécurité VPC theElastiCache du cache comme source. | [ELC action: associate EC2 security group](#elc-action-associate-ec2-security-group) |
| L'une des conditions suivantes s'applique : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/compute-connection.html) | Un ou plusieurs groupes de sécurité sont associés à l' EC2 instance dont le nom correspond au modèle`ec2-elasticache-${ec2InstanceId}:${cacheId}`. Un groupe de sécurité qui correspond au modèle n'a pas été modifié. Ce groupe de sécurité n'a qu'une seule règle sortante avec le groupe de sécurité VPC ElastiCache du cache comme source. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
**ElastiCacheaction : créer de nouveaux groupes de sécurité**
ElastiCache prend les mesures suivantes :
+ Crée un nouveau groupe de sécurité qui correspond au modèle `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Ce groupe de sécurité possède une règle entrante dont le groupe de sécurité VPC de EC2 l'instance est la source. Ce groupe de sécurité est associé au ElastiCache cache et permet à l' EC2 instance d'y accéder.
+ Crée un nouveau groupe de sécurité qui correspond au modèle `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Ce groupe de sécurité dispose d'une règle sortante avec le groupe de sécurité VPC ElastiCache du cache comme cible. Ce groupe de sécurité est associé à l' EC2 instance et permet à EC2 celle-ci d'envoyer du trafic vers le ElastiCache cache.
**ElastiCache action : associer un groupe EC2 de sécurité**
ElastiCacheassocie le groupe de EC2 sécurité existant valide à l' EC2 instance. Ce groupe de sécurité permet à l' EC2instance d'envoyer du trafic vers le ElastiCache cache.
## Affichage des ressources de calcul connectées
Vous pouvez utiliser le AWS Management Console pour afficher les ressources de calcul connectées à un ElastiCache cache. Les ressources affichées comprennent les connexions de ressources de calcul qui ont été configurées automatiquement. Par exemple, vous pouvez autoriser une ressource de calcul à accéder manuellement à un cache en ajoutant une règle au groupe de sécurité VPC associé au cache. Ces ressources n'apparaîtront pas dans la liste des ressources informatiques connectées.
Pour qu'une ressource de calcul soit répertoriée, les mêmes conditions doivent s'appliquer que lors de la connexion automatique d'une EC2 instance et d'un ElastiCache cache.
**Pour afficher les ressources de calcul connectées à un ElastiCache cache**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la
1. Dans le volet de navigation, choisissez **Caches**, puis choisissez un cache Valkey ou Redis OSS.
1. Dans l'onglet **Connectivité et sécurité**, consultez les ressources de calcul dans la section **Configurer la connexion de calcul**.
![\[Ressources de calcul connectées\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ec2-elasticache-connected_resources.png)
# Dimensionnement ElastiCache
Vous pouvez adapter votre ElastiCache cache à vos besoins. Les caches sans serveur et les clusters basés sur des nœuds offrent plusieurs options de dimensionnement différentes.
## Mise à l'échelle ElastiCache sans serveur
ElastiCache Serverless s'adapte automatiquement au trafic de votre charge de travail à mesure qu'il augmente ou diminue. Pour chaque cache ElastiCache sans serveur, suit ElastiCache en permanence l'utilisation des ressources telles que le processeur, la mémoire et le réseau. Lorsque l'une de ces ressources est limitée, ElastiCache Serverless évolue en ajoutant une nouvelle partition et en redistribuant les données vers la nouvelle partition, sans aucune interruption de service pour votre application. Vous pouvez surveiller les ressources consommées par votre cache en CloudWatch surveillant la `BytesUsedForCache` métrique pour le stockage des données du cache et `ElastiCacheProcessingUnits` (ECPU) pour l'utilisation du calcul.
## Définition de limites de mise à l’échelle pour gérer les coûts
Vous pouvez choisir de configurer une utilisation maximale à la fois pour le stockage des données du cache et ECPU/second pour votre cache afin de contrôler les coûts du cache. Cela garantira que l’utilisation de votre cache ne dépassera jamais l’utilisation maximale configurée.
Si vous définissez un maximum de dimensionnement, votre application risque de connaître une baisse des performances du cache lorsque celui-ci atteint le maximum. Lorsque vous définissez un maximum de stockage de données en cache et que votre stockage de données en cache atteint le maximum, ElastiCache les données de votre cache qui ont un Time-To-Live (TTL) défini commencent à être expulsées, en utilisant la logique LRU. Si aucune donnée ne peut être expulsée, les demandes d’écriture de données supplémentaires recevront un message d’erreur OOM (mémoire insuffisante). Lorsque vous définissez un ECPU/second maximum et que l'utilisation du calcul de votre charge de travail dépasse cette valeur, ElastiCache les demandes commencent à être limitées.
Si vous définissez une limite maximale sur `BytesUsedForCache` ou`ElastiCacheProcessingUnits`, nous vous recommandons vivement de configurer une CloudWatch alarme à une valeur inférieure à la limite maximale afin que vous soyez averti lorsque votre cache fonctionne à proximité de ces limites. Nous vous recommandons de définir une alarme à 75 % de la limite maximale que vous avez définie. Consultez la documentation pour savoir comment configurer les CloudWatch alarmes.
## Pré-dimensionnement avec Serverless ElastiCache
**ElastiCache Prédimensionnement sans serveur**
Avec le prédimensionnement, également appelé préchauffage, vous pouvez définir des limites minimales prises en charge pour votre ElastiCache cache. Vous pouvez définir ces minimums pour les unités de ElastiCache traitement (ECPUs) par seconde ou pour le stockage des données. Cela peut être utile pour préparer les événements de mise à l'échelle prévus. Par exemple, si une société de jeux prévoit une multiplication par 5 du nombre de connexions dès la première minute de lancement de son nouveau jeu, elle peut préparer son cache pour ce pic d'utilisation significatif.
Vous pouvez effectuer un pré-dimensionnement à l'aide de la ElastiCache console, de la CLI ou de l'API. ElastiCache Serverless met à jour les ECPUs/second informations disponibles dans le cache dans les 60 minutes et envoie une notification d'événement lorsque la mise à jour de la limite minimale est terminée.
**Comment fonctionne le pré-dimensionnement**
Lorsque la limite minimale pour ECPUs/second le stockage des données est mise à jour via la console, la CLI ou l'API, cette nouvelle limite est disponible dans un délai d'une heure. ElastiCache Serverless prend en charge 30 Ko ECPUs/second sur un cache vide, et jusqu'à 90 000 en ECPUs/sec cas d'utilisation de la fonction Read from Replica. ElastiCache Serverless for Valkey 8.0 peut doubler le nombre de demandes prises en charge par seconde (RPS) toutes les 2 à 3 minutes, pour atteindre 5 millions de RPS par cache contre zéro en moins de 13 minutes, avec une latence de lecture constante inférieure à la milliseconde p50. Si vous prévoyez qu'un événement de dimensionnement à venir pourrait dépasser ce taux, nous vous recommandons de fixer le minimum ECPUs/second au pic ECPUs/sec attendu au moins 60 minutes avant l'événement de pointe. Dans le cas contraire, l'application risque de connaître une latence élevée et un ralentissement des demandes.
Une fois la mise à jour de la limite minimale terminée, ElastiCache Serverless commencera à vous mesurer pour le nouveau minimum ECPUs par seconde ou le nouveau minimum de stockage. Cela se produit même si votre application n'exécute pas de requêtes dans le cache ou si votre utilisation du stockage de données est inférieure au minimum. Lorsque vous abaissez la limite minimale par rapport à son paramètre actuel, la mise à jour est immédiate, de sorte que ElastiCache Serverless commence immédiatement à mesurer la nouvelle limite minimale.
**Note**
Lorsque vous définissez une limite d'utilisation minimale, celle-ci vous est facturée même si votre utilisation réelle est inférieure à la limite d'utilisation minimale. L'utilisation de l'ECPU ou du stockage de données qui dépasse la limite d'utilisation minimale est facturée au tarif normal. Par exemple, si vous définissez une limite d'utilisation minimale de 100 000 dollars, ECPUs/second vous serez facturé au moins 1,224\$1 par heure (en utilisant les prix de l'ECPU indiqués dans us-east-1), même si votre utilisation est inférieure à ce minimum défini.
ElastiCache Serverless prend en charge l'échelle minimale requise au niveau agrégé du cache. ElastiCache Serverless prend également en charge un maximum de 30 000 ECPUs/second par slot (90 000 ECPUs/second lors de l'utilisation de Read from Replica à l'aide de connexions READONLY). Il est recommandé que votre application veille à ce que la distribution des clés entre les emplacements Valkey ou Redis OSS et le trafic entre les clés soient aussi uniformes que possible.
## Définition des limites de dimensionnement à l'aide de la console et AWS CLI
*Définition des limites de dimensionnement à l'aide de la AWS console*
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez le moteur qui s'exécute sur le cache que vous souhaitez modifier.
1. La liste des caches exécutant le moteur choisi s’affiche.
1. Choisissez le cache à modifier en cliquant sur le bouton d’option situé à gauche du nom du cache.
1. Choisissez **Actions**, puis **Modifier**.
1. Sous **Limites d'utilisation, définissez les limites** **de mémoire** ou **de calcul** appropriées.
1. Cliquez sur **Prévisualiser les modifications**, puis sur **Enregistrer les modifications**.
**Définition des limites d'échelle à l'aide du AWS CLI**
Pour modifier les limites de dimensionnement à l'aide de la CLI, utilisez l' modify-serverless-cacheAPI.
**Linux :**
```
aws elasticache modify-serverless-cache --serverless-cache-name \
--cache-usage-limits 'DataStorage={Minimum=10,Maximum=100,Unit=GB}, ECPUPerSecond={Minimum=1000,Maximum=100000}'
```
**Windows:**
```
aws elasticache modify-serverless-cache --serverless-cache-name ^
--cache-usage-limits 'DataStorage={Minimum=10,Maximum=100,Unit=GB}, ECPUPerSecond={Minimum=1000,Maximum=100000}'
```
**Suppression des limites de mise à l’échelle à l’aide de l’interface de ligne de commande**
Pour supprimer les limites de mise à l'échelle à l'aide de la CLI, définissez les paramètres de limite minimale et maximale sur 0.
**Linux :**
```
aws elasticache modify-serverless-cache --serverless-cache-name \
--cache-usage-limits 'DataStorage={Minimum=0,Maximum=0,Unit=GB}, ECPUPerSecond={Minimum=0,Maximum=0}'
```
**Windows:**
```
aws elasticache modify-serverless-cache --serverless-cache-name ^
--cache-usage-limits 'DataStorage={Minimum=0,Maximum=0,Unit=GB}, ECPUPerSecond={Minimum=0,Maximum=0}'
```
# Mise à l'échelle de clusters basés sur des nœuds
La quantité de données dont votre application a besoin pour fonctionner est rarement statique. Elle augmente et diminue au fur et mesure du développement et des fluctuations normales liées à votre activité. Si vous gérez vous-même votre cache, vous devez mettre en service le matériel nécessaire pour répondre aux pics de demande, ce qui peut s'avérer coûteux. En utilisant Amazon, ElastiCache vous pouvez évoluer pour répondre à la demande actuelle, en ne payant que pour ce que vous utilisez. ElastiCache vous permet de dimensionner votre cache en fonction de la demande.
**Note**
Si un cluster Valkey ou Redis OSS est répliqué dans une ou plusieurs régions, ces régions sont redimensionnées dans l'ordre. Lors de la mise à l'échelle, les régions secondaires sont redimensionnées en premier, puis la région principale. Lors de la réduction, la région principale est la première, puis les régions secondaires suivent.
Lors de la mise à jour de la version du moteur, la commande est la région secondaire, puis la région principale.
**Topics**
+ [Dimensionnement à la demande pour les clusters Memcached](Scaling-self-designed.mem-heading.md)
+ [Dimensionnement manuel pour les clusters Memcached](Scaling.Memcached.manually.md)
+ [Mise à l'échelle pour les clusters Valkey ou Redis OSS (mode cluster désactivé)](scaling-redis-classic.md)
+ [Dimensionnement des nœuds de réplication pour Valkey ou Redis OSS (mode cluster désactivé)](Scaling.RedisReplGrps.md)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md)
# Dimensionnement à la demande pour les clusters Memcached
ElastiCache for Memcached propose un service de mise en cache en mémoire entièrement géré qui déploie, exploite et fait évoluer verticalement Memcached dans le cloud.AWS
**Dimensionnement vertical à la demande**
Grâce à la mise à l'échelle verticale, ElastiCache Memcached fournit un système de mise en cache de mémoire distribuée à hautes performances largement utilisé pour accélérer les applications dynamiques en allégeant la charge des bases de données. Il stocke les données et les objets dans la RAM, réduisant ainsi le besoin de lire à partir de sources de données externes.
Vous pouvez appliquer une mise à l'échelle verticale aux clusters basés sur des nœuds existants ainsi qu'aux nouveaux clusters. Cela peut apporter de la flexibilité dans l'allocation des ressources, permettant aux utilisateurs de s'adapter efficacement à l'évolution des charges de travail sans modifier l'architecture du cluster. Cette capacité d'évolutivité améliore les performances en augmentant la capacité du cache pendant les périodes de forte demande et en la réduisant pour optimiser les coûts pendant les périodes de faible demande. Cela simplifie les opérations, élimine le besoin de créer de nouveaux clusters pour répondre à l'évolution des besoins en ressources et permet de réagir rapidement aux fluctuations du trafic. Dans l'ensemble, la mise à l'échelle verticale des clusters basés sur des nœuds Memcached peut contribuer à améliorer la rentabilité, à améliorer l'utilisation des ressources et même à permettre aux utilisateurs de modifier leur type d'instance Memcached. Tout cela permet aux utilisateurs d'aligner plus facilement leur infrastructure de mise en cache sur les besoins réels des applications.
**Note**
Les modifications de type de nœud ne sont disponibles que pour les clusters Memcached basés sur des nœuds dotés de versions de moteur 1.5 ou ultérieures.
La découverte automatique doit être activée pour pouvoir utiliser la mise à l'échelle verticale.
## Configuration du dimensionnement vertical à la demande pour les clusters Memcached basés sur des nœuds
Vous pouvez configurer le dimensionnement vertical à la demande pour Memcached avec`scale-config`, qui contient deux paramètres :
1. **ScaleIntervalMinutes:** durée (en minutes) entre le dimensionnement des lots pendant le processus de mise à niveau de Memcached
1. **ScalePercentage:** pourcentage de nœuds à dimensionner simultanément pendant le processus de mise à niveau de Memcached
**Conversion d'un type de nœud Memcached existant en un cache pouvant être redimensionné verticalement via la CLI**
Pour convertir un cluster basé sur des nœuds Memcached existant en un cache pouvant être redimensionné verticalement, vous pouvez l'utiliser via `elasticache modify-cache-cluster` la CLI.
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config \
--apply-immediately
```
**Configuration de la mise à l'échelle verticale avec la CLI**
Pour configurer la mise à l'échelle verticale pour un cluster Memcached basé sur des nœuds via la CLI, utilisez `elasticache modify-cache-cluster` with `scale-config` et ses paramètres et. `ScalePercentage` `ScaleIntervalMinutes`
+ **scale-interval-minutes:** Ceci définit le temps (en minutes) entre les lots de mise à l'échelle. Ce réglage peut aller de 2 à 30 minutes. Si aucune valeur n'est spécifiée, la valeur par défaut de 5 minutes est appliquée.
+ **scale-percentage :** indique le pourcentage de nœuds à dimensionner simultanément dans chaque lot. Ce paramètre peut être compris entre 10 et 100. Le paramètre est arrondi lors de la division. Par exemple, si le résultat est de 49,5, un paramètre de 50 est appliqué. Si aucune valeur n'est spécifiée, la valeur par défaut de 20 est appliquée.
Ces options de configuration vous permettront d'affiner le processus de dimensionnement en fonction de vos besoins spécifiques, en trouvant un équilibre entre la minimisation des perturbations du cluster et l'optimisation de la vitesse de mise à l'échelle. Le paramètre scale-config ne sera applicable qu'aux types de moteurs Memcached et sera ignoré pour les autres moteurs de cache, garantissant ainsi la rétrocompatibilité avec l'utilisation existante des API pour d'autres clusters.
**Appel d'API**
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config '{
"ScalePercentage": 30,
"ScaleIntervalMinutes": 2
}'
--apply-immediately
```
**Résultat :**
Renvoie l'ID du cluster et la modification en attente.
```
{
"CacheCluster": {
"CacheNodeType": "old_insance_type",
...
...
"PendingModifiedValues": {
"CacheNodeType": "new_instance_type"
},
}
}
```
**Répertoriez les paramètres de mise à l'échelle verticale de votre cache Memcached**
Vous pouvez récupérer les options de mise à l'échelle de vos caches Memcached et voir quelles sont leurs options actuelles pour la mise à l'échelle verticale.
**Appel d'API**
```
aws elasticache list-allowed-node-type-modifications --cache-cluster-id
```
**Résultat :**
```
{
"ScaleUpModifications": [
"cache.x.xxxx",
"cache.x.xxxx"
],
"ScaleDownModifications": [
"cache.x.xxxx",
"cache.x.xxxx",
"cache.x.xxxx"
]
}
```
**Mise à l'échelle verticale pour Memcached avec le AWS Management Console**
Suivez ces étapes pour AWS Management Console convertir un cluster Memcached basé sur des nœuds en cluster évolutif verticalement.
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Sélectionnez le cluster Memcached à convertir.
1. Sélectionnez l'onglet **Modifier**.
1. Accédez à la section **Paramètres du cache** et sélectionnez le **type de nœud** souhaité.
1. Sélectionnez **Aperçu des modifications**, puis passez en revue les modifications.
1. Sélectionnez **Modify**.
## Mise à l'échelle horizontale automatisée pour Memcached
ElastiCache s'intègre désormais au service AWS Application Auto Scaling (AAS) pour inclure le dimensionnement horizontal automatique pour les clusters Memcached. Vous pouvez définir des politiques de dimensionnement via le service AWS Application Auto Scaling et ajuster automatiquement le nombre de nœuds dans les clusters Memcached selon les besoins, en fonction de métriques ou de plannings prédéfinis.
**Note**
La mise à l'échelle horizontale automatisée n'est actuellement pas disponible dans les régions de Pékin et de Ningxia.
Voici les méthodes disponibles pour redimensionner automatiquement horizontalement vos clusters basés sur des nœuds.
+ **Dimensionnement planifié :** le dimensionnement basé sur un calendrier vous permet de définir votre propre calendrier de dimensionnement pour des changements de charge prévisibles. Par exemple, chaque semaine le trafic vers l'application Web commence à augmenter le mercredi, reste élevé le jeudi et amorce une baisse le vendredi. Vous pouvez configurer Auto Scaling pour augmenter la capacité le mercredi et la diminuer le vendredi.
+ **Suivi des cibles :** avec les politiques de dimensionnement du suivi des cibles, vous choisissez une métrique de mise à l'échelle et définissez une valeur cible. Application Auto Scaling crée et gère les CloudWatch alarmes qui déclenchent la politique de dimensionnement et calcule l'ajustement de dimensionnement en fonction de la métrique et de la valeur cible. La politique de dimensionnement ajoute ou supprime de la capacité si nécessaire pour maintenir la métrique à la valeur cible spécifiée ou proche de celle-ci.
**Comment configurer la mise à l'échelle horizontale pour un cluster Memcached basé sur des nœuds via la CLI**
Lors de la mise à l'échelle horizontale d'un cluster Memcached basé sur des nœuds, vous pouvez utiliser une politique de suivi des cibles, une politique planifiée ou les deux.
1. **Enregistrer une ressource en tant que cible évolutive**
Appelez l'`RegisterScalableTarget`API dans AWS Application Auto Scaling pour enregistrer la cible de la dimension évolutive`elasticache:cache-cluster:Nodes`.
**API : ApplicationAutoScaling. RegisterScalableTarget**
Entrée :
```
{
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"MinCapacity": 20,
"MaxCapacity": 50
}
```
1. **Création d'une politique de dimensionnement du suivi de Target**
Ensuite, vous pouvez créer une politique de dimensionnement de suivi des cibles pour la ressource en appelant l'API de politique de dimensionnement put.
1. **Métrique prédéfinie**
Vous trouverez ci-dessous une politique qui s'adapte à la dimension du nœud de cache, en utilisant la métrique prédéfinie` ElastiCacheCPUUtilization`, définie à 50 pour le cluster test-cluster-1. Lorsque vous supprimez des nœuds à des fins de scale-in, les n derniers nœuds seront supprimés.
API : ApplicationAutoScaling. PutScalingPolicy
Entrée :
```
{
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 50,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ElastiCacheCPUUtilization"
},
"ScaleOutCooldown": 600,
"ScaleInCooldown": 600
},
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1"
}
```
Sortie :
```
{
"PolicyARN": "arn:aws:autoscaling:us-west-2:012345678910:scalingPolicy:6d8972f3-efc8-437c-92d1-6270f29a66e7:resource/elasticache/cache-cluster/test-cluster-1:policyName/cpu50-target-tracking-scaling-policy",
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca",
"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d",
"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d"
}
]
}
```
1. **Métrique personnalisée**
Vous pouvez également définir une politique de dimensionnement pour la dimension en utilisant un pourcentage personnalisé basé sur la métrique Cloudwatch.
Entrée :
```
{
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"CustomizedMetricSpecification": {
"Dimensions": [
{
"Name": "MyMetricDimension",
"Value": "DimensionValue"
}
],
"MetricName": "MyCustomMetric",
"Namespace": "MyNamespace",
"Statistic": "Average",
"Unit": "Percent"
},
"TargetValue": 40,
"ScaleOutCooldown": 600,
"ScaleInCooldown": 600
},
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1"
}
```
1. **Actions planifiées**
Lorsque vous devez effectuer une mise à l'échelle en fonction d'un événement particulier, puis intervenir après l'événement, vous pouvez créer deux actions planifiées en appelant l'`PutScheduledAction`API.
**Politique 1 : Extensification**
La `at` commande `--schedule` planifie l'action pour qu'elle soit exécutée une fois à une date et à une heure spécifiées dans le futur. Le champ de planification prend également en charge le taux (minute, heure, jour, etc.) et le cron (pour l'expression cron).
À la date et à l'heure spécifiées, Application Auto Scaling met à jour les valeurs `MinCapacity` et `MaxCapacity`. Application Auto Scaling évolue MinCapacity jusqu'à 70 nœuds de cache.
**API : ApplicationAutoScaling. PutScheduledAction**
Entrée :
```
{
"ResourceId": "elasticache:ache-cluster:test-cluster-1",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ScalableTargetAction": {
"MaxCapacity": 100,
"MinCapacity": 70
},
"Schedule": "at(2020-05-20T17:05:00)",
"ScheduledActionName": "ScalingOutScheduledAction",
"ServiceNamespace": "elasticache",
}
```
**Politique 2 : mise à l'échelle**
À la date et à l'heure spécifiées, Application Auto Scaling met à jour les valeurs de `MinCapacity` la table et les redimensionne `MaxCapacity` pour ramener le nombre de nœuds de cache à 60. `MaxCapacity`
**API : ApplicationAutoScaling. PutScheduledAction**
Entrée :
```
{
"ResourceId": "elasticache:cache-cluster:test-cluster-1",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ScalableTargetAction": {
"MaxCapacity": 60,
"MinCapacity": 40
},
"Schedule": "at(2020-05-21T17:05:00)",
"ScheduledActionName": "ScalingInScheduledAction",
"ServiceNamespace": "elasticache",
}
```
1. **Afficher les activités de dimensionnement**
Vous pouvez consulter les activités de dimensionnement à l'aide de l'`DescribeScalingActivities`API.
**API : ApplicationAutoScaling. DescribeScalingActivities**
Sortie :
```
{
"ScalingActivities": [
{
"ScalableDimension": "elasticache:elasticache:DesiredCount",
"Description": "Setting desired count to 30.",
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ActivityId": "4d759079-a31f-4d0c-8468-504c56e2eecf",
"StartTime": 1462574194.658,
"elasticacheNamespace": "elasticache",
"EndTime": 1462574276.686,
"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
"StatusMessage": "Failed to set desired count to 30",
"StatusCode": "Failed"
},
{
"ScalableDimension": "elasticache:elasticache:DesiredCount",
"Description": "Setting desired count to 25.",
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ActivityId": "90aff0eb-dd6a-443c-889b-b809e78061c1",
"StartTime": 1462574254.223,
"elasticacheNamespace": "elasticache",
"EndTime": 1462574333.492,
"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
"StatusMessage": "Successfully set desired count to 25. Change successfully fulfilled by elasticache.",
"StatusCode": "Successful"
}
]
}
```
1. **Modifier/supprimer la politique de dimensionnement**
Vous pouvez modifier ou supprimer des politiques en appelant à nouveau `PutScalingPolicy` l'API ou en appelant `DeleteScalingPolicy` `DeleteScheduled` Action.
1. **Désenregistrer les cibles évolutives**
Vous pouvez désenregistrer la cible évolutive via l'`DeregisterScalableTarget`API. L'annulation de l'enregistrement d'une cible évolutive supprime les politiques de dimensionnement et les actions planifiées qui lui sont associées.
**API : ApplicationAutoScaling. DeregisterScalableTarget**
Entrée :
```
{
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes"
}
```
1. **Nettoyage des politiques de dimensionnement**
1. **Politiques de dimensionnement multiples**
Vous pouvez créer plusieurs politiques de dimensionnement. Vous trouverez ci-dessous des informations clés sur le comportement issues du [suivi des cibles Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html).
+ Vous pouvez avoir plusieurs stratégies de dimensionnement Suivi de la cible pour une cible évolutive, dans la mesure où chacune d'elles utilise une métrique différente.
+ L'objectif d'Application Auto Scaling est de toujours donner la priorité à la disponibilité, afin que son comportement diffère selon que les politiques de suivi des cibles et d'échelonnement sont prêtes pour une augmentation ou une diminution de la capacité. Il augmentera la taille de la cible scalable si une des stratégies Suivi de la cible est prête pour une augmentation de taille, mais la diminuera uniquement si toutes les stratégies Suivi de la cible (avec la portion de diminution en charge activée) sont prêtes pour une diminution de taille.
+ Si plusieurs stratégies indiquent simultanément à la cible évolutive de procéder à une montée en charge ou à une diminution en charge, Application Auto Scaling effectue la mise à l'échelle en fonction de la stratégie qui fournit la plus grande capacité à la fois pour la diminution et l'augmentation. Cela vous offre une plus grande flexibilité pour couvrir plusieurs scénarios et pouvoir toujours disposer d'une capacité suffisante pour traiter vos charges de travail d'application.
**Note**
AWS Application Auto Scaling ne met pas en file d'attente les politiques de dimensionnement. Application Auto Scaling attendra la fin de la première mise à l'échelle, puis se refroidira, puis répétera l'algorithme ci-dessus.
**Redimensionnez automatiquement horizontalement un cluster Memcached basé sur des nœuds via AWS Management Console**
Suivez ces étapes pour AWS Management Console convertir un cluster Memcached existant basé sur des nœuds en un cluster évolutif horizontalement.
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Sélectionnez le cache Memcached à convertir.
1. Accédez à l'onglet **Autoscaling**.
1. Sélectionnez la politique de dimensionnement à appliquer en sélectionnant Ajouter une mise à **l'échelle dynamique ou Ajouter une mise** **à l'échelle planifiée**.
1. Renseignez les détails de la politique sélectionnée selon vos besoins.
1. Cliquez sur **Create**.
# Dimensionnement manuel pour les clusters Memcached
La mise à l'échelle horizontale manuelle d'un cluster Memcached vers ou vers l'extérieur est aussi simple que d'ajouter ou de supprimer des nœuds du cluster. Les clusters Memcached sont composés de 1 à 60 nœuds.
Etant donné que vous pouvez partitionner vos données sur tous les nœuds d'un cluster de Memcached, il est rarement obligatoire de changer pour un type de nœud avec une plus grande mémoire. Cependant, étant donné que le moteur Memcached ne conserve pas les données, si vous effectuez une mise à l'échelle vers un autre type de nœud, votre nouveau cluster repart vide à moins que votre application ne le remplisse.
Pour redimensionner manuellement verticalement votre cluster Memcached, vous devez créer un nouveau cluster. Les clusters de Memcached commencent toujours vides, sauf si votre application les remplisse.
**Dimensionnement manuel des clusters Memcached**
| Action | Rubrique |
| --- | --- |
| Augmentation d'échelle | [Ajout de nœuds à un cluster](Clusters.html#AddNode) |
| Diminution d'échelle | [Suppression de nœuds d’un cluster](Clusters.html#DeleteNode) |
| Modification des types de nœuds | [Dimensionnement vertical manuel des clusters Memcached basés sur des nœuds](#Scaling.Memcached.Vertically) |
**Topics**
+ [Dimensionnement horizontal manuel d'un cluster Memcached basé sur des nœuds](#Scaling.Memcached.Horizontally)
+ [Dimensionnement vertical manuel des clusters Memcached basés sur des nœuds](#Scaling.Memcached.Vertically)
## Dimensionnement horizontal manuel d'un cluster Memcached basé sur des nœuds
Le moteur Memcached prend en charge le partitionnement de vos données sur plusieurs nœuds. En conséquent, il est facile de dimensionner horizontalement les clusters de Memcached. Pour dimensionner horizontalement votre cluster de Memcached, ils suffit simplement d'ajouter ou de supprimer des nœuds.
Les rubriques suivantes expliquent en détail comment dimensionner votre cluster de Memcached ou en ajoutant ou supprimant des nœuds.
+ [Ajout de nœuds à un cluster](Clusters.html#AddNode)
+ [Suppression de nœuds de votre cluster](Clusters.html#AddNode)
Chaque fois que vous modifiez le nombre de nœuds dans votre cluster Memcached, vous devez redéfinir le mappage, au minimum, d'une partie de votre espace de clé vers le nœud adéquat. Pour en savoir plus sur l'équilibrage de charge de votre cluster Memcached, consultez [Configuration de votre ElastiCache client pour un équilibrage de charge efficace (Memcached)](BestPractices.LoadBalancing.md).
Si vous utilisez la découverte automatique sur votre cluster de Memcached, vous n'avez pas besoin de modifier les points de terminaison de votre application à mesure que vous ajoutez ou supprimez des nœuds. Pour plus d’informations sur la découverte automatique, consultez [Identifiez automatiquement les nœuds de votre cluster (Memcached)](AutoDiscovery.md). Si vous n’utilisez pas la découverte automatique, chaque fois que vous modifiez le nombre de nœuds de votre cluster Memcached, vous devez mettre à jour les points de terminaison de votre application.
## Dimensionnement vertical manuel des clusters Memcached basés sur des nœuds
Lorsque vous redimensionnez manuellement votre cluster Memcached vers le haut ou vers le bas, vous devez créer un nouveau cluster. Les clusters de Memcached commencent toujours vides, sauf si votre application les remplisse.
**Important**
Si vous optez pour un plus petit type de nœud, veillez à ce que le type de nœud plus petit soit suffisant pour vos données et les besoins de traitement. Pour de plus amples informations, veuillez consulter [Choix de la taille de votre nœud](CacheNodes.SelectSize.md).
**Topics**
+ [Dimensionnement vertical d'un cluster Memcached basé sur des nœuds (console)](#Scaling.Memcached.Vertically.CON)
+ [Mise à l'échelle verticale d'un cluster Memcached basé sur des nœuds ()AWS CLI](#Scaling.Memcached.Vertically.CLI)
+ [Dimensionnement vertical d'un cluster Memcached basé sur des nœuds (API) ElastiCache](#Scaling.Memcached.Vertically.API)
### Dimensionnement vertical d'un cluster Memcached basé sur des nœuds (console)
La procédure suivante vous explique comment dimensionner verticalement un cluster Memcached basé sur des nœuds à l'aide du.AWS Management Console
1. Créez un nouveau cluster de avec le nouveau type de nœud. Pour de plus amples informations, veuillez consulter [Création d'un cluster Memcached (console)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached).
1. Créez un nouveau cluster de cache avec le nouveau type de nœud. Pour de plus amples informations, veuillez consulter [Trouver les points de terminaison d'un cluster (console) (Memcached)](Endpoints.md#Endpoints.Find.Memcached).
1. Supprimez l'ancien cluster. Pour plus d’informations, consultez [Suppression d’un nouveau nœud dans Memcached](Clusters.html#Delete.CON.Memcached).
### Mise à l'échelle verticale d'un cluster Memcached basé sur des nœuds ()AWS CLI
La procédure suivante vous explique comment dimensionner verticalement un cluster Memcached basé sur des nœuds à l'aide du.AWS CLI
1. Créez un nouveau cluster de avec le nouveau type de nœud. Pour de plus amples informations, veuillez consulter [Création d'un cluster (AWS CLI)](Clusters.Create.md#Clusters.Create.CLI).
1. Créez un nouveau cluster de cache avec le nouveau type de nœud. Pour de plus amples informations, veuillez consulter [Recherche des points de terminaison (AWS CLI)](Endpoints.md#Endpoints.Find.CLI).
1. Supprimez l'ancien cluster. Pour de plus amples informations, veuillez consulter [Utilisation du AWS CLI pour supprimer un ElastiCache cluster](Clusters.Delete.md#Clusters.Delete.CLI).
### Dimensionnement vertical d'un cluster Memcached basé sur des nœuds (API) ElastiCache
La procédure suivante vous explique comment dimensionner verticalement un cluster Memcached basé sur des nœuds à l'aide de l'API. ElastiCache
1. Créez un nouveau cluster de avec le nouveau type de nœud. Pour de plus amples informations, consultez [Création d'un cluster pour Memcached (API) ElastiCache](Clusters.Create-mc.md#Clusters.Create.API.mem-heading).
1. Créez un nouveau cluster de cache avec le nouveau type de nœud. Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison (ElastiCache API)](Endpoints.md#Endpoints.Find.API).
1. Supprimez l'ancien cluster. Pour de plus amples informations, veuillez consulter [Utilisation de l' ElastiCache API](Clusters.Delete.md#Clusters.Delete.API).
# Mise à l'échelle pour les clusters Valkey ou Redis OSS (mode cluster désactivé)
Les clusters Valkey ou Redis OSS (mode cluster désactivé) peuvent être des clusters à nœud unique avec 0 partition ou des clusters à nœuds multiples avec 1 partition. Les clusters à un seul nœud utilisent ce nœud pour se connecter aussi bien en écriture qu'en lecture. Les clusters à nœuds multiples ont toujours 1 nœud comme nœud read/write principal avec 0 à 5 nœuds de réplication en lecture seule.
**Topics**
+ [Mise à l'échelle pour les clusters Valkey ou Redis OSS (mode cluster désactivé)](#Scaling.RedisStandalone)
**Mise à l'échelle des clusters Valkey ou Redis OSS**
| Action | Valkey ou Redis OSS (mode cluster désactivé) | Valkey ou Redis OSS (mode cluster activé) |
| --- | --- | --- |
| Diminution d'échelle | [Supprimer des nœuds d'un ElastiCache cluster](Clusters.DeleteNode.md) | [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md) |
| Augmentation d'échelle | [Ajout de nœuds à un cluster](Clusters.html#AddNode) | [Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) |
| Modification des types de nœuds | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/scaling-redis-classic.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/scaling-redis-classic.html) | [Dimensionnement vertical en ligne en modifiant le type de nœud](redis-cluster-vertical-scaling.md) |
| Modification du nombre de groupes de nœuds | Non pris en charge pour les clusters Valkey ou Redis OSS (mode cluster désactivé) | [Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md) |
**Contents**
+ [Mise à l'échelle pour les clusters Valkey ou Redis OSS (mode cluster désactivé)](#Scaling.RedisStandalone)
+ [Mise à l'échelle de clusters Valkey ou Redis OSS à nœud unique](#Scaling.RedisStandalone.ScaleUp)
+ [Mise à l'échelle de clusters Valkey ou Redis OSS (mode cluster désactivé) (console) à nœud unique](#Scaling.RedisStandalone.ScaleUp.CON)
+ [Mise à l'échelle de clusters Valkey ou Redis OSS à nœud unique ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Mise à l'échelle de clusters Valkey ou Redis OSS (API) à nœud unique ElastiCache](#Scaling.RedisStandalone.ScaleUp.API)
+ [Réduction de la taille des clusters Valkey ou Redis OSS à nœud unique](#Scaling.RedisStandalone.ScaleDown)
+ [Réduction de la taille d'un cluster Valkey ou Redis OSS à nœud unique (console)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Réduction des clusters Valkey ou Redis OSS à nœud unique ()AWS CLI](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Réduction des clusters Valkey ou Redis OSS (API) à nœud unique ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
## Mise à l'échelle pour les clusters Valkey ou Redis OSS (mode cluster désactivé)
Les nœuds Valkey ou Redis OSS (mode cluster désactivé) doivent être suffisamment grands pour contenir toutes les données du cache plus la surcharge de Valkey ou Redis OSS. Pour modifier la capacité de données de votre cluster Valkey ou Redis OSS (mode cluster désactivé), vous devez effectuer une mise à l'échelle verticale, en passant à un type de nœud plus grand pour augmenter la capacité de données, ou en réduisant à un type de nœud plus petit pour réduire la capacité de données.
Le processus de mise à ElastiCache l'échelle est conçu pour faire de son mieux pour conserver vos données existantes et nécessite une réplication réussie de Valkey ou Redis OSS. Pour les clusters Valkey ou Redis OSS (mode cluster désactivé), nous recommandons de mettre suffisamment de mémoire à la disposition de Valkey ou Redis OSS.
Vous ne pouvez pas partitionner vos données sur plusieurs clusters Valkey ou Redis OSS (mode cluster désactivé). Toutefois, si vous devez uniquement augmenter ou diminuer la capacité de lecture de votre cluster, vous pouvez créer un cluster Valkey ou Redis OSS (mode cluster désactivé) avec des nœuds de réplication et ajouter ou supprimer des répliques de lecture. Pour créer un cluster Valkey ou Redis OSS (mode cluster désactivé) avec des nœuds de réplication en utilisant votre cluster Valkey ou Redis OSS à nœud unique comme cluster principal, voir. [Création d'un cluster Valkey (mode cluster désactivé) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
Une fois que vous avez créé le cluster avec réplicas, vous pouvez augmenter la capacité de lecture en ajoutant des réplicas en lecture. Plus tard, si nécessaire, vous pourrez réduire la capacité de lecture en éliminant les réplicas en lecture. Pour plus d’informations, consultez [Augmentation de la capacité de lecture](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleOut) ou [Diminution de la capacité de lecture](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleIn).
Outre la possibilité d'augmenter la capacité de lecture, les clusters Valkey ou Redis OSS (mode cluster désactivé) dotés de répliques offrent d'autres avantages commerciaux. Pour de plus amples informations, veuillez consulter [Haute disponibilité avec les groupes de réplication](Replication.md).
**Important**
Si votre groupe de paramètres est utilisé `reserved-memory` pour réserver de la mémoire pour la surcharge de Valkey ou Redis OSS, avant de commencer le dimensionnement, assurez-vous de disposer d'un groupe de paramètres personnalisé qui réserve la quantité de mémoire appropriée pour votre nouveau type de nœud. Vous pouvez aussi modifier un groupe de paramètres personnalisé de façon à ce qu'il utilise `reserved-memory-percent` et vous servir de ce groupe de paramètres pour votre nouveau cluster.
Si vous utilisez `reserved-memory-percent`, cette opération n'est pas nécessaire.
Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
**Topics**
+ [Mise à l'échelle de clusters Valkey ou Redis OSS à nœud unique](#Scaling.RedisStandalone.ScaleUp)
+ [Réduction de la taille des clusters Valkey ou Redis OSS à nœud unique](#Scaling.RedisStandalone.ScaleDown)
### Mise à l'échelle de clusters Valkey ou Redis OSS à nœud unique
Lorsque vous augmentez la taille d'un cluster Valkey ou Redis OSS à nœud unique, ElastiCache effectuez le processus suivant, que vous utilisiez la ElastiCache console, l'API ou l'AWS CLI API. ElastiCache
1. Un nouveau cluster avec le nouveau type de nœud est créé dans la même zone de disponibilité que le cluster existant.
1. Les données du cache du cluster existant sont copiées dans le nouveau cluster. La durée de ce processus dépend du type de nœud et de la quantité de données contenues dans le cluster.
1. Les lectures et les écritures sont désormais effectuées à l'aide du nouveau cluster. Les points de terminaison du nouveau cluster étant les mêmes que ceux de l'ancien cluster, il n'est pas nécessaire de mettre à jour les points de terminaison dans votre application. Vous remarquerez une brève interruption des lectures et des écritures à partir du nœud primaire pendant que l'entrée DNS est mise à jour.
1. ElastiCache supprime l'ancien cluster. Vous remarquerez une brève interruption (quelques secondes) des lectures et des écritures à partir de l'ancien nœud car les connexions à l'ancien nœud seront déconnectées.
**Note**
Pour les clusters exécutant le type de nœud r6gd, vous pouvez uniquement mettre à l’échelle en fonction des tailles de nœuds au sein de la famille de nœuds r6gd.
Comme indiqué dans le tableau suivant, votre opération de mise à l'échelle de Valkey ou Redis OSS est bloquée si une mise à niveau du moteur est prévue pour la prochaine fenêtre de maintenance. Pour plus d'informations, consultez [Gestion de la maintenance des ElastiCache clusters](maintenance-window.md).
**Opérations Valkey ou Redis OSS bloquées**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/scaling-redis-classic.html)
Si vous avez une opération en suspens qui vous bloque, vous pouvez effectuer l'une des actions suivantes.
+ Planifiez votre opération de mise à l'échelle de Valkey ou Redis OSS pour la prochaine fenêtre de maintenance en décochant la case **Appliquer immédiatement** (utilisation de la CLI :`--no-apply-immediately`, utilisation de l'API :). `ApplyImmediately=false`
+ Attendez votre prochaine fenêtre de maintenance (ou après) pour effectuer votre opération de mise à l'échelle de Valkey ou Redis OSS.
+ Ajoutez la mise à niveau du moteur Valkey ou Redis OSS à cette modification de cluster en cochant la case **Appliquer immédiatement** (utilisation de la CLI :`--apply-immediately`, utilisation de l'API :`ApplyImmediately=true`). Cela permet de débloquer votre opération de mise à l'échelle en provoquant une mise à jour du moteur à effectuer immédiatement.
Vous pouvez étendre un cluster Valkey ou Redis OSS à nœud unique (mode cluster désactivé) à l'aide de la ElastiCache console, de l'API ou de l'API AWS CLI. ElastiCache
**Important**
Si votre groupe de paramètres est utilisé `reserved-memory` pour réserver de la mémoire pour la surcharge de Valkey ou Redis OSS, avant de commencer le dimensionnement, assurez-vous de disposer d'un groupe de paramètres personnalisé qui réserve la quantité de mémoire appropriée pour votre nouveau type de nœud. Vous pouvez aussi modifier un groupe de paramètres personnalisé de façon à ce qu'il utilise `reserved-memory-percent` et vous servir de ce groupe de paramètres pour votre nouveau cluster.
Si vous utilisez `reserved-memory-percent`, cette opération n'est pas nécessaire.
Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
#### Mise à l'échelle de clusters Valkey ou Redis OSS (mode cluster désactivé) (console) à nœud unique
La procédure suivante décrit comment augmenter la taille d'un cluster Valkey ou Redis OSS à nœud unique à l'aide de la ElastiCache console de gestion. Au cours de ce processus, votre cluster Valkey ou Redis OSS continuera à traiter les demandes avec un temps d'arrêt minimal.
**Pour étendre un cluster Valkey ou Redis OSS à nœud unique (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey ou Redis OSS clusters**.
1. Dans la liste des clusters, choisissez le cluster que vous souhaitez augmenter (il doit exécuter le moteur Valkey ou Redis OSS, et non le moteur Valkey ou Redis OSS en cluster).
1. Sélectionnez **Modifier**.
1. Dans l'assistant **Modifier le cluster** :
1. Choisissez le type de nœud auquel vous souhaitez passer dans la liste **Type de nœud**.
1. Si vous utilisez `reserved-memory` pour gérer la mémoire, dans la liste **Groupe de paramètres**, choisissez le groupe de paramètres personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud.
1. Si vous souhaitez effectuer un processus de mise à l'échelle immédiatement, cochez la case **Appliquer immédiatement**. Si la case **Appliquer immédiatement** est décochée, le processus de mise à l'échelle est effectué lors du créneau de maintenance suivant du cluster.
1. Sélectionnez **Modifier**.
Si vous avez choisi **Apply immediately** lors de l'étape précédente, le statut du cluster passe à *modification*. Lorsque son statut passe à *available*, la modification est terminée et vous pouvez commencer à utiliser le nouveau cluster.
#### Mise à l'échelle de clusters Valkey ou Redis OSS à nœud unique ()AWS CLI
La procédure suivante décrit comment augmenter la taille d'un cluster Valkey ou Redis OSS à nœud unique à l'aide du.AWS CLI Au cours de ce processus, votre cluster Valkey ou Redis OSS continuera à traiter les demandes avec un temps d'arrêt minimal.
**Pour étendre un cluster Valkey ou Redis OSS à nœud unique ()AWS CLI**
1. Déterminez les types de nœuds que vous pouvez augmenter en exécutant la AWS CLI`list-allowed-node-type-modifications` commande avec le paramètre suivant.
+ `--cache-cluster-id`
Pour Linux, macOS ou Unix :
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Pour Windows :
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
}
```
Pour plus d'informations, consultez [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) dans la *référence AWS CLI*.
1. Modifiez votre cluster existant en spécifiant le cluster à augmenter et le nouveau type de nœud plus grand, à l'aide de la AWS CLI`modify-cache-cluster` commande et des paramètres suivants.
+ `--cache-cluster-id`— Le nom du cluster que vous agrandissez.
+ `--cache-node-type`— Le nouveau type de nœud pour lequel vous souhaitez redimensionner le cluster. Cette valeur doit correspondre à l'un des types de nœuds renvoyés par la commande `list-allowed-node-type-modifications` lors de l'étape 1.
+ `--cache-parameter-group-name` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `--apply-immediately` : ce paramètre entraîne l'application immédiate du processus d'augmentation. Pour reporter le processus de mise à l'échelle au créneau de maintenance suivant du cluster, utilisez le paramètre `--no-apply-immediately`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cache-cluster \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m2-xl \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-cache-cluster ^
--cache-cluster-id my-redis-cache-cluster ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m2-xl ^
--apply-immediately
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis6.x",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "6.0",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
```
Pour plus d'informations, consultez [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) dans la *référence AWS CLI*.
1. Si vous avez utilisé le`--apply-immediately`, vérifiez l'état du nouveau cluster à l'aide de la AWS CLI`describe-cache-clusters` commande avec le paramètre suivant. Lorsque le statut devient *disponible*, vous pouvez commencer à utiliser le nouveau cluster plus grand.
+ `--cache-cluster-id`— Le nom de votre cluster Valkey ou Redis OSS à nœud unique. Utilisez ce paramètre pour décrire un cluster en particulier plutôt que tous les clusters.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Pour plus d'informations, consultez [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) dans la *référence AWS CLI*.
#### Mise à l'échelle de clusters Valkey ou Redis OSS (API) à nœud unique ElastiCache
La procédure suivante décrit comment augmenter la taille d'un cluster Valkey ou Redis OSS à nœud unique à l'aide de l'API. ElastiCache Au cours de ce processus, votre cluster Valkey ou Redis OSS continuera à traiter les demandes avec un temps d'arrêt minimal.
**Pour étendre un cluster (API) Valkey ou Redis OSS à nœud unique ElastiCache**
1. Déterminez les types de nœuds que vous pouvez augmenter en exécutant l'`ListAllowedNodeTypeModifications`action d' ElastiCache API avec le paramètre suivant.
+ `CacheClusterId`— Le nom du cluster Valkey ou Redis OSS à nœud unique que vous souhaitez augmenter.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) le *Amazon ElastiCache API Reference*.
1. Modifiez votre cluster existant en spécifiant le cluster à augmenter et le nouveau type de nœud plus grand, à l'aide de l'action `ModifyCacheCluster` ElastiCache API et des paramètres suivants.
+ `CacheClusterId`— Le nom du cluster que vous agrandissez.
+ `CacheNodeType`— Le nouveau type de nœud plus grand auquel vous souhaitez étendre le cluster. Cette valeur doit être l'un des types de nœuds renvoyés par l'`ListAllowedNodeTypeModifications`action de l'étape précédente.
+ `CacheParameterGroupName` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `ApplyImmediately` : lorsqu'il est défini sur `true`, il entraîne l'application immédiate du processus d'augmentation. Pour reporter le processus de mise à l'échelle au créneau de maintenance suivant du cluster, utilisez le paramètre `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) le *Amazon ElastiCache API Reference*.
1. Si vous l'avez utilisé `ApplyImmediately``=true`, vérifiez l'état du nouveau cluster à l'aide de l'`DescribeCacheClusters`action ElastiCache API avec le paramètre suivant. Lorsque le statut devient *disponible*, vous pouvez commencer à utiliser le nouveau cluster plus grand.
+ `CacheClusterId`— Le nom de votre cluster Valkey ou Redis OSS à nœud unique. Utilisez ce paramètre pour décrire un cluster en particulier plutôt que tous les clusters.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) le *Amazon ElastiCache API Reference*.
### Réduction de la taille des clusters Valkey ou Redis OSS à nœud unique
Les sections suivantes vous expliquent comment réduire un cluster Valkey ou Redis OSS à nœud unique à un type de nœud plus petit. Pour garantir le succès à long terme de votre nouveau cluster Valkey ou Redis OSS, il est important de s'assurer que le nouveau type de nœud plus petit est suffisamment grand pour accueillir toutes les données et les surcharges liées à Valkey ou Redis OSS. Pour de plus amples informations, veuillez consulter [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md).
**Note**
Pour les clusters exécutant le type de nœud r6gd, vous pouvez uniquement mettre à l’échelle en fonction des tailles de nœuds au sein de la famille de nœuds r6gd.
**Topics**
+ [Réduction de la taille d'un cluster Valkey ou Redis OSS à nœud unique (console)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Réduction des clusters Valkey ou Redis OSS à nœud unique ()AWS CLI](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Réduction des clusters Valkey ou Redis OSS (API) à nœud unique ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
#### Réduction de la taille d'un cluster Valkey ou Redis OSS à nœud unique (console)
La procédure suivante vous explique comment réduire votre cluster Valkey ou Redis OSS à nœud unique à un type de nœud plus petit à l'aide de la console. ElastiCache
**Important**
Si votre groupe de paramètres est utilisé `reserved-memory` pour réserver de la mémoire pour la surcharge de Valkey ou Redis OSS, avant de commencer le dimensionnement, assurez-vous de disposer d'un groupe de paramètres personnalisé qui réserve la quantité de mémoire appropriée pour votre nouveau type de nœud. Vous pouvez aussi modifier un groupe de paramètres personnalisé de façon à ce qu'il utilise `reserved-memory-percent` et vous servir de ce groupe de paramètres pour votre nouveau cluster.
Si vous utilisez `reserved-memory-percent`, cette opération n'est pas nécessaire.
Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
**Pour réduire la taille de votre cluster Valkey ou Redis OSS à nœud unique (console)**
1. Assurez-vous que le type de nœud plus petit soit suffisant pour supporter vos données et les besoins de traitement.
1. Si votre groupe de paramètres est utilisé `reserved-memory` pour réserver de la mémoire pour la surcharge de Valkey ou Redis OSS, assurez-vous de disposer d'un groupe de paramètres personnalisé pour réserver la quantité de mémoire appropriée pour votre nouveau type de nœud.
Vous pouvez aussi modifier votre groupe de paramètres personnalisé de façon à utiliser `reserved-memory-percent`. Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans la liste des clusters, choisissez le cluster que dont vous souhaitez baisser la capacité. Ce cluster doit exécuter le moteur Valkey ou Redis OSS et non le moteur Valkey ou Redis OSS en cluster.
1. Sélectionnez **Modifier**.
1. Dans l'assistant **Modifier le cluster** :
1. Choisissez le type de nœud dont vous souhaitez baisser la capacité dans la liste **Type de nœud**.
1. Si vous utilisez `reserved-memory` pour gérer la mémoire, dans la liste **Groupe de paramètres**, choisissez le groupe de paramètres personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud.
1. Si vous souhaitez effectuer le processus de diminution de la capacité immédiatement, choisissez la case **Apply immediately**. Si la case **Apply immediately** est décochée, le processus de diminution de la capacité est effectué lors du créneau de maintenance suivant du cluster.
1. Sélectionnez **Modifier**.
1. Lorsque le statut du cluster passe de *modifying* à *available*, cela signifie que votre cluster est passé au nouveau type de nœud. Il n'est pas nécessaire de mettre à jour les points de terminaison dans votre application.
#### Réduction des clusters Valkey ou Redis OSS à nœud unique ()AWS CLI
La procédure suivante décrit comment réduire la taille d'un cluster Valkey ou Redis OSS à nœud unique à l'aide du.AWS CLI
**Pour réduire la taille d'un cluster Valkey ou Redis OSS à nœud unique ()AWS CLI**
1. Déterminez les types de nœuds que vous pouvez réduire en exécutant la AWS CLI`list-allowed-node-type-modifications` commande avec le paramètre suivant.
+ `--cache-cluster-id`
Pour Linux, macOS ou Unix :
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Pour Windows :
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
}
```
Pour plus d'informations, consultez [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) dans la *référence AWS CLI*.
1. Modifiez votre cluster existant en spécifiant le cluster à réduire et le nouveau type de nœud plus petit, à l'aide de la AWS CLI`modify-cache-cluster` commande et des paramètres suivants.
+ `--cache-cluster-id`— Le nom du cluster que vous réduisez.
+ `--cache-node-type`— Le nouveau type de nœud pour lequel vous souhaitez redimensionner le cluster. Cette valeur doit correspondre à l'un des types de nœuds renvoyés par la commande `list-allowed-node-type-modifications` lors de l'étape 1.
+ `--cache-parameter-group-name` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `--apply-immediately` : entraîne l'application immédiate du processus de réduction. Pour reporter le processus de mise à l'échelle au créneau de maintenance suivant du cluster, utilisez le paramètre `--no-apply-immediately`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cache-cluster \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m2-xl \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-cache-cluster ^
--cache-cluster-id my-redis-cache-cluster ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m2-xl ^
--apply-immediately
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis6,x",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "6.0",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
```
Pour plus d'informations, consultez [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) dans la *référence AWS CLI*.
1. Si vous avez utilisé le`--apply-immediately`, vérifiez l'état du nouveau cluster à l'aide de la AWS CLI`describe-cache-clusters` commande avec le paramètre suivant. Lorsque le statut devient *disponible*, vous pouvez commencer à utiliser le nouveau cluster plus grand.
+ `--cache-cluster-id`— Le nom de votre cluster Valkey ou Redis OSS à nœud unique. Utilisez ce paramètre pour décrire un cluster en particulier plutôt que tous les clusters.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Pour plus d'informations, consultez [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) dans la *référence AWS CLI*.
#### Réduction des clusters Valkey ou Redis OSS (API) à nœud unique ElastiCache
La procédure suivante décrit comment redimensionner un cluster Valkey ou Redis OSS à nœud unique à l'aide de l'API. ElastiCache
**Pour réduire la taille d'un cluster Valkey ou Redis OSS (API) à nœud unique ElastiCache**
1. Déterminez les types de nœuds que vous pouvez réduire en exécutant l'`ListAllowedNodeTypeModifications`action d' ElastiCache API avec le paramètre suivant.
+ `CacheClusterId`— Le nom du cluster Valkey ou Redis OSS à nœud unique que vous souhaitez réduire.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) le *Amazon ElastiCache API Reference*.
1. Modifiez votre cluster existant en spécifiant le cluster à augmenter et le nouveau type de nœud plus grand, à l'aide de l'action `ModifyCacheCluster` ElastiCache API et des paramètres suivants.
+ `CacheClusterId`— Le nom du cluster que vous réduisez.
+ `CacheNodeType`— Le nouveau type de nœud plus petit auquel vous souhaitez réduire le cluster. Cette valeur doit être l'un des types de nœuds renvoyés par l'`ListAllowedNodeTypeModifications`action de l'étape précédente.
+ `CacheParameterGroupName` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `ApplyImmediately` : définissez ce paramètre sur `true` pour effectuer immédiatement le processus de réduction. Pour reporter le processus de mise à l'échelle au créneau de maintenance suivant du cluster, utilisez le paramètre `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) le *Amazon ElastiCache API Reference*.
1. Si vous l'avez utilisé `ApplyImmediately``=true`, vérifiez l'état du nouveau cluster à l'aide de l'`DescribeCacheClusters`action ElastiCache API avec le paramètre suivant. Lorsque le statut devient *disponible*, vous pouvez commencer à utiliser le nouveau cluster plus petit.
+ `CacheClusterId`— Le nom de votre cluster Valkey ou Redis OSS à nœud unique. Utilisez ce paramètre pour décrire un cluster en particulier plutôt que tous les clusters.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) le *Amazon ElastiCache API Reference*.
# Dimensionnement des nœuds de réplication pour Valkey ou Redis OSS (mode cluster désactivé)
Un cluster Valkey ou Redis OSS doté de nœuds de réplication (appelé *groupe de réplication* dans l'API/CLI) assure une haute disponibilité grâce à une réplication dans laquelle le mode multi-AZ avec basculement automatique est activé. Un cluster avec des nœuds répliques est un ensemble logique de six nœuds Valkey ou Redis OSS au maximum dont un nœud, le nœud principal, est capable de répondre à la fois aux demandes de lecture et d'écriture. Tous les autres nœuds du cluster sont des réplicas en lecture seule du cluster principal. Les données écrites dans le cluster principal sont répliquées de façon asynchrone sur tous les réplicas en lecture du cluster. Valkey ou Redis OSS (mode cluster désactivé) ne prenant pas en charge le partitionnement de vos données sur plusieurs clusters, chaque nœud d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) contient l'intégralité du jeu de données de cache. Les clusters Valkey ou Redis OSS (mode cluster activé) permettent de partitionner vos données sur un maximum de 500 partitions.
Pour modifier la capacité de données de votre cluster, vous devez dimensionner le type de nœud en passant à un type de nœud plus grand ou plus petit.
Pour modifier la capacité de lecture de votre cluster, ajoutez des réplicas en lecture, jusqu'à un maximum de 5, ou supprimez-en.
Le processus de mise à ElastiCache l'échelle est conçu pour faire de son mieux pour conserver vos données existantes et nécessite une réplication réussie de Valkey ou Redis OSS. Pour les clusters Valkey ou Redis OSS dotés de répliques, nous recommandons de mettre suffisamment de mémoire à la disposition de Valkey ou Redis OSS.
**Topics**
+ [Augmenter les clusters Valkey ou Redis OSS avec des répliques](#Scaling.RedisReplGrps.ScaleUp)
+ [Réduction de la taille des clusters Valkey ou Redis OSS avec des répliques](#Scaling.RedisReplGrps.ScaleDown)
+ [Augmentation de la capacité de lecture](#Scaling.RedisReplGrps.ScaleOut)
+ [Diminution de la capacité de lecture](#Scaling.RedisReplGrps.ScaleIn)
**Rubriques connexes**
+ [Haute disponibilité avec les groupes de réplication](Replication.md)
+ [Réplication : mode cluster Valkey et Redis OSS désactivé ou activé](Replication.Redis-RedisCluster.md)
+ [Minimiser les temps d'arrêt en ElastiCache utilisant le multi-AZ avec Valkey et Redis OSS](AutoFailover.md)
+ [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md)
**Topics**
+ [Augmenter les clusters Valkey ou Redis OSS avec des répliques](#Scaling.RedisReplGrps.ScaleUp)
+ [Réduction de la taille des clusters Valkey ou Redis OSS avec des répliques](#Scaling.RedisReplGrps.ScaleDown)
+ [Augmentation de la capacité de lecture](#Scaling.RedisReplGrps.ScaleOut)
+ [Diminution de la capacité de lecture](#Scaling.RedisReplGrps.ScaleIn)
## Augmenter les clusters Valkey ou Redis OSS avec des répliques
Amazon ElastiCache fournit un support de console, de CLI et d'API pour dimensionner votre groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) vers le haut.
Lorsque le processus de mise à l'échelle est lancé, ElastiCache effectue les opérations suivantes :
1. Il lance un groupe de réplication à l'aide du nouveau type de nœud.
1. Il copie toutes les données du nœud principal actuel vers le nouveau nœud principal.
1. Il synchronise les nouveaux réplicas en lecture avec le nouveau nœud principal.
1. Il met à jour les entrées DNS afin qu'elles pointent vers les nouveaux nœuds. Ainsi, vous n'aurez plus besoin de mettre à jour les points de terminaison de votre application. Pour Valkey 7.2 et versions ultérieures ou Redis OSS 5.0.5 et versions ultérieures, vous pouvez dimensionner les clusters compatibles avec le basculement automatique pendant que le cluster reste en ligne et traite les demandes entrantes. Sur les versions 4.0.10 et antérieures de Redis OSS, vous remarquerez peut-être une brève interruption des lectures et des écritures sur les versions précédentes depuis le nœud principal pendant la mise à jour de l'entrée DNS.
1. Il supprime les anciens nœuds (CLI/API : groupe de réplication). Vous remarquerez une brève interruption (quelques secondes) des lectures et des écritures à partir des anciens nœuds car les connexions aux anciens nœuds seront déconnectées.
La durée de ce processus dépend de votre type de nœud et de la quantité de données dans votre cluster.
Comme indiqué dans le tableau suivant, votre opération de mise à l'échelle de Valkey ou Redis OSS est bloquée si une mise à niveau du moteur est planifiée pour la prochaine fenêtre de maintenance du cluster.
**Opérations Valkey ou Redis OSS bloquées**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/Scaling.RedisReplGrps.html)
Si vous avez une opération en suspens qui vous bloque, vous pouvez effectuer l'une des actions suivantes.
+ Planifiez votre opération de mise à l'échelle de Valkey ou Redis OSS pour la prochaine fenêtre de maintenance en décochant la case **Appliquer immédiatement** (utilisation de la CLI :`--no-apply-immediately`, utilisation de l'API :). `ApplyImmediately=false`
+ Attendez votre prochaine fenêtre de maintenance (ou après) pour effectuer votre opération de mise à l'échelle de Valkey ou Redis OSS.
+ Ajoutez la mise à niveau du moteur Valkey ou Redis OSS à cette modification de cluster en cochant la case **Appliquer immédiatement** (utilisation de la CLI :`--apply-immediately`, utilisation de l'API :`ApplyImmediately=true`). Cela permet de débloquer votre opération de mise à l'échelle en provoquant une mise à jour du moteur à effectuer immédiatement.
Les sections suivantes décrivent comment redimensionner votre cluster Valkey ou Redis OSS avec des répliques à l'aide de la ElastiCache console, de l'API et de l'AWS CLI API. ElastiCache
**Important**
Si votre groupe de paramètres est utilisé `reserved-memory` pour réserver de la mémoire pour la surcharge de Valkey ou Redis OSS, avant de commencer le dimensionnement, assurez-vous de disposer d'un groupe de paramètres personnalisé qui réserve la quantité de mémoire appropriée pour votre nouveau type de nœud. Vous pouvez aussi modifier un groupe de paramètres personnalisé de façon à ce qu'il utilise `reserved-memory-percent` et vous servir de ce groupe de paramètres pour votre nouveau cluster.
Si vous utilisez `reserved-memory-percent`, cette opération n'est pas nécessaire.
Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
### Mise à l'échelle d'un cluster Valkey ou Redis OSS avec des répliques (console)
La durée nécessaire pour redimensionner la taille d'un type de nœud et passer à un type plus grand, varie selon le type de nœud et la quantité de données dans votre cluster de actuel.
Le processus suivant fait évoluer votre cluster avec des répliques de son type de nœud actuel vers un nouveau type de nœud plus grand à l'aide de la ElastiCache console. Pendant ce processus, une brève interruption des lectures et des écritures peut avoir lieu pour d'autres versions à partir du nœud primaire pendant que l'entrée DNS est mise à jour. Vous pouvez constater un temps d'arrêt inférieur à une seconde pour les nœuds s'exécutant sur les versions 5.0.6 et de l'ordre de quelques secondes pour les versions plus anciennes.
**Pour augmenter le cluster Valkey ou Redis OSS avec des répliques (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey clusters** ou **Redis OSS** clusters
1. Dans la liste des clusters, choisissez le cluster que vous souhaitez augmenter. Ce cluster doit exécuter le moteur Valkey ou Redis OSS et non le moteur Valkey ou Redis OSS en cluster.
1. Sélectionnez **Modifier**.
1. Dans l'assistant **Modifier le cluster** :
1. Choisissez le type de nœud auquel vous souhaitez passer dans la liste **Type de nœud**. Notez que tous les types de nœuds ne sont pas disponibles pour la réduction de la capacité.
1. Si vous utilisez `reserved-memory` pour gérer la mémoire, dans la liste **Groupe de paramètres**, choisissez le groupe de paramètres personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud.
1. Si vous souhaitez effectuer un processus de mise à l'échelle immédiatement, choisissez la case **Apply immediately**. Si la case **Apply immediately** est décochée, le processus de mise à l'échelle est effectué lors du créneau de maintenance suivant du cluster.
1. Sélectionnez **Modifier**.
1. Lorsque le statut du cluster passe de *modifying* à *available*, cela signifie que votre cluster est passé au nouveau type de nœud. Il n'est pas nécessaire de mettre à jour les points de terminaison dans votre application.
### Mise à l'échelle d'un groupe de réplication Valkey ou Redis OSS ()AWS CLI
Le processus suivant met à l'échelle votre groupe de réplication à partir de son type de nœud actuel vers un nouveau type de nœud plus grand à l'aide de l'AWS CLI. Au cours de ce processus, ElastiCache met à jour les entrées DNS afin qu'elles pointent vers les nouveaux nœuds. Ainsi, vous n'aurez plus besoin de mettre à jour les points de terminaison de votre application. Pour Valkey 7.2 et versions ultérieures ou Redis OSS 5.0.5 et versions ultérieures, vous pouvez dimensionner les clusters compatibles avec le basculement automatique pendant que le cluster reste en ligne et traite les demandes entrantes. Sur les versions 4.0.10 ou antérieures, vous pouvez remarquer une brève interruption des lectures et des écritures sur les versions précédentes à partir du nœud primaire pendant que l'entrée DNS est mise à jour.
Le temps nécessaire pour passer à un type de nœud plus important varie en fonction de votre type de nœud et de la quantité de données dans votre cluster actuel.
**Pour agrandir un groupe de réplication Valkey ou Redis OSS ()AWS CLI**
1. Déterminez les types de nœuds que vous pouvez augmenter en exécutant la AWS CLI`list-allowed-node-type-modifications` commande avec le paramètre suivant.
+ `--replication-group-id` – Le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication particulier plutôt que tous les groupes de réplication.
Pour Linux, macOS ou Unix :
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Pour Windows :
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
Le résultat de cette opération doit ressembler à ce qui suit (format JSON).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
```
Pour plus d'informations, consultez [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) dans la *référence AWS CLI*.
1. Adaptez votre groupe de réplication actuel au nouveau type de nœud à l'aide de la AWS CLI`modify-replication-group` commande avec les paramètres suivants.
+ `--replication-group-id` : le nom du groupe de réplication.
+ `--cache-node-type`— le nouveau type de nœud plus grand des clusters de ce groupe de réplication. Cette valeur doit être l'un des types d'instance renvoyés par la `list-allowed-node-type-modifications` commande à l'étape précédente.
+ `--cache-parameter-group-name` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `--apply-immediately` : ce paramètre entraîne l'application immédiate du processus d'augmentation. Pour reporter l'opération de mise à l'échelle au créneau de maintenance suivant, utilisez `--no-apply-immediately`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id my-repl-group \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id my-repl-group ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Le résultat de cette commande doit ressembler à ce qui suit (format JSON).
```
{
"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [{
"Status": "available",
"NodeGroupMembers": [{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002"
],
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) dans la *référence AWS CLI*.
1. Si vous avez utilisé le `--apply-immediately` paramètre, surveillez l'état du groupe de réplication à l'aide de la AWS CLI`describe-replication-group` commande avec le paramètre suivant. Pendant que le statut est encore *modification en cours*, vous pouvez constater un temps d'arrêt inférieur à 1 seconde pour les nœuds s'exécutant sur les versions 5.0.6 et une brève interruption des lectures et des écritures pour les versions plus anciennes à partir du nœud primaire pendant que l'entrée DNS est mise à jour.
+ `--replication-group-id` – Le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication particulier plutôt que tous les groupes de réplication.
Pour Linux, macOS ou Unix :
```
aws elasticache describe-replication-groups \
--replication-group-id my-replication-group
```
Pour Windows :
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Pour plus d'informations, consultez [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) dans la *référence AWS CLI*.
### Mise à l'échelle d'un groupe de réplication (ElastiCache API) Valkey ou Redis OSS
Le processus suivant fait passer votre groupe de réplication de son type de nœud actuel à un nouveau type de nœud plus important à l'aide de l' ElastiCache API. Pour Valkey 7.2 et versions ultérieures ou Redis OSS 5.0.5 et versions ultérieures, vous pouvez dimensionner les clusters compatibles avec le basculement automatique pendant que le cluster reste en ligne et traite les demandes entrantes. Sur les versions Redis OSS 4.0.10 et antérieures, vous remarquerez peut-être une brève interruption des lectures et des écritures sur les versions précédentes depuis le nœud principal pendant la mise à jour de l'entrée DNS.
Le temps nécessaire pour passer à un type de nœud plus important varie en fonction de votre type de nœud et de la quantité de données dans votre cluster actuel.
**Pour étendre un groupe de réplication (ElastiCache API) Valkey ou Redis OSS**
1. Déterminez les types de nœuds que vous pouvez augmenter à l'aide de l'`ListAllowedNodeTypeModifications`action d' ElastiCache API avec le paramètre suivant.
+ `ReplicationGroupId` : le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication spécifique plutôt que tous les groupes de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) le *Amazon ElastiCache API Reference*.
1. Adaptez votre groupe de réplication actuel au nouveau type de nœud à l'aide de l'action `ModifyReplicationGroup` ElastiCache API et avec les paramètres suivants.
+ `ReplicationGroupId` : le nom du groupe de réplication.
+ `CacheNodeType`— le nouveau type de nœud plus grand des clusters de ce groupe de réplication. Cette valeur doit être l'un des types d'instance renvoyés par l'`ListAllowedNodeTypeModifications`action de l'étape précédente.
+ `CacheParameterGroupName` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `ApplyImmediately` : lorsqu'il est défini sur `true`, il entraîne l'application immédiate du processus d'augmentation. Pour reporter le processus de mise à l'échelle au créneau de maintenance suivant, utilisez `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Pour plus d'informations, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) le *Amazon ElastiCache API Reference*.
1. Si vous l'avez utilisé `ApplyImmediately``=true`, surveillez l'état du groupe de réplication à l'aide de l'`DescribeReplicationGroups`action ElastiCache API avec les paramètres suivants. Lorsque le statut passe de *modifying* à *available*, cela signifie que vous pouvez commencer à écrire sur votre nouveau groupe de réplication redimensionné.
+ `ReplicationGroupId` – Le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication particulier plutôt que tous les groupes de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) le *Amazon ElastiCache API Reference*.
## Réduction de la taille des clusters Valkey ou Redis OSS avec des répliques
Les sections suivantes vous expliquent comment redimensionner un cluster Valkey ou Redis OSS (mode cluster désactivé) avec des répliques de nœuds jusqu'à un type de nœud plus petit. Pour des raisons de performances, il faut s'assurer que le nouveau type de nœud plus petit a une capacité suffisante pour supporter toutes les données et les besoins de traitement. Pour de plus amples informations, veuillez consulter [S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS](BestPractices.BGSAVE.md).
**Note**
Pour les clusters exécutant le type de nœud r6gd, vous pouvez uniquement mettre à l’échelle en fonction des tailles de nœuds au sein de la famille de nœuds r6gd.
**Important**
Si votre groupe de paramètres est utilisé `reserved-memory` pour réserver de la mémoire pour la surcharge de Valkey ou Redis OSS, avant de commencer le dimensionnement, assurez-vous de disposer d'un groupe de paramètres personnalisé qui réserve la quantité de mémoire appropriée pour votre nouveau type de nœud. Vous pouvez aussi modifier un groupe de paramètres personnalisé de façon à ce qu'il utilise `reserved-memory-percent` et vous servir de ce groupe de paramètres pour votre nouveau cluster.
Si vous utilisez `reserved-memory-percent`, cette opération n'est pas nécessaire.
Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
**Topics**
### Réduction de la taille d'un cluster Valkey ou Redis OSS avec des répliques (console)
Le processus suivant fait évoluer votre cluster Valkey ou Redis OSS avec des nœuds répliques vers un type de nœud plus petit à l'aide de la ElastiCache console.
**Pour réduire la taille d'un cluster Valkey ou Redis OSS avec des nœuds de réplication (console)**
1. Assurez-vous que le type de nœud plus petit soit suffisant pour supporter vos données et les besoins de traitement.
1. Si votre groupe de paramètres est utilisé `reserved-memory` pour réserver de la mémoire pour la surcharge de Valkey ou Redis OSS, assurez-vous de disposer d'un groupe de paramètres personnalisé pour réserver la quantité de mémoire appropriée pour votre nouveau type de nœud.
Vous pouvez aussi modifier votre groupe de paramètres personnalisé de façon à utiliser `reserved-memory-percent`. Pour de plus amples informations, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans la liste des clusters, choisissez le cluster que dont vous souhaitez baisser la capacité. Ce cluster doit exécuter le moteur Valkey ou Redis OSS et non le moteur Valkey ou Redis OSS en cluster.
1. Sélectionnez **Modifier**.
1. Dans l'assistant **Modifier le cluster** :
1. Choisissez le type de nœud dont vous souhaitez baisser la capacité dans la liste **Type de nœud**.
1. Si vous utilisez `reserved-memory` pour gérer la mémoire, dans la liste **Groupe de paramètres**, choisissez le groupe de paramètres personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud.
1. Si vous souhaitez effectuer le processus de diminution de la capacité immédiatement, choisissez la case **Apply immediately**. Si la case **Apply immediately** est décochée, le processus de diminution de la capacité est effectué lors du créneau de maintenance suivant du cluster.
1. Sélectionnez **Modifier**.
1. Lorsque le statut du cluster passe de *modifying* à *available*, cela signifie que votre cluster est passé au nouveau type de nœud. Il n'est pas nécessaire de mettre à jour les points de terminaison dans votre application.
### Réduction de la taille d'un groupe de réplication Valkey ou Redis OSS ()AWS CLI
Le processus suivant met à l'échelle votre groupe de réplication à partir de son type de nœud actuel vers un nouveau type de nœud plus petit à l'aide de l'AWS CLI. Au cours de ce processus, ElastiCache met à jour les entrées DNS afin qu'elles pointent vers les nouveaux nœuds. Ainsi, vous n'aurez plus besoin de mettre à jour les points de terminaison de votre application. Pour Valkey 7.2 ou Redis OSS 5.0.5 et versions ultérieures, vous pouvez dimensionner les clusters compatibles avec le basculement automatique pendant que le cluster reste en ligne et traite les demandes entrantes. Sur les versions 4.0.10 ou antérieures, vous pouvez remarquer une brève interruption des lectures et des écritures sur les versions précédentes à partir du nœud primaire pendant que l'entrée DNS est mise à jour.
Cependant, les lectures à partir des clusters de répliques lues se poursuivent sans interruption.
Le temps nécessaire pour passer à un type de nœud plus petit varie en fonction de votre type de nœud et de la quantité de données dans votre cluster actuel.
**Pour réduire un groupe de réplication Valkey ou Redis OSS ()AWS CLI**
1. Déterminez les types de nœuds que vous pouvez réduire en exécutant la AWS CLI`list-allowed-node-type-modifications` commande avec le paramètre suivant.
+ `--replication-group-id` – Le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication particulier plutôt que tous les groupes de réplication.
Pour Linux, macOS ou Unix :
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Pour Windows :
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
Le résultat de cette opération doit ressembler à ce qui suit (format JSON).
```
{
"ScaleDownModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
```
Pour plus d'informations, consultez [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) dans la *référence AWS CLI*.
1. Adaptez votre groupe de réplication actuel au nouveau type de nœud à l'aide de la AWS CLI`modify-replication-group` commande avec les paramètres suivants.
+ `--replication-group-id` : le nom du groupe de réplication.
+ `--cache-node-type`— le nouveau type de nœud plus petit des clusters de ce groupe de réplication. Cette valeur doit être l'un des types d'instance renvoyés par la `list-allowed-node-type-modifications` commande à l'étape précédente.
+ `--cache-parameter-group-name` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `--apply-immediately` : ce paramètre entraîne l'application immédiate du processus d'augmentation. Pour reporter l'opération de mise à l'échelle au créneau de maintenance suivant, utilisez `--no-apply-immediately`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id my-repl-group \
--cache-node-type cache.t2.small \
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id my-repl-group ^
--cache-node-type cache.t2.small ^
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Le résultat de cette commande doit ressembler à ce qui suit (format JSON).
```
{"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002",
],
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) dans la *référence AWS CLI*.
1. Si vous avez utilisé le `--apply-immediately` paramètre, surveillez l'état du groupe de réplication à l'aide de la AWS CLI`describe-replication-group` commande avec le paramètre suivant. Lorsque le statut passe de *modification* à *disponible*, vous pouvez commencer à écrire dans votre nouveau groupe de réplication réduit.
+ `--replication-group-id` – Le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication particulier plutôt que tous les groupes de réplication.
Pour Linux, macOS ou Unix :
```
aws elasticache describe-replication-group \
--replication-group-id my-replication-group
```
Pour Windows :
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Pour plus d'informations, consultez [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) dans la *référence AWS CLI*.
### Réduction de la taille d'un groupe de réplication (ElastiCache API) Valkey ou Redis OSS
Le processus suivant fait passer votre groupe de réplication de son type de nœud actuel à un nouveau type de nœud plus petit à l'aide de l' ElastiCache API. Au cours de ce processus, ElastiCache met à jour les entrées DNS afin qu'elles pointent vers les nouveaux nœuds. Ainsi, vous n'aurez plus besoin de mettre à jour les points de terminaison de votre application. Pour Valkey 7.2 et versions ultérieures ou Redis OSS 5.0.5 et versions ultérieures, vous pouvez dimensionner les clusters compatibles avec le basculement automatique pendant que le cluster reste en ligne et traite les demandes entrantes. Sur Redis OSS version 4.0.10 et antérieures, vous remarquerez peut-être une brève interruption des lectures et des écritures sur les versions précédentes depuis le nœud principal pendant la mise à jour de l'entrée DNS. Cependant, les lectures à partir des clusters de répliques lues se poursuivent sans interruption.
Le temps nécessaire pour passer à un type de nœud plus petit varie en fonction de votre type de nœud et de la quantité de données dans votre cluster actuel.
**Pour réduire un groupe de réplication (ElastiCache API) Valkey ou Redis OSS**
1. Déterminez les types de nœuds que vous pouvez réduire à l'aide de l'`ListAllowedNodeTypeModifications`action d' ElastiCache API avec le paramètre suivant.
+ `ReplicationGroupId` : le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication spécifique plutôt que tous les groupes de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) le *Amazon ElastiCache API Reference*.
1. Adaptez votre groupe de réplication actuel au nouveau type de nœud à l'aide de l'action `ModifyReplicationGroup` ElastiCache API et avec les paramètres suivants.
+ `ReplicationGroupId` : le nom du groupe de réplication.
+ `CacheNodeType`— le nouveau type de nœud plus petit des clusters de ce groupe de réplication. Cette valeur doit être l'un des types d'instance renvoyés par l'`ListAllowedNodeTypeModifications`action de l'étape précédente.
+ `CacheParameterGroupName` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `ApplyImmediately` – Lorsqu'il est défini sur `true`, il entraîne l'application immédiate du processus d'augmentation. Pour reporter le processus de réduction à la prochaine fenêtre de maintenance, utilisez `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Pour plus d'informations, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) le *Amazon ElastiCache API Reference*.
1. Si vous l'avez utilisé `ApplyImmediately``=true`, surveillez l'état du groupe de réplication à l'aide de l'`DescribeReplicationGroups`action ElastiCache API avec les paramètres suivants. Lorsque le statut passe de *modification* à *disponible*, vous pouvez commencer à écrire dans votre nouveau groupe de réplication réduit.
+ `ReplicationGroupId` – Le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication particulier plutôt que tous les groupes de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) le *Amazon ElastiCache API Reference*.
## Augmentation de la capacité de lecture
Pour augmenter la capacité de lecture, ajoutez des répliques de lecture (cinq au maximum) à votre groupe de réplication Valkey ou Redis OSS.
Vous pouvez augmenter la capacité de lecture de votre cluster Valkey ou Redis OSS à l'aide de la ElastiCache console, de l'API AWS CLI ou de l' ElastiCache API. Pour de plus amples informations, veuillez consulter [Ajouter une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé)](Replication.AddReadReplica.md).
## Diminution de la capacité de lecture
Pour réduire la capacité de lecture, supprimez une ou plusieurs répliques de lecture de votre cluster Valkey ou Redis OSS contenant des répliques (appelé *groupe de réplication* dans l'API/CLI). Si le mode Multi-AZ avec basculement automatique est activé pour ce cluster, vous ne pouvez pas supprimer le dernier réplica en lecture sans désactiver au préalable le mode Multi-AZ. Pour de plus amples informations, veuillez consulter [Modification d'un groupe de réplication](Replication.Modify.md).
Pour de plus amples informations, veuillez consulter [Suppression d'une réplique de lecture pour Valkey ou Redis OSS (mode cluster désactivé)](Replication.RemoveReadReplica.md).
# Mise à l'échelle des clusters Valkey ou Redis OSS (mode cluster activé)
À mesure que la demande de vos clusters évolue, vous pouvez décider d'améliorer les performances ou de réduire les coûts en modifiant le nombre de partitions dans votre cluster Valkey ou Redis OSS (mode cluster activé). Il est recommandé d'utiliser à cette fin la mise à l'échelle horizontal en ligne, parce que votre cluster peut ainsi continuer à traiter les demandes pendant le processus de mise à l'échelle.
Les conditions qui peuvent vous conduire à décider de redimensionner votre cluster sont les suivantes :
+ **Pression mémoire :**
Si les nœuds de votre cluster sont sous pression mémoire, vous pouvez décider de l'augmenter de telle sorte que vous ayez plus de ressources pour mieux stocker les données et traiter les demandes.
Vous pouvez déterminer si vos nœuds sont soumis à une pression de mémoire en surveillant les indicateurs suivants : *FreeableMemory*SwapUsage**, et *BytesUsedForCache*.
+ **Goulet d'étranglement UC ou réseau :**
Si latency/throughput des problèmes affectent votre cluster, vous devrez peut-être le redimensionner pour les résoudre.
Vous pouvez surveiller vos niveaux de latence et de débit en surveillant les métriques suivantes : *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*CurrConnections**, et *NewConnections*.
+ **Votre cluster est surdimensionné :**
La demande courante sur votre cluster est telle que la mise à l'échelle ne nuit pas aux performances et réduit vos coûts.
Vous pouvez surveiller l'utilisation de votre cluster pour déterminer si vous pouvez ou non l'adapter en toute sécurité à l'aide des métriques suivantes : *FreeableMemory*SwapUsage*BytesUsedForCache***, *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*, *CurrConnections*, et *NewConnections*.
**Impact la mise à l'échelle sur les performances**
Lorsque vous dimensionnez à l'aide du processus hors ligne, votre cluster se retrouve hors ligne pendant une partie importante du processus et de ce fait vous ne pouvez pas traiter les demandes. Lorsque vous mettez à l'échelle à l'aide de la méthode en ligne, comme la mise à l'échelle est une opération gourmande en ressources de calcul, il en résulte une certaine dégradation des performances ; néanmoins, votre cluster continue à traiter les demandes d'un bout à l'autre de l'opération de mise à l'échelle. L'importance de la dégradation à laquelle vous êtes confronté dépend de votre utilisation normale de l'UC et de vos données.
Il existe deux manières de redimensionner votre cluster Valkey ou Redis OSS (mode cluster activé) : mise à l'échelle horizontale et verticale.
+ Le dimensionnement horizontal vous permet de modifier le nombre de groupes de nœuds (partitions) dans le groupe de réplication en ajoutant ou en supprimant des groupes de nœuds (partitions). Le processus de repartage en ligne permet une mise à l'échelle in/out pendant que le cluster continue de traiter les demandes entrantes.
Configurer les emplacements de votre nouveau cluster différemment qu'ils ne l'étaient dans l'ancien cluster. Méthode hors ligne uniquement.
+ Dimensionnement vertical : modifier le type de nœud pour redimensionner le cluster. La mise à l'échelle verticale en ligne permet une mise à l'échelle up/down pendant que le cluster continue de traiter les demandes entrantes.
Si vous réduisez la taille et la capacité de mémoire du cluster, en augmentant ou en diminuant la taille, assurez-vous que la nouvelle configuration dispose de suffisamment de mémoire pour vos données et pour la surcharge de Valkey ou Redis OSS.
Pour de plus amples informations, veuillez consulter [Choix de la taille de votre nœud](CacheNodes.SelectSize.md).
**Contents**
+ [Repartage hors ligne pour Valkey ou Redis OSS (mode cluster activé)](#redis-cluster-resharding-offline)
+ [Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)](#redis-cluster-resharding-online)
+ [Ajout de partitions avec le repartitionnement en ligne](#redis-cluster-resharding-online-add)
+ [Suppression de partitions avec le repartitionnement en ligne](#redis-cluster-resharding-online-remove)
+ [Suppression de partitions (console)](#redis-cluster-resharding-online-remove-console)
+ [Suppression de partitions (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Supprimer des fragments (ElastiCacheAPI)](#redis-cluster-resharding-online-remove-api)
+ [Rééquilibrage en ligne des partitions](#redis-cluster-resharding-online-rebalance)
+ [Rééquilibrage en ligne des partitions (console)](#redis-cluster-resharding-online-rebalance-console)
+ [Rééquilibrage des partitions en ligne (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Rééquilibrage des partitions en ligne (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
+ [Dimensionnement vertical en ligne en modifiant le type de nœud](redis-cluster-vertical-scaling.md)
+ [Augmentation en ligne](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (console)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-console)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS ()AWS CLI](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (API) ElastiCache](redis-cluster-vertical-scaling.md#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Réduction en ligne](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-down)
+ [Réduction de la taille des clusters Valkey ou Redis OSS (console)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-down-console)
+ [Réduction de la taille des clusters Valkey ou Redis OSS ()AWS CLI](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Réduction de la taille des clusters Valkey ou Redis OSS (API) ElastiCache](redis-cluster-vertical-scaling.md#Scaling.Vertical.ScaleDown.API)
## Repartage hors ligne pour Valkey ou Redis OSS (mode cluster activé)
Le principal avantage de la reconfiguration des partitions hors ligne est que vous pouvez faire bien plus qu'ajouter ou supprimer simplement des partitions de votre groupe de réplication. Lorsque vous redimensionnez et rééquilibrez hors ligne, en plus de modifier le nombre de partitions dans votre groupe de réplication, vous pouvez effectuer les opérations suivantes :
**Note**
Le repartage hors ligne n'est pas pris en charge sur les clusters Valkey ou Redis OSS avec la hiérarchisation des données activée. Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
+ Modifier le type de nœud de votre groupe de réplication.
+ Spécifier la zone de disponibilité de chaque nœud du groupe de réplication.
+ Mettre à niveau vers une version plus récente du moteur.
+ Spécifier le nombre de nœuds de réplicas dans chaque partition indépendamment.
+ Spécifiez l'espace de clés de chaque partition.
Le principal désavantage de la reconfiguration hors ligne des partitions est que votre cluster est hors ligne depuis la partie restauration du processus jusqu'à ce que vous mettiez à jour les points de terminaison de votre application. La durée pendant laquelle votre cluster est hors ligne varie avec la quantité de données de votre cluster.
**Pour reconfigurer votre cluster de partitions Valkey ou Redis OSS (mode cluster activé) hors ligne**
1. Créez une sauvegarde manuelle de votre cluster Valkey ou Redis OSS existant. Pour de plus amples informations, veuillez consulter [Réalisation de sauvegardes manuelles](backups-manual.md).
1. Créez un nouveau cluster en restaurant la sauvegarde. Pour de plus amples informations, veuillez consulter [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
1. Mettez à jour les points de terminaison dans votre application sur les points de terminaison du nouveau cluster. Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md).
## Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)
En utilisant le repartage en ligne et le rééquilibrage des partitions avec ElastiCache Valkey 7.2 ou version ultérieure, ou Redis OSS version 3.2.10 ou ultérieure, vous pouvez faire évoluer votre cluster Valkey ou Redis OSS (mode cluster activé) de manière dynamique sans interruption de service. Cette approche signifie que votre cluster peut continuer à traiter des demandes même lorsqu'une mise à l'échelle ou un rééquilibrage est en cours.
Vous pouvez effectuer les opérations suivantes :
+ **Dimensionnement** : augmentez la capacité de lecture et d'écriture en ajoutant des fragments (groupes de nœuds) à votre cluster Valkey ou Redis OSS (mode cluster activé) (groupe de réplication).
Si vous ajoutez une ou plusieurs partitions à votre groupe de réplication, le nombre de nœuds de chaque nouvelle partition est identique au nombre de nœuds de la plus petite des partitions existantes.
+ **Évolutivité** : réduisez la capacité de lecture et d'écriture, et donc les coûts, en supprimant les fragments de votre cluster Valkey ou Redis OSS (mode cluster activé).
+ **Rééquilibrage** — Déplacez les espaces clés entre les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) afin qu'ils soient répartis de la manière la plus égale possible entre les partitions.
Vous ne pouvez pas exécuter les actions suivantes :
+ **Configurer les partitions indépendamment :**
Vous ne pouvez pas spécifier l'espace de clés des partitions indépendamment. Pour ce faire, vous devez utiliser le processus hors ligne.
Actuellement, les restrictions suivantes s'appliquent au repartage et au rééquilibrage ElastiCache en ligne :
+ Ces processus nécessitent Valkey 7.2 ou version ultérieure ou Redis OSS 3.2.10 ou version ultérieure. Pour plus d'informations sur la mise à niveau de la version de votre moteur, consultez [Gestion des versions pour ElastiCache](VersionManagement.md).
+ Il existe des limitations pour les emplacements et les espaces de clés ou les éléments volumineux :
Si l'une des clés d'une partition contient un élément volumineux, cette clé ne peut pas faire l'objet d'une nouvelle migration lors d'une montée en charge ou d'un rééquilibrage. Cette fonctionnalité peut se traduire par des partitions non équilibrées.
Si l'une des clés d'une partition contient un élément volumineux (supérieur à 256 Mo après sérialisation), cette partition n'est pas supprimée lors de l'agrandissement. Cette fonctionnalité peut se traduire par le fait que certaines partitions ne sont pas supprimées.
+ Lors de l'agrandissement, le nombre de nœuds des nouvelles partitions est égal au nombre de nœuds de la plus petite partition existante.
+ Lors de la réduction, les balises communes à toutes les partitions existantes sont copiées sur les nouvelles partitions.
+ Lors de la mise à l'échelle d'un cluster Global Data Store, les fonctions ne ElastiCache seront pas automatiquement répliquées depuis l'un des nœuds existants vers le ou les nouveaux nœuds. Nous vous recommandons de charger vos fonctions dans la ou les nouvelles partitions après avoir fait monter en puissance votre cluster afin que toutes les partitions aient les mêmes fonctions.
**Note**
ElastiCache Pour Valkey 7.2 et versions ultérieures, et ElastiCache pour Redis OSS version 7 et ultérieure : lors de la mise à l'échelle de votre cluster, les fonctions chargées dans l'un des nœuds existants (sélectionnées au hasard) ElastiCache seront automatiquement répliquées sur le ou les nouveaux nœuds. Si votre application utilise des [fonctions](https://valkey.io/topics/functions-intro/), nous vous recommandons de charger toutes vos fonctions sur toutes les partitions avant de les redimensionner afin que votre cluster ne se retrouve pas avec des définitions de fonctions différentes sur différentes partitions.
Pour de plus amples informations, veuillez consulter [Redimensionnement de cluster en ligne](best-practices-online-resharding.md).
Vous pouvez redimensionner ou rééquilibrer horizontalement vos clusters Valkey ou Redis OSS (mode cluster activé) à l'aide de l'API AWS Management Console, du et de l'AWS CLI API. ElastiCache
### Ajout de partitions avec le repartitionnement en ligne
Vous pouvez ajouter des partitions à votre cluster Valkey ou Redis OSS (mode cluster activé) à l'aide de l'API AWS Management ConsoleAWS CLI, ou. ElastiCache Lorsque vous ajoutez des partitions à un cluster Valkey ou Redis OSS (mode cluster activé), toutes les balises des partitions existantes sont copiées sur les nouvelles partitions.
**Topics**
#### Ajout de partitions (console)
Vous pouvez utiliser le AWS Management Console pour ajouter une ou plusieurs partitions à votre cluster Valkey ou Redis OSS (mode cluster activé). La procédure suivante décrit le processus.
**Pour ajouter des partitions à votre cluster Valkey ou Redis OSS (mode cluster activé)**
1. Ouvrez la ElastiCache console à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey clusters** ou **Redis OSS** clusters.
1. Recherchez et choisissez le nom, et non la case à gauche du nom du cluster, du cluster Valkey ou Redis OSS (mode cluster activé) auquel vous souhaitez ajouter des partitions.
**Astuce**
**Valkey ou Redis OSS (mode cluster activé) Afficher **Clusterisé Valkey ou Clusterisé** **Redis OSS dans la colonne** Mode**
1. Choisissez **Ajouter une partition**.
1. Pour **Nombre de partitions à ajouter**, choisissez le nombre de partitions que vous voulez ajouter au cluster.
1. Pour **Zones de disponibilité**, choisissez **Aucune préférence** ou **Spécifier les zones de disponibilité**.
1. Si vous choisissez **Spécifier les zones de disponibilité**, pour chaque nœud de chaque partition, sélectionnez la zone de disponibilité du nœud dans la liste Zones de disponibilité.
1. Choisissez **Ajouter**.
#### Ajout de partitions (AWS CLI)
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en ajoutant des partitions à l'aide du.AWS CLI
Utilisez les paramètres suivants avec `modify-replication-group-shard-configuration`.
**Parameters**
+ `--apply-immediately` – Obligatoire. Spécifie que l'opération de reconfiguration des partitions doit démarrer immédiatement.
+ `--replication-group-id` – Obligatoire. Spécifie sur quel groupe de réplication (cluster) l'opération de reconfiguration des partitions doit être exécutée.
+ `--node-group-count` – Obligatoire. Spécifie le nombre de partitions (groupes de nœuds) qui doivent exister une fois l'opération terminée. Lors de l'ajout des partitions, la valeur de `--node-group-count` doit être supérieure au nombre actuel de partitions.
Le cas échéant, vous pouvez spécifier la zone de disponibilité de chaque nœud du groupe de réplication avec `--resharding-configuration`.
+ `--resharding-configuration` : facultatif. Liste des zones de disponibilité favorites de chaque nœud de chaque partition du groupe de réplication. N'utilisez ce paramètre que si la valeur de `--node-group-count` est supérieure au nombre actuel de partitions. Si ce paramètre est omis lors de l'ajout de partitions, Amazon ElastiCache sélectionne les zones de disponibilité pour les nouveaux nœuds.
L'exemple suivant reconfigure les espaces clés sur quatre partitions dans un cluster Valkey ou Redis OSS (mode cluster activé) nommé. `my-cluster` L'exemple spécifie aussi la zone de disponibilité de chaque nœud de chaque partition. L'opération commence immédiatement.
**Example - Ajout de partitions**
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--resharding-configuration \
"PreferredAvailabilityZones=us-east-2a,us-east-2c" \
"PreferredAvailabilityZones=us-east-2b,us-east-2a" \
"PreferredAvailabilityZones=us-east-2c,us-east-2d" \
"PreferredAvailabilityZones=us-east-2d,us-east-2c" \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--resharding-configuration ^
"PreferredAvailabilityZones=us-east-2a,us-east-2c" ^
"PreferredAvailabilityZones=us-east-2b,us-east-2a" ^
"PreferredAvailabilityZones=us-east-2c,us-east-2d" ^
"PreferredAvailabilityZones=us-east-2d,us-east-2c" ^
--apply-immediately
```
Pour plus d'informations, consultez [modify-replication-group-shard-configuration](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html) dans la AWS CLI documentation.
#### Ajouter des partitions (ElastiCache API)
Vous pouvez utiliser l' ElastiCache API pour reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en ligne en utilisant l'opération. `ModifyReplicationGroupShardConfiguration`
Utilisez les paramètres suivants avec `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` – Obligatoire. Spécifie que l'opération de reconfiguration des partitions doit démarrer immédiatement.
+ `ReplicationGroupId` – Obligatoire. Spécifie sur quel groupe de réplication (cluster) l'opération de reconfiguration des partitions doit être exécutée.
+ `NodeGroupCount` – Obligatoire. Spécifie le nombre de partitions (groupes de nœuds) qui doivent exister une fois l'opération terminée. Lors de l'ajout des partitions, la valeur de `NodeGroupCount` doit être supérieure au nombre actuel de partitions.
Le cas échéant, vous pouvez spécifier la zone de disponibilité de chaque nœud du groupe de réplication avec `ReshardingConfiguration`.
+ `ReshardingConfiguration` : facultatif. Liste des zones de disponibilité favorites de chaque nœud de chaque partition du groupe de réplication. N'utilisez ce paramètre que si la valeur de `NodeGroupCount` est supérieure au nombre actuel de partitions. Si ce paramètre est omis lors de l'ajout de partitions, Amazon ElastiCache sélectionne les zones de disponibilité pour les nouveaux nœuds.
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en ajoutant des partitions à l'aide de l'API. ElastiCache
**Example - Ajout de partitions**
L'exemple suivant ajoute des groupes de nœuds au cluster Valkey ou Redis OSS (mode cluster activé)`my-cluster`, de sorte qu'il y a un total de quatre groupes de nœuds à la fin de l'opération. L'exemple spécifie aussi la zone de disponibilité de chaque nœud de chaque partition. L'opération commence immédiatement.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2a
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2b
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2a
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2c
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ModifyReplicationGroupShardConfiguration](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)la référence de ElastiCache l'API.
### Suppression de partitions avec le repartitionnement en ligne
Vous pouvez supprimer des fragments de votre cluster Valkey ou Redis OSS (mode cluster activé) à l'aide de l'API AWS Management ConsoleAWS CLI, ou. ElastiCache
**Topics**
+ [Suppression de partitions (console)](#redis-cluster-resharding-online-remove-console)
+ [Suppression de partitions (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Supprimer des fragments (ElastiCacheAPI)](#redis-cluster-resharding-online-remove-api)
#### Suppression de partitions (console)
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en supprimant les partitions à l'aide du.AWS Management Console
Avant de supprimer des groupes de nœuds (partitions) de votre groupe de réplication, ElastiCache assurez-vous que toutes vos données rentreront dans les partitions restantes. Si c'est le cas, les partitions spécifiées sont supprimées du groupe de réplication comme requis. Si les données ne tiennent pas dans les groupes de nœuds restants, la procédure est interrompue et le groupe de réplication est maintenu dans la même configuration de groupe de nœuds qu'avant que la demande ne soit envoyée.
Vous pouvez utiliser le AWS Management Console pour supprimer une ou plusieurs partitions de votre cluster Valkey ou Redis OSS (mode cluster activé). Vous pouvez supprimer toutes les partitions d'un groupe de réplication. Vous devez à la place supprimer l'ancien groupe de réplication. Pour de plus amples informations, veuillez consulter [Suppression d'un groupe de réplication](Replication.DeletingRepGroup.md). La procédure suivante décrit la suppression d'une ou plusieurs partitions.
**Pour supprimer des fragments de votre cluster Valkey ou Redis OSS (mode cluster activé)**
1. Ouvrez la ElastiCache console à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey clusters** ou **Redis OSS** clusters.
1. Recherchez et choisissez le nom, et non la case à gauche du nom du cluster, du cluster Valkey ou Redis OSS (mode cluster activé) dont vous souhaitez supprimer des partitions.
**Astuce**
Les clusters Valkey ou Redis OSS (mode cluster activé) ont une valeur supérieure ou égale à 1 dans la colonne **Shards**.
1. Dans la liste des partitions, cochez la case à gauche du nom de chaque partition que vous souhaitez supprimer.
1. Choisissez **Supprimer une partition**.
#### Suppression de partitions (AWS CLI)
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en supprimant les partitions à l'aide du.AWS CLI
**Important**
Avant de supprimer des groupes de nœuds (partitions) de votre groupe de réplication, ElastiCache assurez-vous que toutes vos données rentreront dans les partitions restantes. Si c'est le cas, les partitions spécifiées (`--node-groups-to-remove`) sont supprimés du groupe de réplication comme demandé, puis leurs espaces de clés sont mappés dans les partitions restantes. Si les données ne tiennent pas dans les groupes de nœuds restants, la procédure est interrompue et le groupe de réplication est maintenu dans la même configuration de groupe de nœuds qu'avant que la demande ne soit envoyée.
Vous pouvez utiliser le AWS CLI pour supprimer une ou plusieurs partitions de votre cluster Valkey ou Redis OSS (mode cluster activé). Vous pouvez supprimer toutes les partitions d'un groupe de réplication. Vous devez à la place supprimer l'ancien groupe de réplication. Pour de plus amples informations, veuillez consulter [Suppression d'un groupe de réplication](Replication.DeletingRepGroup.md).
Utilisez les paramètres suivants avec `modify-replication-group-shard-configuration`.
**Parameters**
+ `--apply-immediately` – Obligatoire. Spécifie que l'opération de reconfiguration des partitions doit démarrer immédiatement.
+ `--replication-group-id` – Obligatoire. Spécifie sur quel groupe de réplication (cluster) l'opération de reconfiguration des partitions doit être exécutée.
+ `--node-group-count` – Obligatoire. Spécifie le nombre de partitions (groupes de nœuds) qui doivent exister une fois l'opération terminée. Lors de la suppression des partitions, la valeur de `--node-group-count` doit être inférieure au nombre actuel de partitions.
+ `--node-groups-to-remove` – Obligatoire quand `--node-group-count` est inférieur au nombre actuel de groupes de nœuds (partitions). Liste des partitions (groupe de nœuds) IDs à supprimer du groupe de réplication.
La procédure suivante décrit la suppression d'une ou plusieurs partitions.
**Example – Suppression de partitions**
L'exemple suivant supprime deux groupes de nœuds du cluster Valkey ou Redis OSS (mode cluster activé)`my-cluster`, de sorte qu'il y a un total de deux groupes de nœuds à la fin de l'opération. Les espaces de clés des partitions supprimées sont répartis également sur les partitions restantes.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 2 \
--node-groups-to-remove "0002" "0003" \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 2 ^
--node-groups-to-remove "0002" "0003" ^
--apply-immediately
```
#### Supprimer des fragments (ElastiCacheAPI)
Vous pouvez utiliser l' ElastiCache API pour reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en ligne en utilisant l'opération. `ModifyReplicationGroupShardConfiguration`
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en supprimant les partitions à l'aide de l'API. ElastiCache
**Important**
Avant de supprimer des groupes de nœuds (partitions) de votre groupe de réplication, ElastiCache assurez-vous que toutes vos données rentreront dans les partitions restantes. Si c'est le cas, les partitions spécifiées (`NodeGroupsToRemove`) sont supprimés du groupe de réplication comme demandé, puis leurs espaces de clés sont mappés dans les partitions restantes. Si les données ne tiennent pas dans les groupes de nœuds restants, la procédure est interrompue et le groupe de réplication est maintenu dans la même configuration de groupe de nœuds qu'avant que la demande ne soit envoyée.
Vous pouvez utiliser l' ElastiCache API pour supprimer une ou plusieurs partitions de votre cluster Valkey ou Redis OSS (mode cluster activé). Vous pouvez supprimer toutes les partitions d'un groupe de réplication. Vous devez à la place supprimer l'ancien groupe de réplication. Pour de plus amples informations, veuillez consulter [Suppression d'un groupe de réplication](Replication.DeletingRepGroup.md).
Utilisez les paramètres suivants avec `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` – Obligatoire. Spécifie que l'opération de reconfiguration des partitions doit démarrer immédiatement.
+ `ReplicationGroupId` – Obligatoire. Spécifie sur quel groupe de réplication (cluster) l'opération de reconfiguration des partitions doit être exécutée.
+ `NodeGroupCount` – Obligatoire. Spécifie le nombre de partitions (groupes de nœuds) qui doivent exister une fois l'opération terminée. Lors de la suppression des partitions, la valeur de `NodeGroupCount` doit être inférieure au nombre actuel de partitions.
+ `NodeGroupsToRemove` – Obligatoire quand `--node-group-count` est inférieur au nombre actuel de groupes de nœuds (partitions). Liste des partitions (groupe de nœuds) IDs à supprimer du groupe de réplication.
La procédure suivante décrit la suppression d'une ou plusieurs partitions.
**Example – Suppression de partitions**
L'exemple suivant supprime deux groupes de nœuds du cluster Valkey ou Redis OSS (mode cluster activé)`my-cluster`, de sorte qu'il y a un total de deux groupes de nœuds à la fin de l'opération. Les espaces de clés des partitions supprimées sont répartis également sur les partitions restantes.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=2
&ReplicationGroupId=my-cluster
&NodeGroupsToRemove.member.1=0002
&NodeGroupsToRemove.member.2=0003
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
### Rééquilibrage en ligne des partitions
Vous pouvez rééquilibrer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) à l'aide de l'API AWS Management Console,AWS CLI ou. ElastiCache
**Topics**
+ [Rééquilibrage en ligne des partitions (console)](#redis-cluster-resharding-online-rebalance-console)
+ [Rééquilibrage des partitions en ligne (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Rééquilibrage des partitions en ligne (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
#### Rééquilibrage en ligne des partitions (console)
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en rééquilibrant les partitions à l'aide du.AWS Management Console
**Pour rééquilibrer les espaces clés entre les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé)**
1. Ouvrez la ElastiCache console à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey clusters** ou **Redis OSS** clusters.
1. Choisissez le nom, et non la case à gauche du nom, du cluster Valkey ou Redis OSS (mode cluster activé) que vous souhaitez rééquilibrer.
**Astuce**
Les clusters Valkey ou Redis OSS (mode cluster activé) ont une valeur supérieure ou égale à 1 dans la colonne **Shards**.
1. Choisissez **Rééquilibrer**.
1. À l'invite, choisissez **Rééquilibrer**. Il se peut que vous voyiez un message similaire à celui-ci :*Slots in the replication group are uniformly distributed. Nothing to do. (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidReplicationGroupState; Request ID: 2246cebd-9721-11e7-8d5b-e1b0f086c8cf)*. Sinon, choisissez **Annuler**.
#### Rééquilibrage des partitions en ligne (AWS CLI)
Utilisez les paramètres suivants avec `modify-replication-group-shard-configuration`.
**Parameters**
+ `-apply-immediately` – Obligatoire. Spécifie que l'opération de reconfiguration des partitions doit démarrer immédiatement.
+ `--replication-group-id` – Obligatoire. Spécifie sur quel groupe de réplication (cluster) l'opération de reconfiguration des partitions doit être exécutée.
+ `--node-group-count` – Obligatoire. Pour rééquilibrer l'espace de clés entre toutes les partitions du cluster, cette valeur doit être identique au nombre actuel de partitions.
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en rééquilibrant les partitions à l'aide du.AWS CLI
**Example – Rééquilibrage des partitions d'un cluster**
L'exemple suivant rééquilibre les emplacements du cluster Valkey ou Redis OSS (mode cluster activé) `my-cluster` afin qu'ils soient répartis de la manière la plus égale possible. La valeur de `--node-group-count` (`4`) est le nombre de partitions actuellement dans le cluster.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--apply-immediately
```
#### Rééquilibrage des partitions en ligne (API) ElastiCache
Vous pouvez utiliser l' ElastiCache API pour reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en ligne en utilisant l'opération. `ModifyReplicationGroupShardConfiguration`
Utilisez les paramètres suivants avec `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` – Obligatoire. Spécifie que l'opération de reconfiguration des partitions doit démarrer immédiatement.
+ `ReplicationGroupId` – Obligatoire. Spécifie sur quel groupe de réplication (cluster) l'opération de reconfiguration des partitions doit être exécutée.
+ `NodeGroupCount` – Obligatoire. Pour rééquilibrer l'espace de clés entre toutes les partitions du cluster, cette valeur doit être identique au nombre actuel de partitions.
Le processus suivant décrit comment reconfigurer les partitions de votre cluster Valkey ou Redis OSS (mode cluster activé) en rééquilibrant les partitions à l'aide de l'API. ElastiCache
**Example – Rééquilibrage d'un cluster**
L'exemple suivant rééquilibre les emplacements du cluster Valkey ou Redis OSS (mode cluster activé) `my-cluster` afin qu'ils soient répartis de la manière la plus égale possible. La valeur de `NodeGroupCount` (`4`) est le nombre de partitions actuellement dans le cluster.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
# Dimensionnement vertical en ligne en modifiant le type de nœud
En utilisant la mise à l'échelle verticale en ligne avec Valkey version 7.2 ou ultérieure, ou Redis OSS version 3.2.10 ou ultérieure, vous pouvez dimensionner vos clusters Valkey ou Redis OSS de manière dynamique avec un minimum de temps d'arrêt. Cela permet à votre cluster Valkey ou Redis OSS de répondre aux demandes même pendant le dimensionnement.
**Note**
La mise à l’échelle n’est pas prise en charge entre un cluster de hiérarchisation des données (par exemple, un cluster utilisant un type de nœud r6gd) et un cluster qui n’utilise pas la hiérarchisation des données (par exemple, un cluster utilisant un type de nœud r6g). Pour de plus amples informations, veuillez consulter [Hiérarchisation des données ElastiCache](data-tiering.md).
Vous pouvez effectuer les opérations suivantes :
+ **Élargissement** : augmentez la capacité de lecture et d'écriture en ajustant le type de nœud de votre cluster Valkey ou Redis OSS pour utiliser un type de nœud plus grand.
ElastiCache redimensionne dynamiquement votre cluster tout en restant en ligne et en répondant aux demandes.
+ **Réduire** : réduisez la capacité de lecture et d'écriture en ajustant le type de nœud pour votre cluster Redis afin d'utiliser un type de nœud plus petit. Encore une fois, redimensionne ElastiCache dynamiquement votre cluster tout en restant en ligne et en répondant aux demandes. Dans ce cas, vous réduisez vos coûts en diminuant la taille du nœud.
**Note**
Les processus d'augmentation et de réduction reposent sur la création de clusters avec des types de nœuds nouvellement sélectionnés et la synchronisation des nouveaux nœuds avec les anciens. Pour garantir un up/down flux d'échelle fluide, procédez comme suit :
Assurez-vous d'avoir une capacité ENI (interface réseau Elastic) suffisante. Pour une réduction, assurez-vous que la mémoire du plus petit nœud est suffisante pour absorber le trafic attendu.
Pour accéder aux bonnes pratiques en matière de gestion de la mémoire, veuillez consulter [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md).
Bien que le processus de dimensionnement vertical soit conçu pour rester entièrement en ligne, il repose sur la synchronisation des données entre l'ancien nœud et le nouveau. Nous vous recommandons d'initier l'augmentation/la réduction lorsqu'un trafic minimum des données est prévu.
Testez le comportement de votre application lors du repartitionnement dans un environnement intermédiaire, si possible.
**Contents**
+ [Augmentation en ligne](#redis-cluster-vertical-scaling-scaling-up)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-console)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Réduction en ligne](#redis-cluster-vertical-scaling-scaling-down)
+ [Réduction de la taille des clusters Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-down-console)
+ [Réduction de la taille des clusters Valkey ou Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Réduction de la taille des clusters Valkey ou Redis OSS (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
## Augmentation en ligne
**Topics**
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-console)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Mise à l'échelle des clusters Valkey ou Redis OSS (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
### Mise à l'échelle des clusters Valkey ou Redis OSS (console)
La procédure suivante décrit comment augmenter la taille d'un cluster Valkey ou Redis OSS à l'aide de la console de ElastiCache gestion. Au cours de ce processus, votre cluster continuera à traiter les demandes avec un temps d'arrêt minimal.
**Pour agrandir un cluster Valkey ou Redis OSS (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey clusters** ou **Redis OSS** clusters.
1. Choisissez le cluster dans la liste.
1. Sélectionnez **Modifier**.
1. Dans l'assistant **Modifier le cluster** :
1. Choisissez le type de nœud auquel vous souhaitez passer dans la liste **Type de nœud**. Pour l'augmenter, sélectionnez un type de nœud plus grand que votre nœud existant.
1. Si vous souhaitez effectuer un processus d'augmentation immédiatement, cochez la case **Apply immediately (Appliquer immédiatement)**. Si la case **Appliquer immédiatement** est décochée, le processus de mise à l'échelle est effectué lors du créneau de maintenance suivant du cluster.
1. Sélectionnez **Modifier**.
Si vous avez choisi **Apply immediately** lors de l'étape précédente, le statut du cluster passe à *modification*. Lorsque son statut passe à *available*, la modification est terminée et vous pouvez commencer à utiliser le nouveau cluster.
### Mise à l'échelle des clusters Valkey ou Redis OSS ()AWS CLI
La procédure suivante décrit comment augmenter la taille d'un cluster Valkey ou Redis OSS à l'aide du.AWS CLI Au cours de ce processus, votre cluster continuera à traiter les demandes avec un temps d'arrêt minimal.
**Pour agrandir un cluster Valkey ou Redis OSS ()AWS CLI**
1. Déterminez les types de nœuds que vous pouvez augmenter en exécutant la AWS CLI`list-allowed-node-type-modifications` commande avec le paramètre suivant.
Pour Linux, macOS ou Unix :
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Pour Windows :
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium",
"cache.t1.small "
],
}
```
Pour plus d'informations, consultez [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) dans la *référence AWS CLI*.
1. Modifiez votre groupe de réplication pour l'adapter au nouveau type de nœud plus grand à l'aide de la AWS CLI`modify-replication-group` commande et des paramètres suivants.
+ `--replication-group-id` : le nom du groupe de réplication que vous augmentez.
+ `--cache-node-type`— Le nouveau type de nœud pour lequel vous souhaitez redimensionner le cluster. Cette valeur doit correspondre à l'un des types de nœuds renvoyés par la commande `list-allowed-node-type-modifications` lors de l'étape 1.
+ `--cache-parameter-group-name` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `--apply-immediately` : ce paramètre entraîne l'application immédiate du processus d'augmentation. Pour reporter le processus de mise à l'échelle au créneau de maintenance suivant du cluster, utilisez le paramètre `--no-apply-immediately`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.m3.xlarge \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.m3.xlarge ^
--apply-immediately
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.m3.xlarge",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) dans la *référence AWS CLI*.
1. Si vous avez utilisé le`--apply-immediately`, vérifiez l'état du cluster à l'aide de la AWS CLI`describe-cache-clusters` commande avec le paramètre suivant. Lorsque le statut devient *disponible*, vous pouvez commencer à utiliser le nouveau nœud de cluster plus grand.
### Mise à l'échelle des clusters Valkey ou Redis OSS (API) ElastiCache
Le processus suivant fait passer votre cluster de son type de nœud actuel à un nouveau type de nœud plus grand à l'aide de l' ElastiCache API. Au cours de ce processus, ElastiCache met à jour les entrées DNS afin qu'elles pointent vers les nouveaux nœuds. Ainsi, vous n'aurez plus besoin de mettre à jour les points de terminaison de votre application. Pour Valkey 7.2 et versions ultérieures, Redis OSS 5.0.5 et versions ultérieures, vous pouvez dimensionner les clusters compatibles avec le basculement automatique pendant que le cluster continue de rester en ligne et de traiter les demandes entrantes. Sur les versions Redis OSS 4.0.10 et antérieures, vous remarquerez peut-être une brève interruption des lectures et des écritures sur les versions précédentes depuis le nœud principal pendant la mise à jour de l'entrée DNS.
Le temps nécessaire pour passer à un type de nœud plus important varie en fonction de votre type de nœud et de la quantité de données dans votre cluster actuel.
**Pour agrandir un cluster de cache (ElastiCache API) Valkey ou Redis OSS**
1. Déterminez les types de nœuds que vous pouvez augmenter à l'aide de l'`ListAllowedNodeTypeModifications`action d' ElastiCache API avec le paramètre suivant.
+ `ReplicationGroupId` : le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication spécifique plutôt que tous les groupes de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) le *Amazon ElastiCache API Reference*.
1. Adaptez votre groupe de réplication actuel au nouveau type de nœud à l'aide de l'action `ModifyReplicationGroup` ElastiCache API et avec les paramètres suivants.
+ `ReplicationGroupId` : le nom du groupe de réplication.
+ `CacheNodeType`— le nouveau type de nœud plus grand des clusters de ce groupe de réplication. Cette valeur doit être l'un des types d'instance renvoyés par l'`ListAllowedNodeTypeModifications`action de l'étape précédente.
+ `CacheParameterGroupName` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `ApplyImmediately` : lorsqu'il est défini sur `true`, il entraîne l'application immédiate du processus d'augmentation. Pour reporter le processus de mise à l'échelle au créneau de maintenance suivant, utilisez `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Pour plus d'informations, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) le *Amazon ElastiCache API Reference*.
1. Si vous l'avez utilisé `ApplyImmediately``=true`, surveillez l'état du groupe de réplication à l'aide de l'`DescribeReplicationGroups`action ElastiCache API avec les paramètres suivants. Lorsque le statut passe de *modifying* à *available*, cela signifie que vous pouvez commencer à écrire sur votre nouveau groupe de réplication redimensionné.
+ `ReplicationGroupId` – Le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication particulier plutôt que tous les groupes de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) le *Amazon ElastiCache API Reference*.
## Réduction en ligne
**Topics**
+ [Réduction de la taille des clusters Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-down-console)
+ [Réduction de la taille des clusters Valkey ou Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Réduction de la taille des clusters Valkey ou Redis OSS (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
### Réduction de la taille des clusters Valkey ou Redis OSS (console)
La procédure suivante décrit comment réduire la taille d'un cluster Valkey ou Redis OSS à l'aide de la console de ElastiCache gestion. Au cours de ce processus, votre cluster Valkey ou Redis OSS continuera à traiter les demandes avec un temps d'arrêt minimal.
**Pour réduire la taille d'un cluster Valkey ou Redis OSS (console)**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans le volet de navigation, choisissez **Valkey clusters** ou **Redis OSS** clusters.
1. Choisissez votre cluster préféré dans la liste.
1. Sélectionnez **Modifier**.
1. Dans l'assistant **Modifier le cluster** :
1. Choisissez le type de nœud auquel vous souhaitez passer dans la liste **Type de nœud**. Pour le réduire, sélectionnez un type de nœud plus petit que votre nœud existant. Notez que tous les types de nœuds ne sont pas disponibles pour la réduction de la capacité.
1. Si vous souhaitez effectuer un processus de réduction immédiatement, cochez la case **Apply immediately (Appliquer immédiatement)**. Si la case **Apply immediately (Appliquer immédiatement)** est décochée, le processus de réduction sera effectué lors de la prochaine fenêtre de maintenance du cluster.
1. Sélectionnez **Modifier**.
Si vous avez choisi **Apply immediately** lors de l'étape précédente, le statut du cluster passe à *modification*. Lorsque son statut passe à *available*, la modification est terminée et vous pouvez commencer à utiliser le nouveau cluster.
### Réduction de la taille des clusters Valkey ou Redis OSS ()AWS CLI
La procédure suivante décrit comment réduire la taille d'un cluster Valkey ou Redis OSS à l'aide du.AWS CLI Au cours de ce processus, votre cluster continuera à traiter les demandes avec un temps d'arrêt minimal.
**Pour réduire la taille d'un cluster Valkey ou Redis OSS ()AWS CLI**
1. Déterminez les types de nœuds que vous pouvez réduire en exécutant la AWS CLI`list-allowed-node-type-modifications` commande avec le paramètre suivant.
Pour Linux, macOS ou Unix :
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Pour Windows :
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small"
]
}
```
Pour plus d'informations, consultez [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) dans la *référence AWS CLI*.
1. Modifiez votre groupe de réplication pour le réduire au nouveau type de nœud plus petit, à l'aide de la AWS CLI`modify-replication-group` commande et des paramètres suivants.
+ `--replication-group-id` – Le nom du groupe de réplication que vous réduisez.
+ `--cache-node-type`— Le nouveau type de nœud pour lequel vous souhaitez redimensionner le cluster. Cette valeur doit correspondre à l'un des types de nœuds renvoyés par la commande `list-allowed-node-type-modifications` lors de l'étape 1.
+ `--cache-parameter-group-name` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `--apply-immediately` – Ce paramètre entraîne l'application immédiate du processus d'augmentation. Pour reporter le processus de réduction à la fenêtre de maintenance suivante du cluster, utilisez le paramètre `--no-apply-immediately`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.t2.micro \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.t2.micro ^
--apply-immediately
```
Le résultat de la commande ci-dessus doit être similaire à ce qui suit (format JSON).
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.t2.micro",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
```
Pour plus d'informations, consultez [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) dans la *référence AWS CLI*.
1. Si vous avez utilisé le`--apply-immediately`, vérifiez l'état du cluster à l'aide de la AWS CLI`describe-cache-clusters` commande avec le paramètre suivant. Lorsque le statut devient *disponible*, vous pouvez commencer à utiliser le nouveau nœud de cluster plus petit.
### Réduction de la taille des clusters Valkey ou Redis OSS (API) ElastiCache
Le processus suivant fait passer votre groupe de réplication de son type de nœud actuel à un nouveau type de nœud plus petit à l'aide de l' ElastiCache API. Au cours de ce processus, votre cluster Valkey ou Redis OSS continuera à traiter les demandes avec un temps d'arrêt minimal.
Le temps nécessaire pour passer à un type de nœud plus petit varie en fonction de votre type de nœud et de la quantité de données dans votre cluster actuel.
**Diminution (ElastiCache API)**
1. Déterminez les types de nœuds que vous pouvez réduire à l'aide de l'`ListAllowedNodeTypeModifications`action d' ElastiCache API avec le paramètre suivant.
+ `ReplicationGroupId` : le nom du groupe de réplication. Utilisez ce paramètre pour décrire un groupe de réplication spécifique plutôt que tous les groupes de réplication.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) le *Amazon ElastiCache API Reference*.
1. Réduisez votre groupe de réplication actuel au nouveau type de nœud à l'aide de l'action d'`ModifyReplicationGroup` ElastiCache API et avec les paramètres suivants.
+ `ReplicationGroupId` : le nom du groupe de réplication.
+ `CacheNodeType`— le nouveau type de nœud plus petit des clusters de ce groupe de réplication. Cette valeur doit être l'un des types d'instance renvoyés par l'`ListAllowedNodeTypeModifications`action de l'étape précédente.
+ `CacheParameterGroupName` : [Facultatif] Utilisez ce paramètre si vous avez recours à `reserved-memory` pour gérer la mémoire réservée de votre cluster. Spécifiez un groupe de paramètres de cache personnalisé qui réserve la quantité de mémoire nécessaire à votre nouveau type de nœud. Si vous utilisez `reserved-memory-percent`, vous pouvez omettre ce paramètre.
+ `ApplyImmediately` : lorsqu'il est défini sur `true`, il entraîne l'application immédiate du processus de réduction. Pour reporter le processus de réduction à la prochaine fenêtre de maintenance, utilisez `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.t2.micro
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Pour plus d'informations, consultez [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) le *Amazon ElastiCache API Reference*.
# Commencer à utiliser les filtres Bloom
ElastiCache prend en charge la structure de données du filtre Bloom, qui fournit une structure de données probabiliste peu encombrante pour vérifier si un élément fait partie d'un ensemble. Lorsque vous utilisez des filtres Bloom, des faux positifs sont possibles : un filtre peut indiquer de manière incorrecte l'existence d'un élément, même si cet élément n'a pas été ajouté à l'ensemble. Cependant, l'utilisation de filtres Bloom empêchera les faux *négatifs, c'est-à-dire des* indications incorrectes indiquant qu'un élément n'existe *pas*, même si cet élément a été ajouté à l'ensemble.
Vous pouvez définir le pourcentage de faux positifs potentiels à un taux adapté à votre charge de travail, en ajustant le taux fp. Vous pouvez également configurer la capacité (le nombre d'éléments qu'un filtre Bloom peut contenir), les propriétés dimensionnelles et non dimensionnelles, etc.
Une fois que vous avez créé un cluster avec une version de moteur prise en charge, le type de données Bloom et les commandes associées sont automatiquement disponibles. Le type de `bloom` données est compatible avec l'API avec la syntaxe de commande du filtre Bloom des bibliothèques clientes officielles de Valkey`valkey-py`, notamment`valkey-java`, et`valkey-go`. Vous pouvez facilement migrer les applications Valkey et Redis OSS existantes basées sur Bloom vers. ElastiCache Pour une liste complète des commandes, voir[Commandes du filtre Bloom](#SupportedCommandsBloom).
Les métriques liées à Bloom `BloomFilterBasedCmds``BloomFilterBasedCmdsLatency`, et `BloomFilterBasedCmdsECPUs` sont intégrées CloudWatch pour surveiller l'utilisation de ce type de données. Pour de plus amples informations, veuillez consulter [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md).
**Note**
Pour utiliser les filtres Bloom, vous devez utiliser ElastiCache Valkey 8.1 ou version ultérieure.
Le type de données Bloom n'est pas compatible avec RDB avec d'autres offres Bloom non basées sur Valkey.
## Vue d'ensemble des types de données des filtres Bloom
Les filtres Bloom sont une structure de données probabiliste peu encombrante qui permet d'ajouter des éléments et de vérifier si des éléments existent. Les faux positifs sont possibles lorsqu'un filtre indique de manière incorrecte l'existence d'un élément, même s'il n'a pas été ajouté. Cependant, les filtres Bloom garantissent l'absence de faux négatifs (indiquant à tort qu'un élément n'existe pas, même s'il a été ajouté).
La principale source de documentation pour les filtres Bloom se trouve sur la page de documentation de valkey.io. Il contient les informations suivantes :
+ [Cas d'utilisation courants des filtres Bloom](https://valkey.io/topics/bloomfilters/#common-use-cases-for-bloom-filters)
+ Publicité/Déduplication d'événements
+ Détection des fraudes
+ Filtrer les contenus dommageables et les spams
+ Détection unique des utilisateurs
+ [Différences entre les filtres de floraison scalables et non scalables](https://valkey.io/topics/bloomfilters/#scaling-and-non-scaling-bloom-filters)
+ Comment choisir entre des filtres de floraison redimensionnables et non scalables
+ [Propriétés de la floraison](https://valkey.io/topics/bloomfilters/#bloom-properties)
+ Découvrez les propriétés réglables des filtres Bloom. Cela inclut le taux de faux positifs, la capacité, les propriétés de mise à l'échelle et de non-mise à l'échelle, etc.
+ [Exécution des commandes Bloom](https://valkey.io/topics/bloomfilters/#performance)
+ [Surveillance des statistiques générales du filtre Bloom](https://valkey.io/topics/bloomfilters/#monitoring)
+ [Manipulation de grands filtres Bloom](https://valkey.io/topics/bloomfilters/#handling-large-bloom-filters)
+ Recommandations et informations sur la manière de vérifier si un filtre Bloom atteint sa limite d'utilisation de mémoire et s'il peut être redimensionné pour atteindre la capacité souhaitée.
+ Vous pouvez vérifier spécifiquement la quantité de mémoire consommée par un document de filtre Bloom à l'aide de la commande [BF.INFO](https://valkey.io/commands/bf.info/).
## Limite de taille des fleurs
La consommation de mémoire par un seul objet du filtre Bloom est limitée à 128 Mo. Vous pouvez vérifier la quantité de mémoire consommée par un filtre Bloom à l'aide de la `BF.INFO SIZE` commande.
## Bloom ACLs
À l'instar des catégories existantes par type de données (@string, @hash, etc.), une nouvelle catégorie @bloom est ajoutée pour simplifier la gestion de l'accès aux commandes et aux données Bloom. Aucune autre commande Valkey ou Redis OSS existante n'appartient à la catégorie @bloom.
Trois catégories d'ACL existantes ont été mises à jour pour inclure les nouvelles commandes Bloom : @read, @write et @fast. Le tableau suivant indique le mappage des commandes Bloom aux catégories appropriées.
| commande Bloom | @read | @write | @fast | @bloom |
| --- | --- | --- | --- | --- |
| BF.AJOUTER | | y | y | y |
| BF.CARD | y | | y | y |
| BF.EXISTE | y | | y | y |
| BF.INFO | y | | y | y |
| BF.INSERT | | y | y | y |
| BF.MADD | | y | y | y |
| BF.MEXIST | y | | y | y |
| BF.RESERVE | y | | y | y |
## Métriques liées au filtre Bloom
Les CloudWatch métriques suivantes relatives aux structures de données Bloom sont fournies :
| Métriques CW | Unit | Sans serveur/basé sur un nœud | Description |
| --- | --- | --- | --- |
| BloomFilterBasedCmds | Nombre | les deux | Le nombre total de commandes du filtre Bloom, y compris les commandes de lecture et d'écriture. |
| BloomFilterBasedCmdsLatency | Microsecondes | Autogéré | Latence de toutes les commandes du filtre Bloom, y compris les commandes de lecture et d'écriture. |
| BloomFilterBasedCmdsECPUs | Nombre | sans serveur | ECPUs consommé par toutes les commandes du filtre Bloom, y compris les commandes de lecture et d'écriture. |
## Commandes du filtre Bloom
Les [commandes du filtre Bloom](https://valkey.io/commands/#bloom) sont documentées sur le site Web de [Valkey.io](https://valkey.io/). Chaque page de commande fournit un aperçu complet des commandes bloom, notamment de leur syntaxe, de leur comportement, de leurs valeurs renvoyées et des conditions d'erreur potentielles.
| Nom | Description |
| --- | --- |
| [BF.AJOUTER](https://valkey.io/commands/bf.add/) | Ajoute un seul élément à un filtre Bloom. Si le filtre n'existe pas déjà, il est créé. |
| [CARTE BF](https://valkey.io/commands/bf.card/) | Renvoie la cardinalité d'un filtre Bloom. |
| [BF. EXISTE](https://valkey.io/commands/bf.exists/) | Détermine si le filtre Bloom contient l'élément spécifié. |
| [BF.INFO](https://valkey.io/commands/bf.info/) | Renvoie les informations d'utilisation et les propriétés d'un filtre Bloom spécifique. |
| [B.F. INSÉRER](https://valkey.io/commands/bf.insert/) | Crée un filtre de floraison avec 0 éléments ou plus, ou ajoute des éléments à un filtre de floraison existant. |
| [B.F. MADD](https://valkey.io/commands/bf.madd/) | Ajoute un ou plusieurs éléments à un filtre Bloom. |
| [B.F. EXISTE](https://valkey.io/commands/bf.mexists/) | Détermine si le filtre Bloom contient un ou plusieurs éléments. |
| [B.RESERVE](https://valkey.io/commands/bf.reserve/) | Crée un filtre de floraison vide avec les propriétés spécifiées. |
**Note**
**BF.LOAD** n'est pas pris en charge par. ElastiCache Cela ne concerne que l'utilisation de l'AOF, qui n'est ElastiCache pas prise en charge.
# Commencer à utiliser Watch in Serverless
ElastiCache prend en charge la `WATCH` commande, qui vous permet de surveiller les modifications apportées aux touches et d'exécuter [des transactions](https://valkey.io/topics/transactions/) conditionnelles. La `WATCH` commande est particulièrement utile pour les applications qui nécessitent un contrôle de simultanéité optimiste, garantissant que les transactions ne sont exécutées que si les clés surveillées n'ont pas été modifiées. Cela inclut les modifications apportées par un client, comme les commandes d'écriture, et par Valkey lui-même, comme l'expiration ou l'expulsion. Si les clés ont été modifiées à partir du moment où elles ont été définies `WATCH` et au moment `EXEC` de leur réception, la transaction sera annulée dans son intégralité.
Pour le ElastiCache mode Serverless, les contraintes suivantes sont introduites :
ElastiCache Le mode Serverless `WATCH` est limité à un seul emplacement de hachage. Cela signifie que seules les clés qui correspondent au même emplacement de hachage peuvent être surveillées en même temps par la même connexion, et que la transaction qui suit les commandes de surveillance ne peut fonctionner que sur le même emplacement de hachage. Lorsqu'une application tente de surveiller des clés provenant de différents emplacements de hachage ou d'exécuter des commandes de transaction qui agissent sur des clés mappées à un emplacement de hachage différent de celui des clés surveillées, une `CROSSSLOT` erreur est renvoyée. Les [balises de hachage](https://valkey.io/topics/cluster-spec/#hash-tags) peuvent être utilisées pour garantir que plusieurs clés sont mappées sur le même emplacement de hachage.
De plus, `SCAN` la commande ne peut pas être exécutée dans une connexion avec des touches surveillées et renverra `command not supported during watch state` une erreur.
La transaction sera abandonnée (comme si des touches surveillées avaient été touchées) lorsque ElastiCache Serverless n'a aucune certitude quant à savoir si une clé a été modifiée. Par exemple, lorsqu'un emplacement a été migré et que les clés surveillées sont introuvables sur le même nœud.
**Exemples de code**
## Regardez et manipulez des clés provenant de différents emplacements
Dans l'exemple suivant, la clé surveillée et la clé spécifiée dans la `SET` commande correspondent à différents emplacements de hachage. L'exécution renvoie un`CROSSSLOT ERROR`.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{011794} 1234
QUEUED
> EXEC
CROSSSLOT Keys in request don't hash to the same slot
```
## Regardez et manipulez les clés depuis le même emplacement
L'exemple suivant montre une transaction réussie, car la clé définie `WATCH` n'a pas été modifiée.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{005119} 1234
QUEUED
> EXEC
1) OK
```
## Regardez les clés de différentes machines à sous
Dans l'exemple suivant, une tentative de saisie simultanée de `WATCH` clés provenant de différents emplacements au sein de la même connexion client renvoie un`CROSSSLOT ERROR`.
```
> WATCH foo:{005119}
OK
> WATCH bar:{123455}
CROSSSLOT Keys in request don't hash to the same slot
```
## Limite de surveillance
Chaque connexion client peut regarder jusqu'à 1 000 clés en même temps.
## Commandes prises en charge liées à Watch
Les commandes [WATCH](https://valkey.io/commands/watch/) et [UNWATCH](https://valkey.io/commands/unwatch/) sont documentées sur le site Web de [Valkey.io](https://valkey.io/). Il fournit une vue d'ensemble complète des commandes, notamment de leur syntaxe, de leur comportement, de leurs valeurs renvoyées et des conditions d'erreur potentielles.
# Commencer à utiliser la recherche vectorielle
Amazon ElastiCache for Valkey prend en charge la recherche vectorielle, ce qui vous permet de stocker, de rechercher et de mettre à jour des milliards d'intégrations vectorielles de grande dimension en mémoire avec des latences aussi faibles que quelques microsecondes et un taux de rappel supérieur à 99 %. ElastiCache for Valkey fournit des fonctionnalités permettant d'indexer, de rechercher et de mettre à jour des milliards d'intégrations vectorielles de grande dimension provenant de fournisseurs populaires tels qu'Amazon Bedrock, Amazon, SageMaker Anthropic ou OpenAI pour une recherche et une récupération rapides. La recherche vectorielle pour Amazon ElastiCache est idéale pour les cas d'utilisation où les performances optimales et l'évolutivité sont les critères de sélection les plus importants. Cela inclut la mise en cache sémantique, la génération augmentée par extraction, les recommandations en temps réel, la personnalisation et la détection des anomalies.
La recherche vectorielle peut être utilisée conjointement avec d'autres ElastiCache fonctionnalités pour améliorer vos applications. La recherche vectorielle pour ElastiCache est disponible dans la version 8.2 de Valkey sur les clusters basés sur des nœuds dans toutes les [AWS régions](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) sans frais supplémentaires. Pour commencer, créez un nouveau cluster Valkey 8.2 à l'aide du [AWS Management Console](https://console.aws.amazon.com/elasticache/)AWS SDK ou.AWS CLI Vous pouvez également utiliser la recherche vectorielle sur votre cluster existant en passant de n'importe quelle version précédente de Valkey ou Redis OSS à Valkey 8.2 en [quelques clics sans interruption de](VersionManagement.HowTo.md) service.
# Présentation de la recherche vectorielle
ElastiCache for Valkey fournit des fonctionnalités permettant d'indexer, de rechercher et de mettre à jour des milliards d'intégrations vectorielles de grande dimension. La recherche vectorielle vous permet de créer, de gérer et d'utiliser des index secondaires pour une recherche efficace et évolutive. Chaque opération de recherche vectorielle s'applique à un seul index. Les opérations d'indexation s'appliquent uniquement à l'index spécifié. Un certain nombre d'opérations peuvent être effectuées sur n'importe quel index à tout moment, à l'exception des opérations de création et de suppression d'index. Au niveau du cluster, plusieurs opérations portant sur plusieurs index peuvent être en cours simultanément.
Dans ce document, les termes clé, ligne et enregistrement sont identiques et utilisés de manière interchangeable. De même, les termes colonne, champ, chemin et membre sont également utilisés de manière interchangeable.
La `FT.CREATE` commande peut être utilisée pour créer un index pour un sous-ensemble de clés avec les types d'index spécifiés. `FT.SEARCH`exécute des requêtes sur les index créés et `FT.DROPINDEX` supprime un index existant ainsi que toutes les données associées. Il n'existe aucune commande spéciale pour ajouter, supprimer ou modifier des données indexées. Les `JSON` commandes existantes `HASH` ou qui modifient une clé figurant dans un index mettent automatiquement à jour l'index.
**Topics**
+ [Les index et le keyspace Valkey OSS](#indexes-keyspace)
+ [Types de champs d'index](#index-field-types)
+ [Algorithmes d'index vectoriel](#vector-index-algorithms)
+ [Sécurité de la recherche vectorielle](#vector-search-security)
## Les index et le keyspace Valkey OSS
Les index sont construits et gérés sur un sous-ensemble de l'espace de touches Valkey OSS. L'espace-clé de chaque index est défini par une liste de préfixes clés fournis lors de la création de l'index. La liste des préfixes est facultative et si elle est omise, l'espace clé entier fera partie de cet index. Plusieurs index peuvent choisir des sous-ensembles disjoints ou superposés de l'espace-clé sans limitation.
Les index sont également saisis dans la mesure où ils ne couvrent que les clés dont le type correspond. Actuellement, les index ne sont pris en charge que sur les `HASH` types `JSON` et. Un `HASH` index indexe uniquement les `HASH` clés couvertes par sa liste de préfixes. De même, un `JSON` index indexe uniquement les `JSON` clés couvertes par sa liste de préfixes. Les clés de la liste de préfixes d'espaces de touches d'un index qui n'ont pas le type désigné sont ignorées et n'affectent pas les opérations de recherche.
Un index est mis à jour lorsqu'une commande modifie une touche située dans l'espace-clé de l'index. Valkey extrait automatiquement les champs déclarés pour chaque index et met à jour l'index avec la nouvelle valeur. Le processus de mise à jour comporte trois étapes. Dans un premier temps, la clé HASH ou JSON est modifiée et le client demandeur est bloqué. La deuxième étape est exécutée en arrière-plan et met à jour chacun des index contenant la clé modifiée. Dans la troisième étape, le client est débloqué. Ainsi, pour les opérations de requête effectuées sur la même connexion qu'une mutation, cette modification est immédiatement visible dans les résultats de recherche.
La création d'un index est un processus en plusieurs étapes. La première étape consiste à exécuter la commande FT.CREATE qui définit l'index. L'exécution réussie d'une création initie automatiquement la deuxième étape : le remblayage. Le processus de remplissage s'exécute dans un fil d'arrière-plan et analyse l'espace des touches à la recherche de clés figurant dans la liste de préfixes du nouvel index. Chaque clé trouvée est ajoutée à l'index. Finalement, l'espace clé entier est scanné, complétant ainsi le processus de création de l'index. Notez que lorsque le processus de remplissage des index est en cours d'exécution, les mutations des clés indexées sont autorisées, il n'y a aucune restriction et le processus de remplissage de l'index ne sera pas terminé tant que toutes les clés ne seront pas correctement indexées. Les opérations de requête tentées alors qu'un index est en cours de remblayage ne sont pas autorisées et se terminent par une erreur. La commande FT.INFO renvoie l'état du processus de remblayage dans le champ « backfill\$1status ».
## Types de champs d'index
Chaque index possède un type spécifique déclaré lors de la création de l'index, ainsi que l'emplacement d'un champ (colonne) à indexer. Pour `HASH` les clés, l'emplacement est le nom du champ dans le`HASH`. Pour `JSON` les clés, l'emplacement est une description du chemin JSON. Lorsqu'une clé est modifiée, les données associées aux champs déclarés sont extraites, converties dans le type déclaré et stockées dans l'index. Si les données sont manquantes ou ne peuvent pas être converties correctement dans le type déclaré, ce champ est omis de l'index. Il existe trois types de champs, comme expliqué ci-dessous :
+ Les **champs vectoriels** contiennent un vecteur de nombres, également connu sous le nom d'intégration vectorielle. Les champs vectoriels peuvent être utilisés pour filtrer les vecteurs en fonction de mesures de distance spécifiées qui mesurent la similitude. Pour les `HASH` index, le champ doit contenir le vecteur entier codé au format binaire (little-endian IEEE 754). Pour `JSON` les clés, le chemin doit faire référence à un tableau de la bonne taille rempli de chiffres. Notez que lorsqu'un tableau JSON est utilisé comme champ vectoriel, la représentation interne du tableau dans la clé JSON est convertie dans le format requis par l'algorithme sélectionné, ce qui réduit la consommation de mémoire et la précision. Les opérations de lecture ultérieures à l'aide des commandes JSON produiront la valeur de précision réduite.
+ Les **champs numériques** contiennent un seul chiffre. Les champs numériques peuvent être utilisés avec l'opérateur de recherche par plage. En `HASH` effet, le champ est censé contenir le texte ASCII d'un nombre écrit dans le format standard des nombres à virgule fixe ou flottante. Pour `JSON` les champs, les règles numériques des numéros JSON doivent être respectées. Quelle que soit la représentation dans la clé, ce champ est converti en un nombre à virgule flottante de 64 bits pour être stocké dans l'index. Les nombres sous-jacents étant stockés en virgule flottante avec ses limites de précision, les règles habituelles relatives aux comparaisons numériques pour les nombres à virgule flottante s'appliquent.
+ Les **champs de balises** contiennent zéro ou plusieurs valeurs de balise codées sous la forme d'une seule chaîne UTF-8. Les champs de balises peuvent être utilisés pour filtrer les requêtes relatives à l'équivalence des valeurs de balises par une comparaison entre majuscules et minuscules. La chaîne est analysée en valeurs de balise à l'aide d'un caractère séparateur (la valeur par défaut est une virgule mais peut être remplacée), les espaces blancs de début et de fin étant supprimés. Un seul champ de balise peut contenir autant de valeurs de balise que vous le souhaitez.
## Algorithmes d'index vectoriel
Deux algorithmes d'index vectoriel sont pris en charge dans Valkey :
+ **Plat** — L'algorithme Flat est un traitement linéaire par force brute de chaque vecteur de l'indice, fournissant des réponses exactes dans les limites de précision des calculs de distance. En raison du traitement linéaire de l'indice, les temps d'exécution de cet algorithme peuvent être très élevés pour les grands indices. Les index plats favorisent des vitesses d'ingestion plus élevées.
+ **Petits mondes navigables hiérarchiques (HNSW)** — L'algorithme HNSW est une alternative qui fournit les correspondances vectorielles les plus proches approximatives en échange de temps d'exécution nettement plus courts. L'algorithme est contrôlé par trois paramètres`M`, `EF_CONSTRUCTION` et`EF_RUNTIME`. Les deux premiers paramètres sont spécifiés au moment de la création de l'index et ne peuvent pas être modifiés. Le `EF_RUNTIME` paramètre possède une valeur par défaut qui est spécifiée lors de la création de l'index, mais qui peut ensuite être remplacée lors de n'importe quelle opération de requête individuelle. Ces trois paramètres interagissent pour équilibrer la consommation de mémoire et de processeur lors des opérations d'ingestion et de requête, ainsi que pour contrôler la qualité de l'approximation d'une recherche KNN exacte (connue sous le nom de ratio de rappel).
Dans HNSW, le paramètre M contrôle le nombre maximum de voisins auxquels chaque nœud peut se connecter, façonnant ainsi la densité de l'indice. Un M plus élevé, tel que 32 ou plus, produit un graphe plus connecté, ce qui améliore la vitesse de rappel et de requête, car il existe davantage de chemins pour atteindre les voisins pertinents. Cependant, cela augmente la taille de l'index, l'utilisation de la mémoire et ralentit l'indexation. Un M inférieur, tel que 8 ou moins, produit un faster-to-build index plus petit avec une utilisation de mémoire plus faible, mais les rappels diminuent et les requêtes peuvent prendre plus de temps en raison du nombre réduit de connexions.
Le paramètre EF\$1Construction indique le nombre de connexions candidates à évaluer lors de la création de l'index. Un EF\$1Construction plus élevé, tel que 400 ou plus, signifie que l'indexeur prend en compte davantage de chemins avant de sélectionner des voisins, ce qui permet d'obtenir un graphique qui améliore à la fois le rappel et l'efficacité des requêtes par la suite, mais au prix d'une indexation plus lente et d'une utilisation accrue du processeur et de la mémoire pendant la construction. Un EF\$1Construction faible, tel que 64-120, accélère l'indexation et réduit l'utilisation des ressources, mais le graphe qui en résulte peut réduire les rappels et ralentir les requêtes même si EF\$1Runtime est défini sur un niveau élevé.
Enfin, EF\$1Runtime régit l'étendue de la recherche lors de l'interrogation, en contrôlant le nombre de voisins candidats explorés lors de l'exécution. Une valeur élevée augmente le rappel et la précision, mais au détriment de la latence des requêtes et de l'utilisation du processeur. Un EF\$1Runtime faible rend les requêtes plus rapides et plus légères, mais avec un rappel réduit. Contrairement à M ou EF\$1Construction, ce paramètre n'affecte pas la taille de l'index ni le temps de création, ce qui en fait le paramètre permettant d'ajuster les compromis entre rappel et latence après la création d'un index.
Les deux algorithmes de recherche vectorielle (Flat et HNSW) prennent en charge un `INITIAL_CAP` paramètre facultatif. Lorsqu'il est spécifié, ce paramètre préalloue de la mémoire aux index, ce qui permet de réduire la charge de gestion de la mémoire et d'augmenter les taux d'ingestion de vecteurs. Les indices plats permettent de meilleures vitesses d'ingestion que le HNSW.
Les algorithmes de recherche vectorielle tels que HNSW peuvent ne pas gérer efficacement la suppression ou le remplacement de vecteurs précédemment insérés. L'utilisation de ces opérations peut entraîner une consommation excessive de mémoire d'index et une and/or dégradation de la qualité du rappel. La réindexation est une méthode permettant de rétablir un rappel optimal de l'utilisation and/or de la mémoire.
## Sécurité de la recherche vectorielle
Les mécanismes de sécurité [Valkey ACL (Access Control Lists)](https://valkey.io/topics/acl/) pour l'accès aux commandes et aux données sont étendus pour contrôler la fonction de recherche. Le contrôle ACL des commandes de recherche individuelles est entièrement pris en charge. Une nouvelle catégorie ACL`@search`,, est fournie et de nombreuses catégories existantes (`@fast`,, `@read``@write`, etc.) sont mises à jour pour inclure les nouvelles commandes. Les commandes de recherche ne modifient pas les données clés, ce qui signifie que le mécanisme ACL existant pour l'accès en écriture est préservé. Les règles d'accès `HASH` et les `JSON` opérations ne sont pas modifiées par la présence d'un index ; le contrôle d'accès normal au niveau des clés est toujours appliqué à ces commandes.
L'accès aux commandes de recherche avec index est également contrôlé via ACL. Les contrôles d'accès sont effectués au niveau de l'index complet, et non au niveau de chaque clé. Cela signifie que l'accès à un index n'est accordé à un utilisateur que s'il est autorisé à accéder à toutes les clés possibles dans la liste des préfixes d'espace-touches de cet index. En d'autres termes, le contenu réel d'un index ne contrôle pas l'accès. C'est plutôt le contenu théorique d'un index tel que défini par la liste de préfixes qui est utilisé pour le contrôle de sécurité. Il est possible qu'un utilisateur dispose d'un accès en lecture et en and/or écriture à une clé mais ne puisse pas accéder à un index contenant cette clé. Notez que seul un accès en lecture à l'espace de touches est requis pour créer ou utiliser un index ; la présence ou l'absence d'accès en écriture n'est pas prise en compte.
# Caractéristiques et limites de la recherche vectorielle
## Disponibilité de la recherche vectorielle
La recherche vectorielle pour Amazon ElastiCache est disponible avec la version 8.2 de Valkey sur les clusters basés sur des nœuds dans toutes les AWS régions, sans frais supplémentaires. Vous pouvez également utiliser la recherche vectorielle sur vos clusters existants en passant de n'importe quelle version de Valkey, ou de Redis OSS, à Valkey 8.2, en [quelques clics, sans interruption de](VersionManagement.HowTo.md) service.
La recherche vectorielle est actuellement disponible sur tous les types d' ElastiCache instances autres que les nœuds avec hiérarchisation des données. L'utilisation de la recherche vectorielle sur les instances t2, t3 et t4g nécessite d'augmenter la réserve de mémoire à au moins 50 % pour les microinstances et à 30 % pour les petites instances. Consultez [cette page](redis-memory-management.md) pour en savoir plus.
## Restrictions paramétriques
Le tableau suivant indique les limites applicables aux différents éléments de recherche vectorielle :
**Limites de recherche vectorielle**
| Élément | Valeur maximale |
| --- | --- |
| Nombre de dimensions dans un vecteur | 32768 |
| Nombre d'index pouvant être créés | 10 |
| Nombre de champs dans un index | 50 |
| Clause FT.SEARCH TIMEOUT (millisecondes) | 60000 |
| Nombre maximum de préfixes autorisés par index | 16 |
| Longueur maximale d'un champ de tag | 10 000 |
| Longueur maximale d'un champ numérique | 256 |
| Paramètre HNSW M | 2000000 |
| Paramètre HNSW EF\$1CONSTRUCTION | 4096 |
| Paramètre HNSW EF\$1RUNTIME | 4096 |
## Restrictions opérationnelles
### Persistance de l'indice et remblayage
Le processus de mise à jour comporte trois étapes. Dans un premier temps, la clé HASH ou JSON est modifiée et le client demandeur est bloqué. La deuxième étape est exécutée en arrière-plan et met à jour chacun des index contenant la clé modifiée. Dans la troisième étape, le client est débloqué. Ainsi, pour les opérations de requête effectuées sur la même connexion qu'une mutation, cette modification est immédiatement visible dans les résultats de recherche. Cependant, il est possible que l'insertion ou la mise à jour d'une clé ne soit pas visible dans les résultats de recherche d'autres clients pendant une courte période. Pendant les périodes de forte charge du système et de and/or forte mutation des données, le délai de visibilité peut s'allonger.
La fonction de recherche vectorielle conserve la définition des index et le contenu des index. Les index des champs vectoriels sont enregistrés mais ceux des champs TAGS et NUMERIC ne le sont pas, ce qui signifie qu'ils doivent être reconstruits lorsqu'ils sont chargés en externe (synchronisation complète ou rechargement). Cela signifie que lors de toute demande ou événement opérationnel entraînant le démarrage ou le redémarrage d'un nœud, la définition de l'index et le contenu des vecteurs sont restaurés à partir du dernier instantané. Aucune action de l'utilisateur n'est requise pour lancer cette opération. Toutefois, pour les index TAGS et NUMERIC, la reconstruction est effectuée en tant qu'opération de remblayage dès que les données sont restaurées. Cela équivaut fonctionnellement à l'exécution automatique par le système d'une commande FT.CREATE pour chaque index défini. Notez que le nœud devient disponible pour les opérations d'application dès que les données sont restaurées, mais probablement avant la fin du remplissage de l'index, ce qui signifie que les opérations de remplissage redeviendront visibles pour les applications.
L'achèvement du remplissage de l'index n'est pas synchronisé entre un index principal et un réplica. Ce manque de synchronisation peut devenir visible de manière inattendue pour les applications. Il est donc recommandé aux applications de vérifier que le remblayage est terminé sur les primaires et sur toutes les répliques avant de lancer des opérations de recherche.
### Limites d'échelle
Lors des événements de dimensionnement, l'index peut être remplacé au fur et à mesure que les données sont migrées. Cela réduira le nombre de rappels pour les requêtes de recherche.
### Instantané import/export et migration en direct
Les fichiers RDB d'un cluster avec des index de recherche peuvent être importés vers un autre cluster ElastiCache Valkey avec la version 8.2 ou supérieure. Le nouveau cluster reconstruira le contenu de l'index lors du chargement du fichier RDB. Cependant, la présence d'index de recherche dans un fichier RDB limite la compatibilité de ces données avec les versions antérieures de Valkey. Le format des index de recherche défini par la fonctionnalité de recherche vectorielle n'est compris que par un autre ElastiCache cluster doté de la version 8.2 ou supérieure de Valkey. Toutefois, les fichiers RDB qui ne contiennent pas d'index ne sont pas restreints de cette manière.
### Mémoire insuffisante pendant le remblayage
À l'instar des opérations d'écriture de Valkey OSS, le remplissage d'index est soumis à out-of-memory des limitations. Si la mémoire du moteur est pleine alors qu'un remblayage est en cours, tous les remplissages sont interrompus. Si de la mémoire devient disponible, le processus de remblayage est repris. Il est possible de supprimer un index lorsque le remplissage est suspendu en raison d'un manque de mémoire.
### Transactions
Les commandes`FT.CREATE`,`FT.DROPINDEX`, `FT.ALIASADD``FT.ALIASDEL`, et `FT.ALIASUPDATE` ne peuvent pas être exécutées dans un contexte transactionnel, c'est-à-dire pas dans un `MULTI/EXEC` bloc ou dans un script LUA ou FUNCTION.
# Choix de la configuration appropriée
Dans le cadre de l'expérience console ElastiCache , vous pouvez facilement choisir le type d'instance approprié en fonction des exigences en matière de mémoire et de processeur de votre charge de travail vectorielle.
## Consommation de mémoire
La consommation de mémoire est basée sur le nombre de vecteurs, le nombre de dimensions, la valeur M et la quantité de données non vectorielles, telles que les métadonnées associées au vecteur ou d'autres données stockées dans l'instance. La mémoire totale requise est une combinaison de l'espace nécessaire pour les données vectorielles réelles et de l'espace requis pour les indices vectoriels. L'espace requis pour les données vectorielles est calculé en mesurant la capacité réelle requise pour stocker des vecteurs au sein `HASH` de structures de `JSON` données et le surdébit par rapport aux dalles de mémoire les plus proches, pour des allocations de mémoire optimales. Chacun des index vectoriels utilise des références aux données vectorielles stockées dans ces structures de données ainsi qu'une copie supplémentaire du vecteur dans l'index. Il est conseillé de prévoir cette consommation d'espace supplémentaire par l'indice.
Le nombre de vecteurs dépend de la façon dont vous décidez de représenter vos données sous forme de vecteurs. Par exemple, vous pouvez choisir de représenter un seul document en plusieurs parties, chaque partie représentant un vecteur. Vous pouvez également choisir de représenter l'ensemble du document sous la forme d'un vecteur unique. Le nombre de dimensions de vos vecteurs dépend du modèle d'intégration que vous choisissez. Par exemple, si vous choisissez d'utiliser le modèle d'intégration AWS Titan, le nombre de dimensions sera de 1536. Notez que vous devez tester le type d'instance pour vous assurer qu'il répond à vos besoins.
## Élargir votre charge de travail
La recherche vectorielle prend en charge les trois méthodes de mise à l'échelle : horizontale, verticale et répliques. Lors de la mise à l'échelle de la capacité, la recherche vectorielle se comporte comme un Valkey classique, c'est-à-dire que l'augmentation de la mémoire des nœuds individuels (mise à l'échelle verticale) ou l'augmentation du nombre de nœuds (mise à l'échelle horizontale) augmentera la capacité globale. En mode cluster, la `FT.CREATE` commande peut être envoyée à n'importe quel nœud principal du cluster et le système distribuera automatiquement la nouvelle définition d'index à tous les membres du cluster.
Cependant, du point de vue des performances, la recherche vectorielle se comporte très différemment de Valkey classique. La mise en œuvre multithread de la recherche vectorielle signifie un CPUs rendement supplémentaire pouvant aller jusqu'à une augmentation linéaire du débit de requête et d'ingestion. La mise à l'échelle horizontale entraîne des augmentations linéaires du débit d'ingestion, mais peut réduire le débit des requêtes. Si un débit de requêtes supplémentaire est requis, un dimensionnement par le biais de répliques ou d'un débit supplémentaire CPUs est requis.
# Commandes de recherche vectorielle
Vous trouverez ci-dessous une liste des commandes prises en charge pour la recherche vectorielle.
**Topics**
+ [FT.CREATE](vector-search-commands-ft.create.md)
+ [FT.SEARCH](vector-search-commands-ft.search.md)
+ [FT.DROPINDEX](vector-search-commands-ft.dropindex.md)
+ [FT.INFO](vector-search-commands-ft.info.md)
+ [PIEDS. \$1LISTE](vector-search-commands-ft.list.md)
# FT.CREATE
La `FT.CREATE` commande crée un index vide et lance le processus de remblayage. Chaque index comprend un certain nombre de définitions de champs. Chaque définition de champ spécifie un nom de champ, un type de champ et un chemin dans chaque clé indexée pour localiser une valeur du type déclaré. Certaines définitions de type de champ comportent des spécificateurs de sous-types supplémentaires.
Pour les index sur les clés HASH, le chemin est le même que le nom du membre de hachage. La `AS` clause facultative peut être utilisée pour renommer le champ si vous le souhaitez. Il est particulièrement utile de renommer les champs lorsque le nom du membre contient des caractères spéciaux.
Pour les index sur des clés JSON, le chemin est un chemin JSON vers les données du type déclaré. Comme le chemin JSON contient toujours des caractères spéciaux, la `AS` clause est obligatoire.
**Syntaxe**
```
FT.CREATE
ON HASH | JSON
[PREFIX [...]]
SCHEMA
( [AS ]
| VECTOR [HNSW|FLAT] [])
| TAG [SEPARATOR ] [CASESENSITIVE]
| NUMERIC
)+
```
**(obligatoire) :** C'est le nom que vous donnez à votre index. Si un index portant le même nom existe déjà, une erreur est renvoyée.
**ON HASH \$1 JSON (facultatif) :** seules les clés correspondant au type spécifié sont incluses dans cet index. En cas d'omission, HASH est supposé.
**PRÉFIXE (facultatif) :** si cette clause est spécifiée, seules les clés commençant par les mêmes octets qu'un ou plusieurs des préfixes spécifiés seront incluses dans cet index. Si cette clause est omise, toutes les clés du type correct seront incluses. Un préfixe de longueur nulle correspondrait également à toutes les clés du type correct.
**Types de champs :**
+ TAG : un champ de balise est une chaîne contenant une ou plusieurs valeurs de balise.
+ SÉPARATEUR (facultatif) : l'un des caractères `,.<>{}[]"':;!@#$%^&*()-+=~` utilisés pour délimiter les balises individuelles. En cas d'omission, la valeur par défaut est`,`.
+ CASESENSITIVE (facultatif) : le cas échéant, les comparaisons de balises feront la distinction majuscules/majuscules. Par défaut, les comparaisons de balises NE font PAS la distinction majuscules et minuscules.
+ NUMÉRIQUE : Un champ numérique contient un nombre.
+ VECTEUR : Un champ vectoriel contient un vecteur. Deux algorithmes d'indexation vectorielle sont actuellement pris en charge : HNSW (Hierarchical Navigable Small World) et FLAT (force brute). Chaque algorithme possède un ensemble d'attributs supplémentaires, certains obligatoires et d'autres facultatifs.
+ FLAT : L'algorithme Flat fournit des réponses exactes, mais son temps d'exécution est proportionnel au nombre de vecteurs indexés et peut donc ne pas être approprié pour les grands ensembles de données.
+ DIM (obligatoire) : Spécifie le nombre de dimensions d'un vecteur.
+ TYPE FLOAT32 (obligatoire) : type de données, actuellement seul FLOAT32 est pris en charge.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (obligatoire) : Spécifie l'algorithme de distance.
+ INITIAL\$1CAP (facultatif) : taille initiale de l'index.
+ HNSW : L'algorithme HNSW fournit des réponses approximatives, mais fonctionne nettement plus rapidement que FLAT.
+ DIM (obligatoire) : Spécifie le nombre de dimensions d'un vecteur.
+ TYPE FLOAT32 (obligatoire) : type de données, actuellement seul FLOAT32 est pris en charge.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (obligatoire) : Spécifie l'algorithme de distance.
+ INITIAL\$1CAP (facultatif) : taille initiale de l'index.
+ M (facultatif) : nombre maximum d'arêtes sortantes autorisées pour chaque nœud du graphe dans chaque couche. Sur la couche zéro, le nombre maximal d'arêtes sortantes sera de 2\$1M. La valeur par défaut est 16, le maximum est 512.
+ EF\$1CONSTRUCTION (facultatif) : contrôle le nombre de vecteurs examinés lors de la construction de l'index. Des valeurs plus élevées pour ce paramètre amélioreront le taux de rappel au détriment de délais de création d'index plus longs. La valeur par défaut est 200. La valeur maximale est 4096.
+ EF\$1RUNTIME (facultatif) : contrôle le nombre de vecteurs à examiner lors d'une opération de requête. La valeur par défaut est 10 et le maximum est 4096. Vous pouvez définir cette valeur de paramètre pour chaque requête que vous exécutez. Des valeurs plus élevées augmentent la durée des requêtes, mais améliorent le rappel des requêtes.
**RÉPONSE :** OK ou erreur.
# FT.SEARCH
Effectue une recherche dans l'index spécifié. Les clés correspondant à l'expression de requête sont renvoyées.
```
FT.SEARCH
[NOCONTENT]
[RETURN ( [AS ])+]
[TIMEOUT timeout]
[PARAMS []]
[LIMIT ]
```
+ (obligatoire) : Le nom de l'index que vous souhaitez interroger.
+ (obligatoire) : La chaîne de requête, voir ci-dessous pour plus de détails.
+ NOCONTENT (facultatif) : lorsqu'ils sont présents, seuls les noms de clé obtenus sont renvoyés, aucune valeur de clé n'est incluse.
+ TIMEOUT (facultatif) : permet de définir une valeur de délai d'attente pour la commande de recherche. Il doit s'agir d'un entier en millisecondes.
+ PARAMÈTRES... (facultatif) : `count` représente le nombre d'arguments, c'est-à-dire le double du nombre de paires de noms de valeurs. Consultez la chaîne de requête pour plus de détails sur l'utilisation.
+ RETOUR ... (facultatif) : count est le nombre de champs à renvoyer. Spécifie les champs que vous souhaitez récupérer dans vos documents, ainsi que les alias des valeurs renvoyées. Par défaut, tous les champs sont renvoyés sauf si l'option NOCONTENT est définie, auquel cas aucun champ n'est renvoyé. Si le nombre est défini sur 0, il se comporte de la même manière que NOCONTENT.
+ LIMITE : Vous permet de choisir une partie du résultat. Les premières touches sont ignorées et seul un maximum de clés est inclus. La valeur par défaut est LIMIT 0 10, qui renvoie au maximum 10 clés.
+ PARAMS : deux fois le nombre de paires clé-valeur. Les key/value paires de paramètres peuvent être référencées depuis l'expression de requête. Pour plus d'informations, voir [Expression de requête de recherche vectorielle](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
+ DIALECTE : (facultatif) : Spécifie votre dialecte. Le seul dialecte pris en charge est le 2.
**RÉPONSE**
La commande renvoie soit un tableau en cas de succès, soit une erreur.
En cas de succès, la première entrée du tableau de réponses représente le nombre de clés correspondantes, suivie d'une entrée de tableau pour chaque clé correspondante. Notez que si l'`LIMIT`option est spécifiée, elle ne contrôlera que le nombre de clés renvoyées et n'affectera pas la valeur de la première entrée.
Lorsque `NOCONTENT` cette valeur est spécifiée, chaque entrée de la réponse contient uniquement le nom de clé correspondant. Sinon, chaque entrée inclut le nom de clé correspondant, suivi d'un tableau des champs renvoyés. Les champs de résultat d'une clé sont constitués d'un ensemble de name/value paires. La première name/value paire correspond à la distance calculée. Le nom de cette paire est construit à partir du nom du champ vectoriel précédé par « \$1\$1 » et ajouté par « \$1score » et la valeur est la distance calculée. Les name/value paires restantes sont les membres et les valeurs de la clé tels que contrôlés par la `RETURN` clause.
La chaîne de requête est conforme à cette syntaxe :
```
=>[ KNN @ $ ]
```
Où :
+ : est soit une expression\$1, soit une expression de filtre. Un \$1 indique qu'il n'y a aucun filtrage et que tous les vecteurs de l'index sont donc recherchés. Une expression de filtre peut être fournie pour désigner un sous-ensemble des vecteurs à rechercher.
+ : nom d'un champ vectoriel dans l'index spécifié.
+ : Le nombre de vecteurs du plus proche voisin à renvoyer.
+ : nom PARAM dont la valeur correspondante fournit le vecteur de requête pour l'algorithme KNN. Notez que ce paramètre doit être codé sous forme de virgule flottante binaire IEEE 754 32 bits au format little-endian.
+ : (Facultatif) Une liste de keyword/value paires qui modifient cette recherche KNN particulière. Deux mots clés sont actuellement pris en charge :
+ EF\$1RUNTIME : Ce mot clé est accompagné d'une valeur entière qui remplace la valeur par défaut de EF\$1RUNTIME spécifiée lors de la création de l'index.
+ AS : Ce mot clé est accompagné d'une valeur de chaîne qui devient le nom du champ de score dans le résultat, remplaçant ainsi l'algorithme de génération de nom de champ de score par défaut.
**Expression du filtre**
Une expression de filtre est construite comme une combinaison logique d'opérateurs de recherche numériques et de balises contenus entre parenthèses.
**Balise**
L'opérateur de recherche de balises est spécifié par une ou plusieurs chaînes séparées par le caractère \$1. Une clé satisfera l'opérateur de recherche de balises si le champ indiqué contient l'une des chaînes spécifiées.
```
@:{}
or
@:{ | }
or
@:{ | | ...}
```
Par exemple, la requête suivante renverra des documents de couleur bleue, noire OU verte.
`@color:{blue | black | green}`
Autre exemple, la requête suivante renverra des documents contenant « hello world » ou « hello universe ».
`@description:{hello world | hello universe}`
**Plage numérique**
L'opérateur de plage numérique permet de filtrer les requêtes pour ne renvoyer que les valeurs comprises entre une valeur de début et une valeur de fin données. Les requêtes de plage inclusives et exclusives sont prises en charge. Pour des comparaisons relationnelles simples, \$1inf, -inf peuvent être utilisés avec une requête de plage. La syntaxe d'un opérateur de recherche par plage est la suivante :
```
@:[ [(] [(] ]
```
... où est soit un nombre, soit \$1inf ou -inf. Les limites sans premier parent ouvert sont inclusives, tandis que les limites avec le premier parent ouvert sont exclusives.
Utilisez le tableau suivant comme guide pour mapper des expressions mathématiques à des requêtes de filtrage :
```
min <= field <= max @field:[min max]
min < field <= max @field:[(min max]
min <= field < max @field:[min (max]
min < field < max @field:[(min (max]
field >= min @field:[min +inf]
field > min @field:[(min +inf]
field <= max @field:[-inf max]
field < max @field:[-inf (max]
field == val @field:[val val]
```
**Opérateurs logiques**
Plusieurs balises et opérateurs de recherche numériques peuvent être utilisés pour créer des requêtes complexes à l'aide d'opérateurs logiques.
**Logique ET**
Pour définir un ET logique, utilisez un espace entre les prédicats. Par exemple :
`query1 query2 query3`
**OU logique**
Pour définir un OR logique, utilisez un espace entre les prédicats. Par exemple :
`query1 | query2 | query3`
**Négation logique**
Toute requête peut être annulée en ajoutant le `-` caractère avant chaque requête. Les requêtes négatives renvoient toutes les entrées qui ne correspondent pas à la requête. Cela inclut également les clés qui n'ont pas le champ.
Par exemple, une requête négative sur @genre : \$1comedy\$1 renverra tous les livres qui ne sont pas des comédies ET tous les livres qui n'ont pas de champ de genre.
La requête suivante renverra tous les livres du genre « comédie » qui n'ont pas été publiés entre 2015 et 2024, ou qui n'ont pas de champ annuel : @genre : [comedy] - @year : [2015 2024]
**Priorité des opérateurs**
Les règles de priorité des opérateurs typiques s'appliquent, c'est-à-dire que le NEGATE logique est la priorité la plus élevée, suivi par le OU logique ET ensuite le OU logique avec la priorité la plus faible. Les parenthèses peuvent être utilisées pour remplacer les règles de priorité par défaut.
*Exemples de combinaison d'opérateurs logiques*
Les opérateurs logiques peuvent être combinés pour former des expressions de filtre complexes.
La requête suivante renverra tous les livres du genre « comédie » ou « horreur » (AND) publiés entre 2015 et 2024 : `@genre:[comedy|horror] @year:[2015 2024]`
La requête suivante renverra tous les livres du genre « comédie » ou « horreur » (OR) publiés entre 2015 et 2024 : `@genre:[comedy|horror] | @year:[2015 2024]`
La requête suivante renverra tous les livres qui n'ont pas de champ de genre ou dont le champ de genre n'est pas égal à « comédie », publiés entre 2015 et 2024 : `-@genre:[comedy] @year:[2015 2024]`
# FT.DROPINDEX
**Syntaxe**
```
FT.DROPINDEX
```
L'index spécifié est supprimé. Renvoie OK ou une erreur si cet index n'existe pas.
+ (obligatoire) : nom de l'index à supprimer.
# FT.INFO
**Syntaxe**
```
FT.INFO
```
La recherche vectorielle complète la commande [FT.INFO](https://valkey.io/commands/info/) avec plusieurs sections supplémentaires de statistiques et de compteurs. Une demande de récupération de la section SEARCH permet de récupérer toutes les statistiques suivantes :
| Nom de la touche | Type de la valeur | Description |
| --- | --- | --- |
| nom\$1index | chaîne | Nom de l'index |
| options d'index | chaîne | Instances réservées. Actuellement réglé sur « 0 » |
| définition de l'index | array | Voir ci-dessous pour la définition de ces éléments du tableau. |
| attributs | tableau d'informations sur les attributs | Un élément de ce tableau pour chaque attribut défini, voir ci-dessous pour la définition des informations d'attribut. |
| num\$1docs | entier | Nombre de clés actuellement contenues dans l'index |
| num\$1terms | entier | Instances réservées. Actuellement réglé sur « 0 ». |
| nombre d'enregistrements | entier | Somme du champ « taille » pour chaque attribut. |
| hash\$1indexing\$1failures | entier | Nombre de fois où un attribut n'a pas pu être converti dans le type d'attribut déclaré. Malgré le nom, cela s'applique également aux clés JSON. |
| backfill\$1in\$1progress | entier | Si un remblayage est actuellement en cours, ce sera un « 1 », sinon ce sera un « 0 » |
| % de remplissage complet | float | Estimation de l'achèvement du remblayage, un nombre fractionnaire compris entre [0.. 1] |
| taille de file d'attente mutationnelle | entier | Nombre de clés en attente de mise à jour de l'index. |
| recent\$1mutations\$1queue\$1delay | entier | Estimation du délai (en secondes) de mise à jour de l'index. 0 si aucune mise à jour n'est en cours. |
| state | chaîne | État du remblayage : « prêt » indique que le remblayage a été effectué avec succès. « backfill\$1in\$1progress » indique que le remblayage est en cours. « backfill\$1paused\$1by\$1oom » signifie que le remblayage a été suspendu en raison d'une insuffisance de mémoire. Une fois le problème de mémoire insuffisant résolu, le backill se poursuivra. |
La structure index\$1definition est un tableau de key/value paires définies comme suit :
| Nom de la touche | Type de la valeur | Description |
| --- | --- | --- |
| type\$1clé | chaîne | Soit la chaîne « JSON » soit la chaîne « HASH » |
| prefixes | array | Chaque élément du tableau est un préfixe défini pour l'index. Si aucun préfixe n'a été spécifié lors de la création de l'index, ce tableau comportera 0 entrées. |
| score par défaut | chaîne | Instances réservées. Actuellement réglé sur « 1 » |
Informations sur les attributs : les informations sur les attributs sont spécifiques au type.
Attributs numériques :
| Clé | Type de la valeur | Description |
| --- | --- | --- |
| identifiant | chaîne | Emplacement de l'attribut dans une clé. Nom du membre de hachage ou chemin JSON |
| alias | chaîne | Nom de l'attribut utilisé dans les descriptions des requêtes. |
| type | chaîne | La chaîne « NUMERIC » |
| size | entier | Nombre de clés contenant des valeurs numériques valides dans cet attribut. |
Attributs des balises :
| Nom de la touche | Type de la valeur | Description |
| --- | --- | --- |
| identifiant | chaîne | Emplacement de l'attribut dans une clé. Nom du membre de hachage ou chemin JSON |
| alias | chaîne | Nom de l'attribut utilisé dans les descriptions des requêtes. |
| type | chaîne | La chaîne « TAG » |
| SEPARATOR | character | Le caractère séparateur défini lors de la création de l'index |
| SENSIBLE AUX MAJUSCULES ET MINUSCULES | N/A | Cette clé n'a aucune valeur associée. Il n'est présent que si l'attribut a été créé avec cette option. |
| size | entier | Le nombre de clés avec des valeurs de balise valides dans cet attribut |
Attributs vectoriels :
| Nom de la touche | Type de la valeur | Description |
| --- | --- | --- |
| identifiant | chaîne | Emplacement de l'attribut dans une clé. Nom du membre de hachage ou chemin JSON |
| alias | chaîne | Nom de l'attribut utilisé dans les descriptions des requêtes. |
| type | chaîne | La chaîne « VECTOR » |
| index | character | Pour une description plus détaillée de l'indice vectoriel, voir ci-dessous. |
Description de l'index vectoriel :
| Nom de la touche | Type de la valeur | Description |
| --- | --- | --- |
| capacity | chaîne | Capacité actuelle de l'indice |
| dimensions | chaîne | Nombre d'éléments dans chaque vecteur |
| métrique de distance | chaîne | L'un des types « COSINE », « L2 » ou « IP » |
| size | array | Description de l'indice vectoriel, voir ci-dessous. |
| data\$1type | chaîne | Type de données déclaré. Seul « FLOAT32 » est actuellement pris en charge. |
| automatique | array | Description plus détaillée de l'algorithme de recherche vectorielle. |
Description de l'algorithme de recherche FLAT Vector :
| Nom de la touche | Type de la valeur | Description |
| --- | --- | --- |
| name | chaîne | Nom de l'algorithme : FLAT |
| block\$1size | number | Taille d'un bloc de l'index FLAT. |
Description de l'indice vectoriel HNSW :
| Nom de la touche | Type de la valeur | Description |
| --- | --- | --- |
| name | chaîne | Nom de l'algorithme : HNSW |
| m | number | Le paramètre « M » pour HNSW |
| ef\$1construction | number | Le paramètre « ef\$1construction » pour HNSW |
| ef\$1runtime | number | Le paramètre « ef\$1runtime » pour HNSW. |
# PIEDS. \$1LISTE
Répertoriez tous les index.
**Syntaxe**
```
FT._LIST
```
Renvoie un tableau de chaînes qui sont les noms de l'index actuellement défini.
# Commencer à utiliser JSON pour Valkey et Redis OSS
ElastiCache prend en charge le format natif JSON ( JavaScript Object Notation), qui est un moyen simple et sans schéma d'encoder des ensembles de données complexes dans des clusters Valkey et Redis OSS. Vous pouvez stocker et accéder aux données de manière native à l'aide du format JSON ( JavaScript Object Notation) au sein des clusters, et mettre à jour les données JSON stockées dans ces clusters, sans avoir à gérer de code personnalisé pour les sérialiser et les désérialiser.
En plus d'utiliser les opérations d'API Valkey et Redis OSS pour les applications qui fonctionnent via JSON, vous pouvez désormais récupérer et mettre à jour efficacement des parties spécifiques d'un document JSON sans avoir à manipuler l'objet dans son intégralité. Cela peut améliorer les performances et réduire les coûts. Vous pouvez également rechercher le contenu de votre document JSON à l'aide de la requête `JSONPath` de [style Goessner](https://goessner.net/articles/JsonPath/).
Après avoir créé un cluster avec une version de moteur prise en charge, le type de données JSON et les commandes associées sont automatiquement disponibles. Compatible avec les API et compatible RDB avec la version 2 du module JSON, vous pouvez donc facilement migrer les applications Valkey et Redis OSS existantes basées sur JSON vers. ElastiCache Pour plus d'informations sur les commandes prises en charge, consultez[Commandes Valkey et Redis OSS prises en chargeCommandes JSON](json-list-commands.md).
Les métriques `JsonBasedCmds` liées au JSON `JsonBasedCmdsLatency` sont intégrées CloudWatch pour surveiller l'utilisation de ce type de données. Pour plus d'informations, consultez [Metrics for Valkey et Redis OSS](CacheMetrics.Redis.md).
**Note**
Pour utiliser JSON, vous devez exécuter Valkey 7.2 ou version ultérieure, ou Redis OSS 6.2.6 ou version ultérieure.
**Topics**
+ [Vue d'ensemble des types de données JSON](json-document-overview.md)
+ [Commandes Valkey et Redis OSS prises en charge](json-list-commands.md)
# Vue d'ensemble des types de données JSON
ElastiCache prend en charge un certain nombre de commandes Valkey et Redis OSS pour travailler avec le type de données JSON. Vous trouverez ci-dessous un aperçu du type de données JSON et une liste détaillée des commandes prises en charge.
## Terminologie
****
| Terme | Description |
| --- | --- |
| Document JSON | Fait référence à la valeur d'une clé JSON. |
| Valeur JSON | Fait référence à un sous-ensemble d'un document JSON, y compris la racine qui représente le document entier. Une valeur peut être un conteneur ou une entrée dans un conteneur. |
| Élément JSON | Équivalent de la valeur JSON. |
## Norme JSON prise en charge
Le format JSON est conforme à la norme d'échange de données JSON [RFC 7159](https://www.ietf.org/rfc/rfc7159.txt) et [ECMA-404](https://www.ietf.org/rfc/rfc7159.txt). L'[Unicode](https://www.unicode.org/standard/WhatIsUnicode.html) UTF-8 dans le texte JSON est pris en charge.
## Élément racine
L'élément racine peut être de n'importe quel type de données JSON. Notez que dans la précédente RFC 4627, seuls les objets ou les tableaux étaient autorisés comme valeurs racine. Depuis la mise à jour vers la RFC 7159, la racine d'un document JSON peut être de n'importe quel type de données JSON.
## Limite de taille du document
Les documents JSON sont stockés en interne dans un format optimisé pour un accès et une modification rapides. Ce format entraîne généralement une consommation de mémoire un peu plus importante que la représentation sérialisée équivalente du même document.
La consommation de mémoire par un seul document JSON est limitée à 64 Mo, ce qui correspond à la taille de la structure de données en mémoire, et non de la chaîne JSON. Vous pouvez vérifier la quantité de mémoire consommée par un document JSON en utilisant la commande `JSON.DEBUG MEMORY`.
## JSON ACLs
+ Similaire aux catégories existantes par type de données (@string, @hash, etc.), une nouvelle catégorie @json est ajoutée pour simplifier la gestion de l'accès aux commandes et aux données JSON. Aucune autre commande Valkey ou Redis OSS existante n'appartient à la catégorie @json. Toutes les commandes JSON appliquent les restrictions et autorisations des keyspaces ou des commandes.
+ Cinq catégories d'ACL Valkey et Redis OSS existantes ont été mises à jour pour inclure les nouvelles commandes JSON : @read, @write, @fast, @slow et @admin. Le tableau suivant indique le mappage des commandes JSON aux catégories appropriées.
**ACL**
| Commande JSON | @read | @write | @fast | @slow | @admin |
| --- | --- | --- | --- | --- | --- |
| JSON.ARRAPPEND | | y | y | | |
| JSON.ARRINDEX | y | | y | | |
| JSON.ARRINSERT | | y | y | | |
| JSON.ARRLEN | y | | y | | |
| JSON.ARRPOP | | y | y | | |
| JSON.ARRTRIM | | y | y | | |
| JSON.CLEAR | | y | y | | |
| JSON.DEBUG | y | | | y | y |
| JSON.DEL | | y | y | | |
| JSON.FORGET | | y | y | | |
| JSON.GET | y | | y | | |
| JSON.MGET | y | | y | | |
| JSON.NUMINCRBY | | y | y | | |
| JSON.NUMMULTBY | | y | y | | |
| JSON.OBJKEYS | y | | y | | |
| JSON.OBJLEN | y | | y | | |
| JSON.RESP | y | | y | | |
| JSON.SET | | y | | y | |
| JSON.STRAPPEND | | y | y | | |
| JSON.STRLEN | y | | y | | |
| JSON.STRLEN | y | | y | | |
| JSON.TOGGLE | | y | y | | |
| JSON.TYPE | y | | y | | |
| JSON.NUMINCRBY | | y | y | | |
## Limite de profondeur d'imbrication
Lorsqu'un objet ou un tableau JSON possède un élément qui est lui-même un autre objet ou tableau JSON, cet objet ou tableau intérieur est dit « imbriqué » dans l'objet ou le tableau extérieur. La limite maximale de la profondeur d'imbrication est de 128. Toute tentative de création d'un document contenant une profondeur d'imbrication supérieure à 128 sera rejetée avec une erreur.
## Syntaxe de commande
La plupart des commandes nécessitent un nom de clé comme premier argument. Certaines commandes ont également un argument path. L'argument path correspond par défaut à la racine s'il est optionnel et non fourni.
Notation :
+ Les arguments obligatoires sont entourés de chevrons. Par exemple :
+ Les arguments facultatifs sont entourés de crochets. Par exemple : [path]
+ Les arguments facultatifs supplémentaires sont indiqués par une ellipse (« … »). Par exemple : [json ...]
## Syntaxe de chemin
Le JSON de Redis prend en charge deux types de syntaxe de chemin :
+ **Syntaxe améliorée** — Suit la JSONPath syntaxe décrite par [Goessner](https://goessner.net/articles/JsonPath/), comme indiqué dans le tableau suivant. Nous avons réorganisé et modifié les descriptions dans le tableau pour plus de clarté.
+ **Syntaxe restreinte** : possède des capacités de requête limitées.
**Note**
Les résultats de certaines commandes sont sensibles au type de syntaxe de chemin utilisé.
Si un chemin de requête commence par « \$1 », il utilise la syntaxe améliorée. Sinon, la syntaxe restreinte est utilisée.
**Syntaxe améliorée**
****
| Symbole/Expression | Description |
| --- | --- |
| \$1 | L'élément racine. |
| . ou [] | Opérateur enfant. |
| .. | Descente récursive. |
| \$1 | Caractère générique. Tous les éléments d'un objet ou d'un tableau. |
| [] | Opérateur d'indice de tableau. L'index est basé sur 0. |
| [,] | Opérateur d'union. |
| [start:end:step] | Opérateur de découpage de tableau. |
| ?() | Applique une expression de filtre (script) au tableau ou à l'objet en cours. |
| () | Expression de filtre. |
| @ | Utilisé dans les expressions de filtre qui font référence au nœud en cours de traitement. |
| == | Égal à, utilisé dans les expressions de filtre. |
| \$1= | Pas égal à, utilisé dans les expressions de filtre. |
| > | Supérieur à, utilisé dans les expressions de filtre. |
| >= | Supérieur ou égal à, utilisé dans les expressions de filtre. |
| < | Inférieur à, utilisé dans les expressions de filtre. |
| <= | Inférieur ou égal à, utilisé dans les expressions de filtre. |
| && | AND logique, utilisé pour combiner plusieurs expressions de filtre. |
| \$1\$1 | OR logique, utilisé pour combiner plusieurs expressions de filtre. |
**Exemples**
Les exemples suivants sont basés sur l'exemple de données XML de [Goessner](https://goessner.net/articles/JsonPath/), que nous avons modifié en ajoutant des champs supplémentaires.
```
{ "store": {
"book": [
{ "category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95,
"in-stock": true,
"sold": true
},
{ "category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99,
"in-stock": false,
"sold": true
},
{ "category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99,
"in-stock": true,
"sold": false
},
{ "category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99,
"in-stock": false,
"sold": false
}
],
"bicycle": {
"color": "red",
"price": 19.95,
"in-stock": true,
"sold": false
}
}
}
```
****
| Chemin | Description |
| --- | --- |
| \$1.store.book[\$1].author | Les auteurs de tous les livres de la boutique. |
| \$1..author | Tous les auteurs. |
| \$1.store.\$1 | Tous les membres de la boutique. |
| \$1["store"].\$1 | Tous les membres de la boutique. |
| \$1.store..price | Le prix de tout ce qui se trouve dans la boutique. |
| \$1..\$1 | Tous les membres récursifs de la structure JSON. |
| \$1..book[\$1] | Tous les livres. |
| \$1..book[0] | Le premier livre. |
| \$1..book[-1] | Le dernier livre. |
| \$1..book[0:2] | Les deux premiers livres. |
| \$1..book[0,1] | Les deux premiers livres. |
| \$1..book[0:4] | Les livres d'index 0 à 3 (l'index final n'est pas inclusif). |
| \$1..book[0:4:2] | Les livres à l'index 0, 2. |
| \$1..book[?(@.isbn)] | Tous les livres ayant un numéro ISBN. |
| \$1..book[?(@.price<10)] | Tous les livres dont le prix est inférieur à 10 USD. |
| '\$1..book[?(@.price < 10)]' | Tous les livres dont le prix est inférieur à 10 USD. (Le chemin doit être entre guillemets s'il contient des espaces blancs). |
| '\$1..book[?(@["price"] < 10)]' | Tous les livres dont le prix est inférieur à 10 USD. |
| '\$1..book[?(@.["price"] < 10)]' | Tous les livres dont le prix est inférieur à 10 USD. |
| \$1.. book [? (@.prix>=10&&@.prix<=100)] | Tous les livres dans la fourchette de prix comprise entre 10 et 100 USD. |
| '\$1..book[?(@.price>=10 && @.price<=100)]' | Tous les livres dans la fourchette de prix comprise entre 10 et 100 USD. (Le chemin doit être entre guillemets s'il contient des espaces blancs). |
| \$1..book[?(@.sold==true\$1\$1@.in-stock==false)] | Tous les livres vendus ou en rupture de stock. |
| '\$1..book[?(@.sold == true \$1\$1 @.in-stock == false)]' | Tous les livres vendus ou en rupture de stock. (Le chemin doit être entre guillemets s'il contient des espaces blancs). |
| '\$1.store.book[?(@.["category"] == "fiction")]' | Tous les livres dans la catégorie fiction. |
| '\$1.store.book[?(@.["category"] \$1= "fiction")]' | Tous les livres dans la catégorie non-fiction. |
Exemples d'expressions de filtre supplémentaires :
```
127.0.0.1:6379> JSON.SET k1 . '{"books": [{"price":5,"sold":true,"in-stock":true,"title":"foo"}, {"price":15,"sold":false,"title":"abc"}]}'
OK
127.0.0.1:6379> JSON.GET k1 $.books[?(@.price>1&&@.price<20&&@.in-stock)]
"[{\"price\":5,\"sold\":true,\"in-stock\":true,\"title\":\"foo\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?(@.price>1 && @.price<20 && @.in-stock)]'
"[{\"price\":5,\"sold\":true,\"in-stock\":true,\"title\":\"foo\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?((@.price>1 && @.price<20) && (@.sold==false))]'
"[{\"price\":15,\"sold\":false,\"title\":\"abc\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?(@.title == "abc")]'
[{"price":15,"sold":false,"title":"abc"}]
127.0.0.1:6379> JSON.SET k2 . '[1,2,3,4,5]'
127.0.0.1:6379> JSON.GET k2 $.*.[?(@>2)]
"[3,4,5]"
127.0.0.1:6379> JSON.GET k2 '$.*.[?(@ > 2)]'
"[3,4,5]"
127.0.0.1:6379> JSON.SET k3 . '[true,false,true,false,null,1,2,3,4]'
OK
127.0.0.1:6379> JSON.GET k3 $.*.[?(@==true)]
"[true,true]"
127.0.0.1:6379> JSON.GET k3 '$.*.[?(@ == true)]'
"[true,true]"
127.0.0.1:6379> JSON.GET k3 $.*.[?(@>1)]
"[2,3,4]"
127.0.0.1:6379> JSON.GET k3 '$.*.[?(@ > 1)]'
"[2,3,4]"
```
**Syntaxe restreinte**
****
| Symbole/Expression | Description |
| --- | --- |
| . ou [] | Opérateur enfant. |
| [] | Opérateur d'indice de tableau. L'index est basé sur 0. |
**Exemples**
****
| Chemin | Description |
| --- | --- |
| .store.book[0].author | L'auteur du premier livre. |
| .store.book[-1].author | L'auteur du dernier livre. |
| .address.city | Le nom de la ville. |
| ["store"]["book"][0]["title"] | Le titre du premier livre. |
| ["store"]["book"][-1]["title"] | Le titre du dernier livre. |
**Note**
Tout le contenu de [Goessner](https://goessner.net/articles/JsonPath/) cité dans cette documentation est soumis à la [licence Creative Commons](https://creativecommons.org/licenses/by/2.5/).
## Préfixes d'erreur courantes
Chaque message d'erreur possède un préfixe. Voici une liste des préfixes d'erreur courants.
****
| Préfixe | Description |
| --- | --- |
| ERR | Une erreur générale. |
| LIMIT | Une erreur qui se produit lorsque la limite de taille est dépassée. Par exemple, la limite de taille du document ou la limite de profondeur d'imbrication a été dépassée. |
| NONEXISTENT | Une clé ou un chemin n'existe pas. |
| OUTOFBOUNDARIES | L'index du tableau est hors limites. |
| SYNTAXERR | Erreur de syntaxe. |
| WRONGTYPE | Mauvais type de valeur. |
## Métriques liées à JSON
Les métriques d'informations JSON suivantes sont fournies :
****
| Infos | Description |
| --- | --- |
| json\$1total\$1memory\$1bytes | Mémoire totale allouée aux objets JSON. |
| json\$1num\$1documents | Nombre total de documents dans Valkey ou Redis OSS. |
Pour interroger les métriques principales, exécutez la commande suivante :
```
info json_core_metrics
```
## Comment ElastiCache pour Valkey et Redis OSS interagit avec JSON
La section suivante décrit comment ElastiCache Valkey et Redis OSS interagit avec le type de données JSON.
### Priorité des opérateurs
Lors de l'évaluation d'expressions conditionnelles pour le filtrage, les && sont prioritaires, puis les \$1\$1 sont évalués, comme c'est le cas dans la plupart des langages. Les opérations à l'intérieur des parenthèses sont exécutées en premier.
### Comportement de la limite maximale d'imbrication des chemins
La limite maximale d'imbrication de chemins dans ElastiCache Redis OSS est de 128. Ainsi, une valeur comme `$.a.b.c.d...` ne peut atteindre que 128 niveaux.
### Traitement des valeurs numériques
JSON n'a pas de types de données séparés pour les nombres entiers et les nombres à virgule flottante. Ils sont tous appelés des nombres.
Représentations numériques :
Lorsqu'un nombre JSON est reçu en entrée, il est converti en l'une des deux représentations binaires internes : un entier signé de 64 bits ou une virgule flottante IEEE à double précision de 64 bits. La chaîne de caractères d'origine et toute sa mise en forme ne sont pas retenues. Ainsi, lorsqu'un nombre est généré en sortie dans le cadre d'une réponse JSON, il est converti de la représentation binaire interne en une chaîne imprimable qui utilise des règles de formatage génériques. Ces règles peuvent entraîner la génération d'une chaîne différente de celle qui a été reçue.
Commandes arithmétiques `NUMINCRBY` et `NUMMULTBY` :
+ Si les deux nombres sont des entiers et que le résultat est hors de la plage de `int64`, il devient automatiquement un nombre à virgule flottante IEEE à double précision de 64 bits.
+ Si au moins un des nombres est un nombre à virgule flottante, le résultat est un nombre à virgule flottante IEEE à double précision de 64 bits.
+ Si le résultat dépasse la plage du double IEEE de 64 bits, la commande renvoie une erreur `OVERFLOW`.
Pour une liste détaillée des commandes disponibles, consultez [Commandes Valkey et Redis OSS prises en chargeCommandes JSON](json-list-commands.md).
### Filtrage direct de tableau
ElastiCache pour Valkey ou Redis OSS filtre directement les objets du tableau.
Pour des données comme `[0,1,2,3,4,5,6]` et une requête de chemin comme`$[?(@<4)]`, ou des données similaires `{"my_key":[0,1,2,3,4,5,6]}` et une requête de chemin comme`$.my_key[?(@<4)]`, ElastiCache renverrait [1,2,3] dans les deux cas.
### Comportement d'indexation de tableau
ElastiCache pour Valkey ou Redis OSS autorise les indices positifs et négatifs pour les tableaux. Pour un tableau de longueur cinq, 0 interrogerait le premier élément, 1 le deuxième, et ainsi de suite. Les nombres négatifs commencent à la fin du tableau, donc -1 interrogerait le cinquième élément, -2 le quatrième élément, et ainsi de suite.
Pour garantir un comportement prévisible aux clients, ElastiCache n'arrondit pas les index des tableaux vers le bas ou vers le haut. Ainsi, si vous avez un tableau d'une longueur de 5, le fait d'appeler l'index 5 ou plus, ou -6 ou moins, ne produira aucun résultat.
### Évaluation stricte de la syntaxe
MemoryDB n'autorise pas les chemins JSON dont la syntaxe est invalide, même si un sous-ensemble du chemin contient un chemin valide. Ceci afin de maintenir un comportement correct pour nos clients.
# Commandes Valkey et Redis OSS prises en charge
ElastiCache prend en charge les commandes JSON Valkey et Redis OSS suivantes :
**Topics**
+ [JSON.ARRAPPEND](json-arrappend.md)
+ [JSON.ARRINDEX](json-arrindex.md)
+ [JSON.ARRINSERT](json-arrinsert.md)
+ [JSON.ARRLEN](json-arrlen.md)
+ [JSON.ARRPOP](json-arrpop.md)
+ [JSON.ARRTRIM](json-arrtrim.md)
+ [JSON.CLEAR](json-clear.md)
+ [JSON.DEBUG](json-debug.md)
+ [JSON.DEL](json-del.md)
+ [JSON.FORGET](json-forget.md)
+ [JSON.GET](json-get.md)
+ [JSON.MGET](json-mget.md)
+ [JSON.MSET](json-mset.md)
+ [JSON.NUMINCRBY](json-numincrby.md)
+ [JSON.NUMMULTBY](json-nummultby.md)
+ [JSON.OBJLEN](json-objlen.md)
+ [JSON.OBJKEYS](json-objkeys.md)
+ [JSON.RESP](json-resp.md)
+ [JSON.SET](json-set.md)
+ [JSON.STRAPPEND](json-strappend.md)
+ [JSON.STRLEN](json-strlen.md)
+ [JSON.TOGGLE](json-toggle.md)
+ [JSON.TYPE](json-type.md)
# JSON.ARRAPPEND
Ajoute une ou plusieurs valeurs aux valeurs du tableau au niveau du chemin.
Syntaxe
```
JSON.ARRAPPEND [json ...]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (obligatoire) : chemin JSON.
+ json (obligatoire) : valeur JSON à ajouter au tableau.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers qui représentent la nouvelle longueur du tableau au niveau de chaque chemin.
+ Si une valeur n'est pas un tableau, sa valeur de retour correspondante est nulle.
+ Erreur `NONEXISTENT` si le chemin n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Entier, la nouvelle longueur du tableau.
+ Si plusieurs valeurs de tableau sont sélectionnées, la commande renvoie la nouvelle longueur du premier tableau mis à jour.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un tableau.
+ Erreur `SYNTAXERR` si l'un des arguments d'entrée json n'est pas une chaîne JSON valide.
+ Erreur `NONEXISTENT` si le chemin n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRAPPEND k1 $[*] '"c"'
1) (integer) 1
2) (integer) 2
3) (integer) 3
127.0.0.1:6379> JSON.GET k1
"[[\"c\"],[\"a\",\"c\"],[\"a\",\"b\",\"c\"]]"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRAPPEND k1 [-1] '"c"'
(integer) 3
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"],[\"a\",\"b\",\"c\"]]"
```
# JSON.ARRINDEX
Recherche la première occurrence d'une valeur scalaire JSON dans les tableaux au niveau du chemin.
+ Les erreurs hors limites sont traitées en arrondissant l'index au début et à la fin du tableau.
+ Si start > end, retourner -1 (non trouvé).
Syntaxe
```
JSON.ARRINDEX [start [end]]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (obligatoire) : chemin JSON.
+ json-scalar (obligatoire) : valeur scalaire à rechercher. JSON scalar fait référence à des valeurs qui ne sont pas des objets ou des tableaux. C'est-à-dire que les chaînes, les nombres, les booléens et les valeurs·nulles sont des valeurs scalaires.
+ start (facultatif) : index de départ, inclusif. La valeur par défaut est 0 si elle n'est pas fournie.
+ end (facultatif) : index de fin, exclusif. La valeur par défaut est 0 si elle n'est pas fournie, ce qui signifie que le dernier élément est inclus. 0 ou -1 signifie que le dernier élément est inclus.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers. Chaque valeur est l'index de l'élément correspondant dans le tableau au niveau du chemin. La valeur est -1 si elle n'est pas trouvée.
+ Si une valeur n'est pas un tableau, sa valeur de retour correspondante est nulle.
Si le chemin est une syntaxe restreinte :
+ Entier, l'index de l'élément correspondant, ou -1 si non trouvé.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un tableau.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRINDEX k1 $[*] '"b"'
1) (integer) -1
2) (integer) -1
3) (integer) 1
4) (integer) 1
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.ARRINDEX k1 .children '"Tom"'
(integer) 2
```
# JSON.ARRINSERT
Insère une ou plusieurs valeurs dans le tableau des valeurs au niveau du chemin avant l'index.
Syntaxe
```
JSON.ARRINSERT [json ...]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (obligatoire) : chemin JSON.
+ index (obligatoire) – Un index de tableau avant lequel les valeurs sont insérées.
+ json (obligatoire) : valeur JSON à ajouter au tableau.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers qui représentent la nouvelle longueur du tableau au niveau de chaque chemin.
+ Si une valeur est un tableau vide, sa valeur de retour correspondante est nulle.
+ Si une valeur n'est pas un tableau, sa valeur de retour correspondante est nulle.
+ Erreur `OUTOFBOUNDARIES` si l'argument index est hors limites.
Si le chemin est une syntaxe restreinte :
+ Entier, la nouvelle longueur du tableau.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un tableau.
+ Erreur `OUTOFBOUNDARIES` si l'argument index est hors limites.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRINSERT k1 $[*] 0 '"c"'
1) (integer) 1
2) (integer) 2
3) (integer) 3
127.0.0.1:6379> JSON.GET k1
"[[\"c\"],[\"c\",\"a\"],[\"c\",\"a\",\"b\"]]"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRINSERT k1 . 0 '"c"'
(integer) 4
127.0.0.1:6379> JSON.GET k1
"[\"c\",[],[\"a\"],[\"a\",\"b\"]]"
```
# JSON.ARRLEN
Obtient la longueur des valeurs du tableau au niveau du chemin.
Syntaxe
```
JSON.ARRLEN [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers qui représentent la longueur du tableau au niveau de chaque chemin.
+ Si une valeur n'est pas un tableau, sa valeur de retour correspondante est nulle.
+ Valeur nulle si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Entier, longueur du tableau.
+ Si plusieurs objets sont sélectionnés, la commande renvoie la longueur du premier tableau.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un tableau.
+ Erreur `NONEXISTENT JSON` si le chemin n'existe pas.
+ Valeur nulle si la clé du document n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRLEN k1 $[*]
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 3
127.0.0.1:6379> JSON.SET k2 . '[[], "a", ["a", "b"], ["a", "b", "c"], 4]'
OK
127.0.0.1:6379> JSON.ARRLEN k2 $[*]
1) (integer) 0
2) (nil)
3) (integer) 2
4) (integer) 3
5) (nil)
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRLEN k1 [*]
(integer) 0
127.0.0.1:6379> JSON.ARRLEN k1 [1]
(integer) 1
127.0.0.1:6379> JSON.ARRLEN k1 [2]
(integer) 2
127.0.0.1:6379> JSON.SET k2 . '[[], "a", ["a", "b"], ["a", "b", "c"], 4]'
OK
127.0.0.1:6379> JSON.ARRLEN k2 [1]
(error) WRONGTYPE JSON element is not an array
127.0.0.1:6379> JSON.ARRLEN k2 [0]
(integer) 0
127.0.0.1:6379> JSON.ARRLEN k2 [6]
(error) OUTOFBOUNDARIES Array index is out of bounds
127.0.0.1:6379> JSON.ARRLEN k2 a.b
(error) NONEXISTENT JSON path does not exist
```
# JSON.ARRPOP
Supprime et renvoie l'élément à l'index du tableau. L'extraction d'un tableau vide renvoie valeur nulle.
Syntaxe
```
JSON.ARRPOP [path [index]]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
+ index (facultatif) : La pposition dans le tableau à partir de laquelle l'extraction doit commencer.
+ La valeur par défaut est -1 si elle n'est pas fournie, ce qui signifie le dernier élément.
+ Une valeur négative signifie une position à partir du dernier élément.
+ Les index hors limites sont arrondis à leurs limites de tableau respectives.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau de chaînes en bloc qui représentent les valeurs extraites au niveau de chaque chemin.
+ Si une valeur est un tableau vide, sa valeur de retour correspondante est nulle.
+ Si une valeur n'est pas un tableau, sa valeur de retour correspondante est nulle.
Si le chemin est une syntaxe restreinte :
+ Chaîne en bloc, qui représente la valeur JSON extraite.
+ Valeur nulle si le tableau est vide.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un tableau.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k1 $[*]
1) (nil)
2) "\"a\""
3) "\"b\""
127.0.0.1:6379> JSON.GET k1
"[[],[],[\"a\"]]"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k1
"[\"a\",\"b\"]"
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"]]"
127.0.0.1:6379> JSON.SET k2 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k2 . 0
"[]"
127.0.0.1:6379> JSON.GET k2
"[[\"a\"],[\"a\",\"b\"]]"
```
# JSON.ARRTRIM
Coupe un tableau au niveau du chemin pour qu'il devienne un sous tableau [start, end], les deux inclus.
+ Si le tableau est vide, ne rien faire, retourner 0.
+ Si start <0, le traiter comme 0.
+ Si end >= size (taille du tableau), le traiter comme size-1.
+ Si start >= size ou start > end, vider le tableau et retourner 0.
Syntaxe
```
JSON.ARRTRIM
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (obligatoire) : chemin JSON.
+ start (obligatoire) – L'index de départ, inclusif.
+ end (obligatoire) – L'index de fin, inclusif.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers qui représentent la nouvelle longueur du tableau au niveau de chaque chemin.
+ Si une valeur est un tableau vide, sa valeur de retour correspondante est nulle.
+ Si une valeur n'est pas un tableau, sa valeur de retour correspondante est nulle.
+ Erreur `OUTOFBOUNDARIES` si un argument d'index est hors limites.
Si le chemin est une syntaxe restreinte :
+ Entier, la nouvelle longueur du tableau.
+ Valeur nulle si le tableau est vide.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un tableau.
+ Erreur `OUTOFBOUNDARIES` si un argument d'index est hors limites.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRTRIM k1 $[*] 0 1
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 2
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"],[\"a\",\"b\"],[\"a\",\"b\"]]"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.ARRTRIM k1 .children 0 1
(integer) 2
127.0.0.1:6379> JSON.GET k1 .children
"[\"John\",\"Jack\"]"
```
# JSON.CLEAR
Efface les tableaux ou un objet au niveau du chemin.
Syntaxe
```
JSON.CLEAR [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
+ Entier, le nombre de conteneurs effacés.
+ L'effacement d'un tableau ou d'un objet vide compte pour 1 conteneur effacé.
+ L'effacement d'une valeur non-conteneur retourne 0.
**Exemples**
```
127.0.0.1:6379> JSON.SET k1 . '[[], [0], [0,1], [0,1,2], 1, true, null, "d"]'
OK
127.0.0.1:6379> JSON.CLEAR k1 $[*]
(integer) 7
127.0.0.1:6379> JSON.CLEAR k1 $[*]
(integer) 4
127.0.0.1:6379> JSON.SET k2 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.CLEAR k2 .children
(integer) 1
127.0.0.1:6379> JSON.GET k2 .children
"[]"
```
# JSON.DEBUG
Rapporte des informations. Les sous-commandes prises en charge sont :
+ MEMORY [path] – Rapporte l'utilisation de la mémoire en octets d'une valeur JSON. Le chemin d'accès est par défaut la racine s'il n'est pas fourni.
+ FIELDS [path] – Rapporte le nombre de champs au niveau du chemin du document spécifié. Le chemin d'accès est par défaut la racine s'il n'est pas fourni. Chaque valeur JSON sans conteneur compte pour un champ. Les objets et les tableaux comptent récursivement un champ pour chacune de leurs valeurs JSON contenantes. Chaque valeur de conteneur, à l'exception du conteneur racine, compte pour un champ supplémentaire.
+ HELP – Imprime les messages d'aide de la commande.
Syntaxe
```
JSON.DEBUG
```
Dépend de la sous-commande :
MEMORY
+ Si le chemin est une syntaxe améliorée :
+ Renvoie un tableau d'entiers qui représentent la taille de la mémoire (en octets) de la valeur JSON au niveau de chaque chemin.
+ Renvoie un tableau vide si la clé Valkey ou Redis OSS n'existe pas.
+ Si le chemin est une syntaxe restreinte :
+ Renvoie un nombre entier, la taille de la mémoire et la valeur JSON en octets.
+ Renvoie null si la clé Valkey ou Redis OSS n'existe pas.
FIELDS
+ Si le chemin est une syntaxe améliorée :
+ Renvoie un tableau d'entiers qui représentent le nombre de champs de la valeur JSON au niveau de chaque chemin.
+ Renvoie un tableau vide si la clé Valkey ou Redis OSS n'existe pas.
+ Si le chemin est une syntaxe restreinte :
+ Renvoie un entier, le nombre de champs de la valeur JSON.
+ Renvoie null si la clé Valkey ou Redis OSS n'existe pas.
HELP : Renvoie un tableau de messages d'aide.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[1, 2.3, "foo", true, null, {}, [], {"a":1, "b":2}, [1,2,3]]'
OK
127.0.0.1:6379> JSON.DEBUG MEMORY k1 $[*]
1) (integer) 16
2) (integer) 16
3) (integer) 19
4) (integer) 16
5) (integer) 16
6) (integer) 16
7) (integer) 16
8) (integer) 50
9) (integer) 64
127.0.0.1:6379> JSON.DEBUG FIELDS k1 $[*]
1) (integer) 1
2) (integer) 1
3) (integer) 1
4) (integer) 1
5) (integer) 1
6) (integer) 0
7) (integer) 0
8) (integer) 2
9) (integer) 3
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.DEBUG MEMORY k1
(integer) 632
127.0.0.1:6379> JSON.DEBUG MEMORY k1 .phoneNumbers
(integer) 166
127.0.0.1:6379> JSON.DEBUG FIELDS k1
(integer) 19
127.0.0.1:6379> JSON.DEBUG FIELDS k1 .address
(integer) 4
127.0.0.1:6379> JSON.DEBUG HELP
1) JSON.DEBUG MEMORY [path] - report memory size (bytes) of the JSON element. Path defaults to root if not provided.
2) JSON.DEBUG FIELDS [path] - report number of fields in the JSON element. Path defaults to root if not provided.
3) JSON.DEBUG HELP - print help message.
```
# JSON.DEL
Supprime les valeurs JSON au niveau du chemin dans une clé de document. Si le chemin est la racine, cela revient à supprimer la clé de Valkey ou Redis OSS.
Syntaxe
```
JSON.DEL [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
+ Nombre d'éléments supprimés.
+ 0 si la clé Valkey ou Redis OSS n'existe pas.
+ 0 si le chemin JSON n'est pas valide ou n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.DEL k1 $.d.*
(integer) 3
127.0.0.1:6379> JSOn.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.DEL k1 $.e[*]
(integer) 5
127.0.0.1:6379> JSOn.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[]}"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.DEL k1 .d.*
(integer) 3
127.0.0.1:6379> JSON.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.DEL k1 .e[*]
(integer) 5
127.0.0.1:6379> JSON.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[]}"
```
# JSON.FORGET
Un alias de [JSON.DEL](json-del.md).
# JSON.GET
Renvoie le JSON sérialisé sur un ou plusieurs chemins.
Syntaxe
```
JSON.GET
[INDENT indentation-string]
[NEWLINE newline-string]
[SPACE space-string]
[NOESCAPE]
[path ...]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ INDENT/NEWLINE/SPACE(facultatif) — Contrôle le format de la chaîne JSON renvoyée, c'est-à-dire « pretty print ». La valeur par défaut de chacun d'elle est une chaîne vide. Elles peuvent être remplacées par n'importe quelle combinaison. Elles peuvent être spécifiées dans n'importe quel ordre.
+ NOESCAPE : Facultatif, autorisé à être présent pour la compatibilité héritée et n'a aucun autre effet.
+ path (facultatif) : zéro ou plusieurs chemins JSON, par défaut la racine si aucun n'est donné. Les arguments de chemin doivent être placés à la fin.
**Retour**
Syntaxe de chemin améliorée :
Si un seul chemin est fourni :
+ Renvoie une chaîne sérialisée d'un tableau de valeurs.
+ Si aucune valeur n'est sélectionnée, la commande renvoie un tableau vide.
Si plusieurs chemins sont fournis :
+ Renvoie un objet JSON sérialisé, dans lequel chaque chemin est une clé.
+ Si la syntaxe des chemins est mixte, améliorée et restreinte, le résultat est conforme à la syntaxe améliorée.
+ Si un chemin n'existe pas, sa valeur correspondante est un tableau vide.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.GET k1 $.address.*
"[\"21 2nd Street\",\"New York\",\"NY\",\"10021-3100\"]"
127.0.0.1:6379> JSON.GET k1 indent "\t" space " " NEWLINE "\n" $.address.*
"[\n\t\"21 2nd Street\",\n\t\"New York\",\n\t\"NY\",\n\t\"10021-3100\"\n]"
127.0.0.1:6379> JSON.GET k1 $.firstName $.lastName $.age
"{\"$.firstName\":[\"John\"],\"$.lastName\":[\"Smith\"],\"$.age\":[27]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}}'
OK
127.0.0.1:6379> json.get k2 $..*
"[{},{\"a\":1},{\"a\":1,\"b\":2},1,1,2]"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.GET k1 .address
"{\"street\":\"21 2nd Street\",\"city\":\"New York\",\"state\":\"NY\",\"zipcode\":\"10021-3100\"}"
127.0.0.1:6379> JSON.GET k1 indent "\t" space " " NEWLINE "\n" .address
"{\n\t\"street\": \"21 2nd Street\",\n\t\"city\": \"New York\",\n\t\"state\": \"NY\",\n\t\"zipcode\": \"10021-3100\"\n}"
127.0.0.1:6379> JSON.GET k1 .firstName .lastName .age
"{\".firstName\":\"John\",\".lastName\":\"Smith\",\".age\":27}"
```
# JSON.MGET
Il est sérialisé JSONs sur le chemin à partir de plusieurs clés de document. Elle renvoie une valeur nulle pour une clé ou un chemin JSON inexistant.
**Syntaxe**
```
JSON.MGET [key ...]
```
+ clé (obligatoire) — Une ou plusieurs clés Valkey ou Redis OSS de type document.
+ path (obligatoire) : chemin JSON.
**Retour**
+ Tableau de chaînes en bloc. La taille du tableau est égale au nombre de clés dans la commande. Chaque élément du tableau est complété par (a) le JSON sérialisé tel que localisé par le chemin ou (b) une valeur nulle si la clé n'existe pas, le chemin n'existe pas dans le document, ou le chemin est invalide (erreur de syntaxe).
+ Si l'une des clés spécifiées existe et n'est pas une clé JSON, la commande renvoie l'erreur `WRONGTYPE`.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021"}}'
OK
127.0.0.1:6379> JSON.SET k2 . '{"address":{"street":"5 main Street","city":"Boston","state":"MA","zipcode":"02101"}}'
OK
127.0.0.1:6379> JSON.SET k3 . '{"address":{"street":"100 Park Ave","city":"Seattle","state":"WA","zipcode":"98102"}}'
OK
127.0.0.1:6379> JSON.MGET k1 k2 k3 $.address.city
1) "[\"New York\"]"
2) "[\"Boston\"]"
3) "[\"Seattle\"]"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021"}}'
OK
127.0.0.1:6379> JSON.SET k2 . '{"address":{"street":"5 main Street","city":"Boston","state":"MA","zipcode":"02101"}}'
OK
127.0.0.1:6379> JSON.SET k3 . '{"address":{"street":"100 Park Ave","city":"Seattle","state":"WA","zipcode":"98102"}}'
OK
127.0.0.1:6379> JSON.MGET k1 k2 k3 .address.city
1) "\"New York\""
2) "\"Seattle\""
3) "\"Seattle\""
```
# JSON.MSET
Pris en charge pour Valkey version 8.1 et versions ultérieures.
Définissez des valeurs JSON pour plusieurs clés. L'opération est atomique. Toutes les valeurs sont définies ou aucune n'est définie.
**Syntaxe**
```
JSON.MSET key path json [ key path json ... ]
```
+ Si le chemin fait appel à un membre d'objet :
+ Si l'élément parent n'existe pas, la commande renvoie une erreur NON EXISTANTE.
+ Si l'élément parent existe mais n'est pas un objet, la commande renvoie ERROR.
+ Si l'élément parent existe et est un objet :
+ Si l'élément n'existe pas, un nouvel élément sera ajouté à l'objet parent si et seulement si l'objet parent est le dernier enfant dans le chemin. Sinon, la commande renverra une erreur INEXISTANTE.
+ Si le membre existe, sa valeur sera remplacée par la valeur JSON.
+ Si le chemin fait appel à un index de tableau :
+ Si l'élément parent n'existe pas, la commande renvoie une erreur INEXISTANTE.
+ Si l'élément parent existe mais qu'il ne s'agit pas d'un tableau, la commande renvoie ERROR.
+ Si l'élément parent existe mais que l'index est hors limites, la commande renvoie l'erreur OUTOFBOUNDARIES.
+ Si l'élément parent existe et que l'index est valide, l'élément sera remplacé par la nouvelle valeur JSON.
+ Si le chemin fait appel à un objet ou à un tableau, la valeur (objet ou tableau) sera remplacée par la nouvelle valeur JSON.
**Retour**
+ Réponse sous forme de chaîne simple : « OK » si l'opération a réussi.
+ Réponse d'erreur simple : si l'opération a échoué.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.MSET k1 . '[1,2,3,4,5]' k2 . '{"a":{"a":1, "b":2, "c":3}}' k3 . '{"a": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.GET k1
"[1,2,3,4,5]"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.MSET k2 $.a.* '0' k3 $.a[*] '0'
OK
127.0.0.1:6379> JSON.GET k2
"{\"a\":{\"a\":0,\"b\":0,\"c\":0}}"
127.0.0.1:6379> JSON.GET k3
"{\"a\":[0,0,0,0,0]}"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.MSET k1 . '{"name": "John","address": {"street": "123 Main St","city": "Springfield"},"phones": ["555-1234","555-5678"]}'
OK
127.0.0.1:6379> JSON.MSET k1 .address.street '"21 2nd Street"' k1 .address.city '"New York"'
OK
127.0.0.1:6379> JSON.GET k1 .address.street
"\"21 2nd Street\""
127.0.0.1:6379> JSON.GET k1 .address.city
"\"New York\""
```
# JSON.NUMINCRBY
Incrémente les valeurs numériques au niveau du chemin d'un nombre donné.
Syntaxe
```
JSON.NUMINCRBY
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (obligatoire) : chemin JSON.
+ number (obligatoire) : nombre.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau de chaînes en bloc qui représente la valeur résultante au niveau de chaque chemin.
+ Si une valeur n'est pas un nombre, sa valeur de retour correspondante est nulle.
+ Erreur `WRONGTYPE` si le nombre ne peut pas être analysé.
+ Erreur `OVERFLOW` si le résultat est hors de la plage des doubles IEEE 64 bits.
+ `NONEXISTENT` si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Chaîne en bloc qui représente la valeur résultante.
+ Si plusieurs valeurs sont sélectionnées, la commande renvoie le résultat de la dernière valeur mise à jour.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un nombre.
+ Erreur `WRONGTYPE` si le nombre ne peut pas être analysé.
+ Erreur `OVERFLOW` si le résultat est hors de la plage des doubles IEEE 64 bits.
+ `NONEXISTENT` si la clé du document n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 $.d[*] 10
"[11,12,13]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[11,12,13]}"
127.0.0.1:6379> JSON.SET k1 $ '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 $.a[*] 1
"[]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.b[*] 1
"[2]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.c[*] 1
"[2,3]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.d[*] 1
"[2,3,4]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[2,3,4]}"
127.0.0.1:6379> JSON.SET k2 $ '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k2 $.a.* 1
"[]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.b.* 1
"[2]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.c.* 1
"[2,3]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.d.* 1
"[2,3,4]"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":2,\"b\":3,\"c\":4}}"
127.0.0.1:6379> JSON.SET k3 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k3 $.a.* 1
"[null]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.b.* 1
"[null,2]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.c.* 1
"[null,null]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.d.* 1
"[2,null,4]"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":2,\"b\":\"b\",\"c\":4}}"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 .d[1] 10
"12"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[1,12,3]}"
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 .a[*] 1
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMINCRBY k1 .b[*] 1
"2"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[1,2],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMINCRBY k1 .c[*] 1
"3"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMINCRBY k1 .d[*] 1
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[2,3,4]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k2 .a.* 1
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMINCRBY k2 .b.* 1
"2"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":1,\"b\":2},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMINCRBY k2 .c.* 1
"3"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMINCRBY k2 .d.* 1
"4"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":2,\"b\":3,\"c\":4}}"
127.0.0.1:6379> JSON.SET k3 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k3 .a.* 1
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMINCRBY k3 .b.* 1
"2"
127.0.0.1:6379> JSON.NUMINCRBY k3 .c.* 1
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMINCRBY k3 .d.* 1
"4"
```
# JSON.NUMMULTBY
Multiplie les valeurs numériques au niveau du chemin par un nombre donné.
Syntaxe
```
JSON.NUMMULTBY
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (obligatoire) : chemin JSON.
+ number (obligatoire) : nombre.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau de chaînes en bloc qui représentent la valeur résultante au niveau de chaque chemin.
+ Si une valeur n'est pas un nombre, sa valeur de retour correspondante est nulle.
+ Erreur `WRONGTYPE` si le nombre ne peut pas être analysé.
+ Erreur `OVERFLOW` si le résultat est hors de la plage d'un nombre à virgule flottante IEEE à double précision de 64 bits.
+ `NONEXISTENT` si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Chaîne en bloc qui représente la valeur résultante.
+ Si plusieurs valeurs sont sélectionnées, la commande renvoie le résultat de la dernière valeur mise à jour.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas un nombre.
+ Erreur `WRONGTYPE` si le nombre ne peut pas être analysé.
+ Erreur `OVERFLOW` si le résultat est en dehors de la plage d'un double IEEE de 64 bits.
+ `NONEXISTENT` si la clé du document n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 $.d[*] 2
"[2,4,6]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[2,4,6]}"
127.0.0.1:6379> JSON.SET k1 $ '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 $.a[*] 2
"[]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.b[*] 2
"[2]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.c[*] 2
"[2,4]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.d[*] 2
"[2,4,6]"
127.0.0.1:6379> JSON.SET k2 $ '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k2 $.a.* 2
"[]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.b.* 2
"[2]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.c.* 2
"[2,4]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.d.* 2
"[2,4,6]"
127.0.0.1:6379> JSON.SET k3 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k3 $.a.* 2
"[null]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.b.* 2
"[null,2]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.c.* 2
"[null,null]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.d.* 2
"[2,null,6]"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 .d[1] 2
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[1,4,3]}"
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 .a[*] 2
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMMULTBY k1 .b[*] 2
"2"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[1,2],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMMULTBY k1 .c[*] 2
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,4],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMMULTBY k1 .d[*] 2
"6"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,4],\"d\":[2,4,6]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k2 .a.* 2
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMMULTBY k2 .b.* 2
"2"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":1,\"b\":2},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k2 .c.* 2
"4"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":4},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k2 .d.* 2
"6"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":4},\"d\":{\"a\":2,\"b\":4,\"c\":6}}"
127.0.0.1:6379> JSON.SET k3 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k3 .a.* 2
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMMULTBY k3 .b.* 2
"2"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":1,\"b\":\"b\",\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k3 .c.* 2
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMMULTBY k3 .d.* 2
"6"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":2,\"b\":\"b\",\"c\":6}}"
```
# JSON.OBJLEN
Obtient le nombre de clés dans les valeurs de l'objet au niveau du chemin.
Syntaxe
```
JSON.OBJLEN [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers qui représentent la longueur de l'objet au niveau de chaque chemin.
+ Si une valeur n'est pas un objet, sa valeur de retour correspondante est nulle.
+ Valeur nulle si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Entier, nombre de clés dans l'objet.
+ Si plusieurs objets sont sélectionnés, la commande renvoie la longueur du premier objet.
+ Erreur `WRONGTYPE` si la valeur au chemin n'est pas un objet.
+ Erreur `NONEXISTENT JSON` si le chemin n'existe pas.
+ Valeur nulle si la clé du document n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJLEN k1 $.a
1) (integer) 0
127.0.0.1:6379> JSON.OBJLEN k1 $.a.*
(empty array)
127.0.0.1:6379> JSON.OBJLEN k1 $.b
1) (integer) 1
127.0.0.1:6379> JSON.OBJLEN k1 $.b.*
1) (nil)
127.0.0.1:6379> JSON.OBJLEN k1 $.c
1) (integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 $.c.*
1) (nil)
2) (nil)
127.0.0.1:6379> JSON.OBJLEN k1 $.d
1) (integer) 3
127.0.0.1:6379> JSON.OBJLEN k1 $.d.*
1) (nil)
2) (nil)
3) (integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 $.*
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 3
5) (nil)
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJLEN k1 .a
(integer) 0
127.0.0.1:6379> JSON.OBJLEN k1 .a.*
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.OBJLEN k1 .b
(integer) 1
127.0.0.1:6379> JSON.OBJLEN k1 .b.*
(error) WRONGTYPE JSON element is not an object
127.0.0.1:6379> JSON.OBJLEN k1 .c
(integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 .c.*
(error) WRONGTYPE JSON element is not an object
127.0.0.1:6379> JSON.OBJLEN k1 .d
(integer) 3
127.0.0.1:6379> JSON.OBJLEN k1 .d.*
(integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 .*
(integer) 0
```
# JSON.OBJKEYS
Obtient les noms des clés dans les valeurs de l'objet au niveau du chemin.
Syntaxe
```
JSON.OBJKEYS [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau de tableaux de chaînes en bloc. Chaque élément est un tableau de clés dans un objet correspondant.
+ Si une valeur n'est pas un objet, sa valeur de retour correspondante est une valeur vide.
+ Valeur nulle si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Tableau de chaînes en bloc. Chaque élément est un nom de clé dans l'objet.
+ Si plusieurs objets sont sélectionnés, la commande renvoie les clés du premier objet.
+ Erreur `WRONGTYPE` si la valeur au chemin n'est pas un objet.
+ Valeur nulle si la clé du document n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJKEYS k1 $.*
1) (empty array)
2) 1) "a"
3) 1) "a"
2) "b"
4) 1) "a"
2) "b"
3) "c"
5) (empty array)
127.0.0.1:6379> JSON.OBJKEYS k1 $.d
1) 1) "a"
2) "b"
3) "c"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJKEYS k1 .*
1) "a"
127.0.0.1:6379> JSON.OBJKEYS k1 .d
1) "a"
2) "b"
3) "c"
```
# JSON.RESP
Renvoie la valeur JSON au chemin donné dans le protocole de sérialisation Valkey ou Redis OSS (RESP). Si la valeur est un conteneur, la réponse est un tableau RESP ou un tableau imbriqué.
+ La valeur nulle de JSON est mappée à Null Bulk String de RESP.
+ Les valeurs booléennes de JSON sont mappées aux chaînes simples respectives de RESP.
+ Les nombres entiers sont mappés aux entiers de RESP.
+ Les nombres à virgule flottante double IEEE de 64 bits sont mappés aux chaînes en bloc de RESP.
+ Les chaînes JSON sont mappées aux chaînes en bloc de RESP.
+ Les tableaux JSON sont représentés comme des tableaux RESP, où le premier élément est la chaîne simple [, suivie des éléments du tableau.
+ Les objets JSON sont représentés comme des tableaux RESP, où le premier élément est la simple chaîne \$1, suivie des paires clé-valeur, chacune d'entre elles étant une chaîne en bloc de RESP.
Syntaxe
```
JSON.RESP [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau de tableaux. Chaque élément du tableau représente la forme RESP de la valeur au niveau d'un chemin.
+ Tableau vide si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Tableau qui représente la forme RESP de la valeur au niveau du chemin.
+ Valeur nulle si la clé du document n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.RESP k1 $.address
1) 1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
127.0.0.1:6379> JSON.RESP k1 $.address.*
1) "21 2nd Street"
2) "New York"
3) "NY"
4) "10021-3100"
127.0.0.1:6379> JSON.RESP k1 $.phoneNumbers
1) 1) [
2) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "555 555-1234"
3) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
127.0.0.1:6379> JSON.RESP k1 $.phoneNumbers[*]
1) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "212 555-1234"
2) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.RESP k1 .address
1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
127.0.0.1:6379> JSON.RESP k1
1) {
2) 1) "firstName"
2) "John"
3) 1) "lastName"
2) "Smith"
4) 1) "age"
2) (integer) 27
5) 1) "weight"
2) "135.25"
6) 1) "isAlive"
2) true
7) 1) "address"
2) 1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
8) 1) "phoneNumbers"
2) 1) [
2) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "212 555-1234"
3) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
9) 1) "children"
2) 1) [
10) 1) "spouse"
2) (nil)
```
# JSON.SET
Définit les valeurs JSON au niveau du chemin.
Si le chemin fait appel à un membre d'objet :
+ Si l'élément parent n'existe pas, la commande renvoie une erreur NONEXISTENT.
+ Si l'élément parent existe, mais n'est pas un objet, la commande renvoie une erreur ERROR.
+ Si l'élément parent existe et est un objet :
+ Si l'élément n'existe pas, un nouvel élément sera ajouté à l'objet parent si et seulement si l'objet parent est le dernier enfant dans le chemin. Sinon, la commande renvoie une erreur NONEXISTENT.
+ Si le membre existe, sa valeur sera remplacée par la valeur JSON.
Si le chemin fait appel à un index de tableau :
+ Si l'élément parent n'existe pas, la commande renvoie une erreur NONEXISTENT.
+ Si l'élément parent existe mais n'est pas un tableau, la commande renvoie ERROR.
+ Si l'élément parent existe, mais que l'index est hors limites, la commande renvoie une erreur OUTOFBOUNDARIES.
+ Si l'élément parent existe et que l'index est valide, l'élément sera remplacé par la nouvelle valeur JSON.
Si le chemin fait appel à un objet ou à un tableau, la valeur (objet ou tableau) sera remplacée par la nouvelle valeur JSON.
Syntaxe
```
JSON.SET [NX | XX]
```
[NX \$1 XX] Où vous pouvez avoir 0 ou 1 des identifiants [NX \$1 XX].
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (obligatoire) : chemin JSON. Pour une nouvelle clé, le chemin JSON doit être la racine «. ».
+ NX (facultatif) — Si le chemin est la racine, définissez la valeur uniquement si la clé n'existe pas. C'est-à-dire, insérer un nouveau document. Si le chemin n'est pas la racine, définir la valeur uniquement si le chemin n'existe pas. C'est-à-dire, insérer une valeur dans le document.
+ XX (facultatif) — Si le chemin est la racine, définissez la valeur uniquement si la clé existe. C'est-à-dire, remplacer le document existant. Si le chemin n'est pas la racine, définir la valeur uniquement si le chemin existe. C'est-à-dire, mettre à jour la valeur existante.
**Retour**
+ Simple String « OK » en cas de succès.
+ Valeur nulle si la condition NX ou XX n'est pas remplie.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.SET k1 $.a.* '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"a\":{\"a\":0,\"b\":0,\"c\":0}}"
127.0.0.1:6379> JSON.SET k2 . '{"a": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.SET k2 $.a[*] '0'
OK
127.0.0.1:6379> JSON.GET k2
"{\"a\":[0,0,0,0,0]}"
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"c":{"a":1, "b":2}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.SET k1 .c.a '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"c\":{\"a\":0,\"b\":2},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.SET k1 .e[-1] '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"c\":{\"a\":0,\"b\":2},\"e\":[1,2,3,4,0]}"
127.0.0.1:6379> JSON.SET k1 .e[5] '0'
(error) OUTOFBOUNDARIES Array index is out of bounds
```
# JSON.STRAPPEND
Ajoute une chaîne aux chaînes JSON au niveau du chemin.
Syntaxe
```
JSON.STRAPPEND [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
+ json\$1string (obligatoire) – La représentation JSON d'une chaîne. Notez qu'une chaîne JSON doit être entre guillemets. Par exemple : « "exemple de chaîne" ».
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers qui représentent la nouvelle longueur de la chaîne au niveau de chaque chemin.
+ Si une valeur au niveau du chemin n'est pas une chaîne, sa valeur de retour correspondante est nulle.
+ Erreur `SYNTAXERR` si l'argument json en entrée n'est pas une chaîne JSON valide.
+ Erreur `NONEXISTENT` si le chemin n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Entier, la nouvelle longueur de la chaîne.
+ Si plusieurs valeurs de chaîne sont sélectionnées, la commande renvoie la nouvelle longueur de la dernière chaîne mise à jour.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas une chaîne.
+ Erreur `WRONGTYPE` si l'argument json en entrée n'est pas une chaîne JSON valide.
+ Erreur `NONEXISTENT` si le chemin n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRAPPEND k1 $.a.a '"a"'
1) (integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 $.a.* '"a"'
1) (integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 $.b.* '"a"'
1) (integer) 2
2) (nil)
127.0.0.1:6379> JSON.STRAPPEND k1 $.c.* '"a"'
1) (integer) 2
2) (integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 $.c.b '"a"'
1) (integer) 4
127.0.0.1:6379> JSON.STRAPPEND k1 $.d.* '"a"'
1) (nil)
2) (integer) 2
3) (nil)
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRAPPEND k1 .a.a '"a"'
(integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 .a.* '"a"'
(integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 .b.* '"a"'
(integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 .c.* '"a"'
(integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 .c.b '"a"'
(integer) 4
127.0.0.1:6379> JSON.STRAPPEND k1 .d.* '"a"'
(integer) 2
```
# JSON.STRLEN
Obtient les longueurs des valeurs de chaîne JSON au niveau du chemin.
Syntaxe
```
JSON.STRLEN [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers qui représente la longueur de la valeur de la chaîne au niveau de chaque chemin.
+ Si une valeur n'est pas une chaîne, sa valeur de retour correspondante est nulle.
+ Valeur nulle si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Entier, la longueur de la chaîne.
+ Si plusieurs valeurs de chaîne sont sélectionnées, la commande renvoie la longueur de la première chaîne.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas une chaîne.
+ Erreur `NONEXISTENT` si le chemin n'existe pas.
+ Valeur nulle si la clé du document n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRLEN k1 $.a.a
1) (integer) 1
127.0.0.1:6379> JSON.STRLEN k1 $.a.*
1) (integer) 1
127.0.0.1:6379> JSON.STRLEN k1 $.c.*
1) (integer) 1
2) (integer) 2
127.0.0.1:6379> JSON.STRLEN k1 $.c.b
1) (integer) 2
127.0.0.1:6379> JSON.STRLEN k1 $.d.*
1) (nil)
2) (integer) 1
3) (nil)
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRLEN k1 .a.a
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .a.*
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .c.*
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .c.b
(integer) 2
127.0.0.1:6379> JSON.STRLEN k1 .d.*
(integer) 1
```
# JSON.TOGGLE
Fait basculer les valeurs booléennes entre vrai et faux au niveau du chemin.
Syntaxe
```
JSON.TOGGLE [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau d'entiers (0 - faux, 1 - vrai) qui représentent la valeur booléenne résultante au niveau de chaque chemin.
+ Si une valeur n'est pas une valeur booléenne, sa valeur de retour correspondante est nulle.
+ `NONEXISTENT` si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Chaîne (« vrai »/« faux ») qui représente la valeur booléenne résultante.
+ `NONEXISTENT` si la clé du document n'existe pas.
+ Erreur `WRONGTYPE` si la valeur au niveau du chemin n'est pas une valeur booléenne.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '{"a":true, "b":false, "c":1, "d":null, "e":"foo", "f":[], "g":{}}'
OK
127.0.0.1:6379> JSON.TOGGLE k1 $.*
1) (integer) 0
2) (integer) 1
3) (nil)
4) (nil)
5) (nil)
6) (nil)
7) (nil)
127.0.0.1:6379> JSON.TOGGLE k1 $.*
1) (integer) 1
2) (integer) 0
3) (nil)
4) (nil)
5) (nil)
6) (nil)
7) (nil)
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . true
OK
127.0.0.1:6379> JSON.TOGGLE k1
"false"
127.0.0.1:6379> JSON.TOGGLE k1
"true"
127.0.0.1:6379> JSON.SET k2 . '{"isAvailable": false}'
OK
127.0.0.1:6379> JSON.TOGGLE k2 .isAvailable
"true"
127.0.0.1:6379> JSON.TOGGLE k2 .isAvailable
"false"
```
# JSON.TYPE
Rapporte le type de valeurs au niveau du chemin donné.
Syntaxe
```
JSON.TYPE [path]
```
+ clé (obligatoire) — Une clé Valkey ou Redis OSS de type document JSON.
+ path (facultatif) : chemin JSON. Par défaut, il s'agit de la racine si elle n'est pas fournie.
**Retour**
Si le chemin est une syntaxe améliorée :
+ Tableau de chaînes de caractères qui représentent le type de valeur au niveau de chaque chemin. Le type est l'un de \$1"null", "boolean", "string", "number", "integer", "object" et "array"\$1.
+ Si un chemin n'existe pas, sa valeur de retour correspondante est nulle.
+ Tableau vide si la clé du document n'existe pas.
Si le chemin est une syntaxe restreinte :
+ Chaîne, type de la valeur
+ Valeur nulle si la clé du document n'existe pas.
+ Valeur nulle si le chemin JSON n'est pas valide ou n'existe pas.
**Exemples**
Syntaxe de chemin améliorée :
```
127.0.0.1:6379> JSON.SET k1 . '[1, 2.3, "foo", true, null, {}, []]'
OK
127.0.0.1:6379> JSON.TYPE k1 $[*]
1) integer
2) number
3) string
4) boolean
5) null
6) object
7) array
```
Syntaxe de chemin restreinte :
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.TYPE k1
object
127.0.0.1:6379> JSON.TYPE k1 .children
array
127.0.0.1:6379> JSON.TYPE k1 .firstName
string
127.0.0.1:6379> JSON.TYPE k1 .age
integer
127.0.0.1:6379> JSON.TYPE k1 .weight
number
127.0.0.1:6379> JSON.TYPE k1 .isAlive
boolean
127.0.0.1:6379> JSON.TYPE k1 .spouse
null
```
# Marquer vos ressources ElastiCache
Pour vous aider à gérer vos clusters et autres ElastiCache ressources, vous pouvez attribuer vos propres métadonnées à chaque ressource sous forme de balises. Les balises vous permettent de classer vos AWS ressources de différentes manières, par exemple par objectif, propriétaire ou environnement. Cette approche est utile lorsque vous avez de nombreuses ressources de même type. Elle vous permet d’identifier rapidement une ressource spécifique en fonction des balises que vous lui avez attribuées. Cette rubrique décrit les balises et vous montre comment les créer.
**Avertissement**
Nous vous recommandons de ne pas inclure de données sensibles dans vos balises.
## Principes de base des étiquettes
Une étiquette est une étiquette que vous attribuez à une AWS ressource. Chaque balise est constituée d’une clé et d’une valeur facultative que vous définissez. Les balises vous permettent de classer vos AWS ressources de différentes manières, par exemple par objectif ou par propriétaire. Par exemple, vous pouvez définir un ensemble de balises pour les ElastiCache clusters de votre compte afin de suivre le propriétaire et le groupe d'utilisateurs de chaque instance.
Nous vous recommandons de concevoir un ensemble de clés d’étiquette répondant à vos besoins pour chaque type de ressource. L’utilisation d’un ensemble de clés de balise cohérent facilite la gestion de vos ressources. Vous pouvez rechercher et filtrer les ressources en fonction des balises que vous ajoutez. Pour plus d'informations sur la mise en œuvre d'une stratégie efficace de balisage des ressources, consultez [Le livre blanc AWS sur les bonnes pratiques en matière d'identification](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf).
Les balises n'ont aucune signification sémantique ElastiCache et sont interprétées strictement comme des chaînes de caractères. De plus, les étiquettes ne sont pas automatiquement affectées à vos ressources. Vous pouvez modifier les clés et valeurs de balise, et vous pouvez retirer des balises d’une ressource à tout moment. Vous pouvez définir la valeur d'une balise à `null`. Si vous ajoutez une balise ayant la même clé qu’une balise existante sur cette ressource, la nouvelle valeur remplace l’ancienne valeur. Si vous supprimez une ressource, ses balises sont également supprimées. En outre, si vous ajoutez ou supprimez des balises sur un groupe de réplication, tous les nœuds de ce groupe de réplication verront également leurs balises ajoutées ou supprimées.
Vous pouvez travailler avec des balises à l'aide de l'API AWS Management ConsoleAWS CLI, du et de l' ElastiCache API.
Si vous utilisez IAM, vous pouvez contrôler quels utilisateurs de votre AWS compte sont autorisés à créer, modifier ou supprimer des tags. Pour de plus amples informations, veuillez consulter [Autorisations de niveau ressource](IAM.ResourceLevelPermissions.md).
## Ressources que vous pouvez étiqueter
Vous pouvez étiqueter la plupart ElastiCache des ressources qui existent déjà dans votre compte. Le tableau ci-dessous répertorie les ressources qui prennent en charge le balisage. Si vous utilisez le AWS Management Console, vous pouvez appliquer des balises aux ressources à l'aide de l'[éditeur de balises](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html). Certains écrans de ressources vous permettent de spécifier des balises pour une ressource lorsque vous la créez ; par exemple, une balise avec une clé de Nom et une valeur que vous spécifiez. Dans la plupart des cas, la console applique les balises immédiatement après la création de la ressource (plutôt qu’au cours de la création de ressources). La console peut organiser les ressources en fonction de la balise **Name**, mais cette balise n'a aucune signification sémantique pour le ElastiCache service.
En outre, certaines actions de création de ressources vous permettent de spécifier des balises pour une ressource lors de la création de cette dernière. Si les balises ne peuvent pas être appliquées au cours de la création de ressources, nous restaurons le processus de création de ressources. Cela permet de s’assurer que les ressources sont créées avec des balises ou qu’elles ne sont pas créées du tout, et qu’aucune ressource ne demeurent sans balise à tout moment. En attribuant des balises aux ressources au moment de la création, vous pouvez supprimer la nécessité d’exécuter des scriptes de balisage personnalisés après la création de ressources.
Si vous utilisez l' ElastiCache API Amazon, la AWS CLI ou un AWS SDK, vous pouvez utiliser le `Tags` paramètre de l'action d' ElastiCache API correspondante pour appliquer des balises. Il s'agit des options suivantes :
+ `CreateServerlessCache`
+ `CreateCacheCluster`
+ `CreateReplicationGroup`
+ `CopyServerlessCacheSnapshot`
+ `CopySnapshot`
+ `CreateCacheParameterGroup`
+ `CreateCacheSecurityGroup`
+ `CreateCacheSubnetGroup`
+ `CreateServerlessCacheSnapshot`
+ `CreateSnapshot`
+ `CreateUserGroup`
+ `CreateUser`
+ `PurchaseReservedCacheNodesOffering`
Le tableau suivant décrit les ElastiCache ressources qui peuvent être balisées et les ressources qui peuvent être balisées lors de la création à l'aide de l' ElastiCache API, de la AWS CLI ou d'un AWS SDK.
**Support de balisage pour les ressources ElastiCache**
| Ressource | Prend en charge les balises | Prend en charge le balisage au moment de la création |
| --- | --- | --- |
| serverlesscache | Oui | Oui |
| parametergroup | Oui | Oui |
| securitygroup | Oui | Oui |
| subnetgroup | Oui | Oui |
| replicationgroup | Oui | Oui |
| cluster | Oui | Oui |
| reserved-instance | Oui | Oui |
| serverlesscachesnapshot | Oui | Oui |
| instantané | Oui | Oui |
| user | Oui | Oui |
| usergroup | Oui | Oui |
**Note**
Vous ne pouvez pas étiqueter les entrepôts de données globaux.
Vous pouvez appliquer des autorisations au niveau des ressources basées sur des balises dans vos politiques IAM aux actions d' ElastiCache API qui prennent en charge le balisage lors de la création afin de mettre en œuvre un contrôle granulaire sur les utilisateurs et les groupes qui peuvent étiqueter les ressources lors de la création. Vos ressources sont correctement sécurisées depuis la création. Les balises sont appliquées immédiatement à vos ressources. Les autorisations de niveau ressource basées sur des balises sont donc effectives immédiatement. Vos ressources peuvent être suivies et signalées avec plus de précision. Vous pouvez appliquer l’utilisation du balisage sur les nouvelles ressources et contrôler que les clés et valeurs de balise sont définies sur vos ressources.
Pour de plus amples informations, veuillez consulter [Exemple : étiquetage de vos ressources](#Tagging-your-resources-example).
Pour plus d'informations sur l'étiquetage de vos ressources pour la facturation, veuillez consulter [Surveillance des coûts avec des balises de répartition des coûts](Tagging.md).
## Balisage des caches et des instantanés
Les règles suivantes s'appliquent à l'étiquetage dans le cadre d'opérations de requête :
+ **CreateReplicationGroup**:
+ Si les `--tags` paramètres `--primary-cluster-id` et sont inclus dans la demande, les balises de demande seront ajoutées au groupe de réplication et propagées à tous les clusters du groupe de réplication. Si le cluster principal possède des balises existantes, celles-ci seront remplacées par les balises de demande afin d'avoir des balises cohérentes sur tous les nœuds.
En l'absence de balises de requête, les balises de cluster principales seront ajoutées au groupe de réplication et propagées à tous les clusters.
+ Si `--snapshot-name` ou `--serverless-cache-snapshot-name` est fourni :
Si des balises sont incluses dans la demande, le groupe de réplication sera étiqueté uniquement avec ces balises. Si aucune balise n’est incluse dans la demande, les balises de l’instantané seront ajoutées au groupe de réplication.
+ Si `--global-replication-group-id` est fourni :
Si des balises sont incluses dans la demande, elles seront ajoutées au groupe de réplication et propagées à tous les clusters.
+ **CreateCacheCluster** :
+ Si `--replication-group-id` est fourni :
Si des balises sont incluses dans la demande, le cluster ne sera étiqueté qu'avec ces balises. Si aucune balise n'est incluse dans la demande, le cluster héritera des balises du groupe de réplication au lieu des balises du cluster principal.
+ Si `--snapshot-name` est fourni :
Si des balises sont incluses dans la demande, le cluster ne sera étiqueté qu'avec ces balises. Si aucune balise n'est incluse dans la demande, les balises de capture d'écran seront ajoutées au cluster.
+ **CreateServerlessCache** :
+ Si des balises sont incluses dans la demande, seules les balises de la demande seront ajoutées au cache sans serveur.
+ **CreateSnapshot** :
+ Si `--replication-group-id` est fourni :
Si des balises sont incluses dans la requête, seules les balises de requête seront ajoutées à l'instantané. Si aucune balise n'est incluse dans la requête, les balises du groupe de réplication sont ajoutées à l'instantané.
+ Si `--cache-cluster-id` est fourni :
Si des balises sont incluses dans la requête, seules les balises de requête seront ajoutées à l'instantané. Si aucune balise n'est incluse dans la demande, les balises de cluster seront ajoutées à l'instantané.
+ Pour les instantanés automatiques :
Les balises se propagent à partir des balises du groupe de réplication.
+ **CreateServerlessCacheSnapshot** :
+ Si des balises sont incluses dans la demande, seules les balises de la demande seront ajoutées à l’instantané du cache sans serveur.
+ **CopySnapshot** :
+ Si des balises sont incluses dans la requête, seules les balises de requête seront ajoutées à l'instantané. Si aucune balise n'est incluse dans la requête, les balises d'instantané source sont ajoutées à l'instantané copié.
+ **CopyServerlessCacheSnapshot** :
+ Si des balises sont incluses dans la demande, seules les balises de la demande seront ajoutées à l’instantané du cache sans serveur.
+ **AddTagsToResource**et **RemoveTagsFromResource**:
+ Les balises added/removed proviendront du groupe de réplication et l'action sera propagée à tous les clusters du groupe de réplication.
**Note**
**AddTagsToResource**et **RemoveTagsFromResource**ne peut pas être utilisé pour les paramètres par défaut et les groupes de sécurité.
+ **IncreaseReplicaCount**et **ModifyReplicationGroupShardConfiguration**:
+ Tous les nouveaux clusters ajoutés au groupe de réplication auront les mêmes balises que le groupe de réplication.
## Restrictions liées aux étiquettes
Les restrictions de base suivantes s’appliquent aux balises :
+ Nombre maximal de balises par ressource : 50
+ Pour chaque ressource, chaque clé d'identification doit être unique, et chaque clé d'identification peut avoir une seule valeur.
+ Longueur de clé maximale : 128 caractères Unicode en UTF-8.
+ Longueur de valeur maximale : 256 caractères Unicode en UTF-8.
+ Bien qu'il ElastiCache autorise n'importe quel caractère dans ses balises, d'autres services peuvent être restrictifs. Les caractères autorisés pour les services sont les lettres, les chiffres et les espaces représentables en UTF-8, ainsi que les caractères suivants : \$1 - = . \$1 : / @
+ Les clés et valeurs d’étiquette sont sensibles à la casse.
+ Le `aws:` préfixe est réservé à l'AWS usage. Lorsque la balise possède une clé de balise avec ce préfixe, vous ne pouvez pas modifier ou supprimer sa clé ou sa valeur. Les balises avec le préfixe `aws:` ne sont pas comptabilisées comme vos balises pour la limite de ressources.
Vous ne pouvez pas mettre fin à une ressource, ou l’arrêter ou la supprimer uniquement en fonction de ses balises ; vous devez spécifier l’identificateur de ressource. Par exemple, pour supprimer des instantanés (snapshot) que vous avez balisés avec une clé de balise appelée `DeleteMe`, vous devez utiliser l’action `DeleteSnapshot` avec les identificateurs de ressource des instantanés, tels que `snap-1234567890abcdef0`.
Pour plus d'informations sur les ElastiCache ressources que vous pouvez baliser, consultez[Ressources que vous pouvez étiqueter](#Tagging-your-resources).
## Exemple : étiquetage de vos ressources
+ Création d'un cache sans serveur à l'aide de balises. Cet exemple utilise Memcached comme moteur.
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine memcached
--tags Key="Cost Center", Value="1110001" Key="project",Value="XYZ"
```
+ Ajout de balises à un cache sans serveur
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-east-1:111111222233:serverlesscache:my-cache \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Ajout de balises à un groupe de réplication.
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-east-1:111111222233:replicationgroup:my-rg \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Création d'un cluster de cache en utilisant des balises.
```
aws elasticache create-cache-cluster \
--cluster-id testing-tags \
--cluster-description cluster-test \
--cache-subnet-group-name test \
--cache-node-type cache.t2.micro \
--engine valkey \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Création d'un cluster de cache en utilisant des balises. Cet exemple utilise Redis comme moteur.
```
aws elasticache create-cache-cluster \
--cluster-id testing-tags \
--cluster-description cluster-test \
--cache-subnet-group-name test \
--cache-node-type cache.t2.micro \
--engine valkey \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Création d’un instantané sans serveur avec des balises. Cet exemple utilise Memcached comme moteur.
```
aws elasticache create-serverless-cache-snapshot \
--serverless-cache-name testing-tags \
--serverless-cache-snapshot-name bkp-testing-tags-scs \
--tags Key="work",Value="foo"
```
+ Création d'un instantané avec des balises.
Les instantanés ne sont actuellement disponibles que pour Redis. Dans ce cas, si vous ajoutez des balises sur demande, même si le groupe de réplication contient des balises, l'instantané recevra uniquement les balises demandées.
```
aws elasticache create-snapshot \
--replication-group-id testing-tags \
--snapshot-name bkp-testing-tags-rg \
--tags Key="work",Value="foo"
```
## Exemples de politique de contrôle d'accès basée sur des balises
1. Autoriser une action `AddTagsToResource` sur un cluster uniquement si le cluster contient la balise Project=XYZ.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ"
}
}
}
]
}
```
------
1. Autoriser une action `RemoveTagsFromResource` à partir d'un groupe de réplication s'il contient les balises Projet et Service et que les clés sont différentes de Project et Service.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:RemoveTagsFromResource",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Service": "Elasticache",
"aws:ResourceTag/Project": "XYZ"
},
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Project",
"Service"
]
}
}
}
]
}
```
------
1. Autoriser `AddTagsToResource` à n'importe quelle ressource uniquement si les balises sont différentes de Project et Service.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:*:*"
],
"Condition": {
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Service",
"Project"
]
}
}
}
]
}
```
------
1. Refuser une action `CreateReplicationGroup` si la requête comporte `Tag Project=Foo`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CreateReplicationGroup",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "Foo"
}
}
}
]
}
```
------
1. Refuser une action `CopySnapshot` si l'instantané source contient la balise Project=XYZ et que la balise demandée est Service=ElastiCache.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CopySnapshot",
"Resource": [
"arn:aws:elasticache:*:*:snapshot:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ",
"aws:RequestTag/Service": "Elasticache"
}
}
}
]
}
```
------
1. Refus de l'action `CreateCacheCluster` si l'identification de la demande `Project` est manquante ou n'est pas égale à `Dev`, `QA` ou `Prod`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*",
"arn:aws:elasticache:*:*:securitygroup:*",
"arn:aws:elasticache:*:*:replicationgroup:*"
]
},
{
"Effect": "Deny",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"Null": {
"aws:RequestTag/Project": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:AddTagsToResource"
],
"Resource": "arn:aws:elasticache:*:*:cluster:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": [
"Dev",
"Prod",
"QA"
]
}
}
}
]
}
```
------
Pour obtenir des informations connexes sur les clés de condition, consultez [Utilisation de clés de condition](IAM.ConditionKeys.md).
# Surveillance des coûts avec des balises de répartition des coûts
Lorsque vous ajoutez des balises de répartition des coûts à vos ressources sur Amazon ElastiCache, vous pouvez suivre les coûts en regroupant les dépenses sur vos factures par valeur d'étiquette de ressource.
Une balise de répartition des ElastiCache coûts est une paire clé-valeur que vous définissez et associez à une ElastiCache ressource. Les clés et les valeurs sont sensibles à la casse. Vous pouvez utiliser une clé de balise pour définir une catégorie, et la valeur de balise peut être un élément de cette catégorie. Par exemple, vous pouvez définir une clé de balise appelée `CostCenter` et une valeur de balise appelée `10010`, en indiquant que la ressource est assignée au centre de coûts 10010. Vous pouvez également utiliser des balises pour désigner des ressources destinées aux tests ou à la production en utilisant une clé telle que `Environment` et des valeurs telles que `test` ou `production`. Pour faciliter le suivi des coûts associés à vos ressources, nous vous recommandons d'utiliser un ensemble de clés de balise cohérent.
Utilisez des balises de répartition des coûts pour organiser votre AWS facture afin de refléter votre propre structure de coûts. Pour ce faire, inscrivez-vous pour obtenir la facture de votre AWS compte avec les valeurs clés du tag incluses. Ensuite, pour voir le coût de vos ressources combinées, organisez vos informations de facturation en fonction des ressources possédant les mêmes valeurs de clé de balise. Par exemple, vous pouvez baliser plusieurs ressources avec un nom d’application spécifique, puis organiser vos informations de facturation pour afficher le coût total de cette application dans plusieurs services.
Vous pouvez également combiner des balises pour suivre les coûts plus détaillés. Par exemple, pour suivre vos coûts de service par région, vous pouvez utiliser les clés de balise `Service` et `Region`. Sur une seule ressource, vous pouvez avoir les valeurs `ElastiCache` et `Asia Pacific (Singapore)`, et sur une autre ressource, les valeurs `ElastiCache` et `Europe (Frankfurt)`. Vous pouvez ensuite voir vos ElastiCache coûts totaux ventilés par région. Pour plus d’informations, consultez [Utilisation des balises d’allocation des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) dans le *Guide de l’utilisateur AWS Billing*.
Vous pouvez ajouter des balises de répartition des ElastiCache coûts aux clusters ElastiCache basés sur des nœuds. Lorsque vous ajoutez, affichez, modifiez, copiez ou supprimez une balise, l'opération est appliquée uniquement au cluster spécifié.
**Caractéristiques des étiquettes de répartition des ElastiCache coûts**
+ Les balises de répartition des coûts sont appliquées aux ElastiCache ressources spécifiées dans les opérations de la CLI et de l'API sous forme d'ARN. Le type de ressource sera un « cluster ».
Exemple d'ARN : `arn:aws:elasticache::::`
Exemple d'ARN : `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
+ La clé de balise correspond au nom obligatoire de la balise. La valeur de la chaîne de caractères de la clé peut comporter de 1 à 128 caractères Unicode et ne peut pas être précédée de `aws:`. La chaîne peut uniquement contenir l'ensemble de lettres, de chiffres et d'espaces, de traits de soulignement ( \$1 ), de points ( . ), de deux-points ( : ), de barres obliques inverses ( \$1 ), de signes égal ( = ), de signes plus ( \$1 ), de tirets ( - ) ou d'arobases ( @ ).
+ La valeur de balise est la valeur facultative de la balise. La valeur de la chaîne de caractères de la chaîne peut comporter de 1 à 256 caractères Unicode, et ne peut pas être précédée de `aws:`. La chaîne peut uniquement contenir l'ensemble de lettres, de chiffres et d'espaces, de traits de soulignement ( \$1 ), de points ( . ), de deux-points ( : ), de barres obliques inverses ( \$1 ), de signes égal ( = ), de signes plus ( \$1 ), de tirets ( - ) ou d'arobases ( @ ).
+ Une ElastiCache ressource peut comporter un maximum de 50 balises.
+ Les valeurs comprises dans un ensemble de balises, ne doivent pas nécessairement être uniques. Par exemple, vous pouvez avoir une balise définie où les clés `Service` et `Application` ont, toutes deux, la valeur `ElastiCache`.
AWS n'applique aucune signification sémantique à vos balises. Les balises sont interprétées strictement comme des chaînes de caractères.AWS ne définit pas automatiquement de balises sur aucune ElastiCache ressource.
# Gérez vos étiquettes de répartition des coûts à l'aide du AWS CLI
Vous pouvez utiliser le AWS CLI pour ajouter, modifier ou supprimer des balises de répartition des coûts.
Les balises de répartition des coûts sont appliquées aux ElastiCache clusters. Le cluster à étiqueter est spécifié à l'aide d'un ARN (Amazon Resource Name).
Exemple d'ARN : `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Lister les tags à l'aide du AWS CLI](#Tagging.Managing.CLI.List)
+ [Ajout de balises à l'aide du AWS CLI](#Tagging.Managing.CLI.Add)
+ [Modification des balises à l'aide du AWS CLI](#Tagging.Managing.CLI.Modify)
+ [Suppression de balises à l'aide du AWS CLI](#Tagging.Managing.CLI.Remove)
## Lister les tags à l'aide du AWS CLI
Vous pouvez utiliser les balises AWS CLI pour lister une ElastiCache ressource existante en utilisant l'[list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html)opération.
Le code suivant utilise le AWS CLI pour répertorier les balises du cluster Memcached `my-cluster` dans la région us-west-2.
Pour Linux, macOS ou Unix :
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Pour Windows :
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Le code suivant utilise le AWS CLI pour répertorier les balises du nœud Valkey ou Redis OSS du `my-cluster` cluster `my-cluster-001` dans la région us-west-2.
Pour Linux, macOS ou Unix :
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
Pour Windows :
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
Le résultat de cette opération se présentera de la façon suivante, une liste de toutes les balises sur la ressource.
```
{
"TagList": [
{
"Value": "10110",
"Key": "CostCenter"
},
{
"Value": "EC2",
"Key": "Service"
}
]
}
```
S'il n'y a pas de balises sur la ressource, la sortie sera vide TagList.
```
{
"TagList": []
}
```
Pour plus d'informations, consultez le AWS CLI pour ElastiCache [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html).
## Ajout de balises à l'aide du AWS CLI
Vous pouvez utiliser le AWS CLI pour ajouter des balises à une ElastiCache ressource existante à l'aide de l'opération [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) CLI. Si la clé de balise n'existe pas sur la ressource, la clé et la valeur sont ajoutées à la ressource. Si la clé existe déjà sur la ressource, la valeur associée à cette clé est mise à jour en la nouvelle valeur.
Le code suivant utilise le AWS CLI pour ajouter les clés `Service` et `Region` avec les valeurs`elasticache`, `us-west-2` respectivement au nœud du cluster `my-cluster-001` `my-cluster` dans la région us-west-2.
**Memcached**
Pour Linux, macOS ou Unix :
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tags Key=Service,Value=elasticache \
Key=Region,Value=us-west-2
```
Pour Windows :
```
aws elasticache add-tags-to-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tags Key=Service,Value=elasticache ^
Key=Region,Value=us-west-2
```
**Redis**
Pour Linux, macOS ou Unix :
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tags Key=Service,Value=elasticache \
Key=Region,Value=us-west-2
```
Pour Windows :
```
aws elasticache add-tags-to-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tags Key=Service,Value=elasticache ^
Key=Region,Value=us-west-2
```
Le résultat de cette commande se présentera de la façon suivante, une liste de toutes les balises sur la ressource à la suite de l'opération.
```
{
"TagList": [
{
"Value": "elasticache",
"Key": "Service"
},
{
"Value": "us-west-2",
"Key": "Region"
}
]
}
```
Pour plus d'informations, consultez le AWS CLI pour ElastiCache [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html).
Vous pouvez également utiliser le AWS CLI pour ajouter des balises à un cluster lorsque vous créez un nouveau cluster à l'aide de cette opération[create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html). Vous ne pouvez pas ajouter de balises lors de la création d'un cluster à l'aide de la console ElastiCache de gestion. Une fois que le cluster est créé, vous pouvez utiliser ensuite la console pour ajouter des balises au cluster.
## Modification des balises à l'aide du AWS CLI
Vous pouvez utiliser le AWS CLI pour modifier les balises d'un ElastiCache cluster.
Pour modifier des balises :
+ Utilisez [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) pour ajouter une nouvelle balise et une valeur, ou pour modifier la valeur associée à une balise existante.
+ Utilisez [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html) pour supprimer des balises spécifiées de la ressource.
Le résultat de l'une ou l'autre de ces opérations sera une liste de toutes les balises et de leurs valeurs sur le cluster spécifié.
## Suppression de balises à l'aide du AWS CLI
Vous pouvez utiliser le AWS CLI pour supprimer les balises d'un cluster existant ElastiCache pour Memcached en utilisant l'[remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html)opération.
Pour Memcached, le code suivant utilise le AWS CLI pour supprimer les balises à l'aide des clés `Service` et `Region` du nœud du cluster `my-cluster-001` `my-cluster` dans la région us-west-2.
Pour Linux, macOS ou Unix :
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tag-keys PM Service
```
Pour Windows :
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tag-keys PM Service
```
Pour Redis OSS, le code suivant utilise le AWS CLI pour supprimer les balises à l'aide des clés `Service` et `Region` du nœud du cluster `my-cluster-001` `my-cluster` dans la région us-west-2.
Pour Linux, macOS ou Unix :
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tag-keys PM Service
```
Pour Windows :
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tag-keys PM Service
```
Le résultat de cette commande se présentera de la façon suivante, une liste de toutes les balises sur la ressource à la suite de l'opération.
```
{
"TagList": []
}
```
Pour plus d'informations, consultez le AWS CLI pour ElastiCache [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html).
# Gestion de vos balises de répartition des coûts à l'aide de l' ElastiCache API
Vous pouvez utiliser l' ElastiCache API pour ajouter, modifier ou supprimer des balises de répartition des coûts.
Les balises de répartition des coûts sont appliquées ElastiCache aux clusters Memcached. Le cluster à étiqueter est spécifié à l'aide d'un ARN (Amazon Resource Name).
Exemple d'ARN : `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Lister les tags à l'aide de l' ElastiCache API](#Tagging.Managing.API.List)
+ [Ajouter des tags à l'aide de l' ElastiCache API](#Tagging.Managing.API.Add)
+ [Modification des balises à l'aide de l' ElastiCache API](#Tagging.Managing.API.Modify)
+ [Supprimer des balises à l'aide de l' ElastiCache API](#Tagging.Managing.API.Remove)
## Lister les tags à l'aide de l' ElastiCache API
Vous pouvez utiliser l' ElastiCache API pour répertorier les balises d'une ressource existante à l'aide de l'[ListTagsForResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListTagsForResource.html)opération.
Pour Memcached, le code suivant utilise l' ElastiCache API pour répertorier les balises de la ressource `my-cluster` dans la région us-west-2.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListTagsForResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour Redis OSS, le code suivant utilise l' ElastiCache API pour répertorier les balises de la ressource `my-cluster-001` dans la région us-west-2.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListTagsForResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
## Ajouter des tags à l'aide de l' ElastiCache API
Vous pouvez utiliser l' ElastiCache API pour ajouter des balises à un ElastiCache cluster existant à l'aide de l'[AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html)opération. Si la clé de balise n'existe pas sur la ressource, la clé et la valeur sont ajoutées à la ressource. Si la clé existe déjà sur la ressource, la valeur associée à cette clé est mise à jour en la nouvelle valeur.
Le code suivant utilise l' ElastiCache API pour ajouter les clés `Service` et `Region` avec les valeurs`elasticache`, `us-west-2` respectivement. Pour Memcached, cela s'applique à la ressource. `my-cluster` Pour Redis OSS, cela s'applique à la ressource de la `my-cluster-001` région us-west-2.
**Memcached**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=AddTagsToResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Tags.member.1.Key=Service
&Tags.member.1.Value=elasticache
&Tags.member.2.Key=Region
&Tags.member.2.Value=us-west-2
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
**Redis**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=AddTagsToResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Tags.member.1.Key=Service
&Tags.member.1.Value=elasticache
&Tags.member.2.Key=Region
&Tags.member.2.Value=us-west-2
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Pour plus d'informations, consultez [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) le *Amazon ElastiCache API Reference*.
## Modification des balises à l'aide de l' ElastiCache API
Vous pouvez utiliser l' ElastiCache API pour modifier les balises d'un ElastiCache cluster.
Pour modifier la valeur d'une balise :
+ Utilisez l'opération [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) pour ajouter une nouvelle balise et une valeur, ou pour modifier la valeur d'une balise existante.
+ Utilisez [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) pour supprimer des balises de la ressource.
Le résultat de l'une ou l'autre de ces opérations sera une liste de toutes les balises et leurs valeurs sur la ressource spécifiée.
Utilisez [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) pour supprimer des balises de la ressource.
## Supprimer des balises à l'aide de l' ElastiCache API
Vous pouvez utiliser l' ElastiCache API pour supprimer des balises d'un cluster existant ElastiCache pour Memcached en utilisant l'[RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html)opération.
Le code suivant utilise l' ElastiCache API pour supprimer les balises à l'aide des clés `Service` et `Region` du nœud du cluster `my-cluster-001` `my-cluster` dans la région us-west-2.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=RemoveTagsFromResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&TagKeys.member.1=Service
&TagKeys.member.2=Region
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
# Utilisation de l'objectif Amazon ElastiCache Well-Architected
Cette section décrit l'Amazon ElastiCache Well-Architected Lens, un ensemble de principes de conception et de conseils pour concevoir des charges de travail bien architecturées. ElastiCache
+ The ElastiCache Lens est un additif au [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html).
+ Chaque pilier comporte une série de questions pour aider à lancer la discussion autour d'une ElastiCache architecture.
+ Chaque question présente un certain nombre de meilleures pratiques ainsi que leurs scores pour la création d’un rapport.
+ *Obligatoire* : nécessaire avant de passer en production (si absent, risque élevé)
+ *Meilleure pratique* : le meilleur état possible pour un client
+ *Bonne pratique* : ce que nous recommandons aux clients (si absent, risque modéré)
+ Terminologie Well-Architected
+ [Composant](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) : code, configuration et AWS ressources qui, ensemble, répondent à une exigence. Les composants interagissent avec d'autres composants et sont souvent assimilés à un service dans les architectures de microservices.
+ [Charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) : ensemble de composants qui, ensemble, apportent de la valeur à l'entreprise. Des exemples de charges de travail sont les sites Web marketing, les sites Web d'e-commerce, les systèmes back-end pour une application mobile, les plateformes d'analyse, etc.
**Note**
Ce guide n'a pas été mis à jour pour inclure des informations sur la mise en cache ElastiCache sans serveur et le nouveau moteur Valkey.
**Topics**
+ [Pilier d'excellence opérationnelle d'Amazon ElastiCache Well-Architected Lens](OperationalExcellencePillar.md)
+ [Pilier de ElastiCache sécurité Amazon Well-Architected Lens](SecurityPillar.md)
+ [Pilier de fiabilité des objectifs Amazon ElastiCache Well-Architected](ReliabilityPillar.md)
+ [Pilier d'efficacité des ElastiCache performances des objectifs Amazon Well-Architected](PerformanceEfficiencyPillar.md)
+ [Pilier d'optimisation des ElastiCache coûts d'objectif Amazon Well-Architected](CostOptimizationPillar.md)
# Pilier d'excellence opérationnelle d'Amazon ElastiCache Well-Architected Lens
Le pilier d'excellence opérationnelle se concentre sur l'exécution et la surveillance des systèmes afin de générer de la valeur opérationnelle, ainsi que sur l'amélioration continue des processus et des procédures. Les sujets clés sont les suivants : automatisation des modifications, réponse aux événements et définition des normes pour gérer les opérations quotidiennes.
**Topics**
+ [OE 1 : Comment comprenez-vous les alertes et les événements déclenchés par votre ElastiCache cluster et comment y répondez-vous ?](#OperationalExcellencePillarOE1)
+ [OE 2 : Quand et comment adaptez-vous vos ElastiCache clusters existants ?](#OperationalExcellencePillarOE2)
+ [OE 3 : Comment gérez-vous les ressources de votre ElastiCache cluster et entretenez-vous votre cluster up-to-date ?](#OperationalExcellencePillarOE3)
+ [OE 4 : Comment gérez-vous les connexions des clients à vos ElastiCache clusters ?](#OperationalExcellencePillarOE4)
+ [OE 5 : Comment déployez-vous des ElastiCache composants pour une charge de travail ?](#OperationalExcellencePillarOE5)
+ [EO 6 : Comment planifiez-vous et atténuez-vous les défaillances ?](#OperationalExcellencePillarOE6)
+ [OE 7 : Comment résoudre les événements du moteur Valkey ou Redis OSS ?](#OperationalExcellencePillarOE7)
## OE 1 : Comment comprenez-vous les alertes et les événements déclenchés par votre ElastiCache cluster et comment y répondez-vous ?
**Introduction au niveau des questions :** Lorsque vous gérez des ElastiCache clusters, vous pouvez éventuellement recevoir des notifications et des alertes lorsque des événements spécifiques se produisent. ElastiCache, par défaut, enregistre les [événements](ECEvents.md) liés à vos ressources, tels qu'un basculement, le remplacement d'un nœud, une opération de dimensionnement, une maintenance planifiée, etc. Chaque événement inclut la date et l'heure, le nom et le type de source, ainsi qu'une description.
**Avantage au niveau de la question : **la capacité à comprendre et à gérer les raisons sous-jacentes des événements qui déclenchent les alertes générées par votre cluster vous permet de fonctionner plus efficacement et de répondre aux événements de manière appropriée.
+ **[Obligatoire]** [Passez en revue les événements générés ElastiCache sur la ElastiCache console (après avoir sélectionné votre région) ou à l'aide de la [commande [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) de l'interface de ligne de commande (AWS CLI) Amazon](https://aws.amazon.com/cli) et de l'ElastiCache API.](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) Configurez ElastiCache pour envoyer des notifications pour les événements importants du cluster à l'aide d'Amazon Simple Notification Service (Amazon SNS). L'utilisation d'Amazon SNS avec vos clusters vous permet de prendre des mesures programmatiques en cas d'événements. ElastiCache
+ Il existe deux grandes catégories d'événements : les événements en cours et les événements planifiés. La liste des événements actuels inclut : la création et la suppression de ressources, les opérations de mise à l’échelle, le basculement, le redémarrage du nœud, la création d'un instantané, la modification d’un paramètre du cluster, le renouvellement d’un certificat CA, les événements d'échec (échec de l’allocation du cluster (VPC ou ENI), échec de mise à l’échelle (ENI) et échec d’un instantané). La liste des événements planifiés inclut : nœud dont le remplacement est planifié pendant la fenêtre de maintenance et nœud dont le remplacement a été replanifié.
+ Bien que vous n'ayez pas besoin de réagir immédiatement à certains de ces événements, il est essentiel de commencer par examiner tous les événements d’échec :
+ ElastiCache:AddCacheNodeFailed
+ ElastiCache:CacheClusterProvisioningFailed
+ ElastiCache:CacheClusterScalingFailed
+ ElastiCache:CacheNodesRebooted
+ ElastiCache: SnapshotFailed (Valkey ou Redis OSS uniquement)
+ **[Ressources] :**
+ [Gestion des ElastiCache notifications Amazon SNS](ECEvents.SNS.md)
+ [Notifications d'événements Amazon SNS](ElastiCacheSNS.md)
+ **[Idéal]** Pour automatiser les réponses aux événements, tirez parti des fonctionnalités AWS des produits et services telles que les fonctions SNS et Lambda. Suivez les meilleures pratiques en apportant des modifications mineures, fréquentes et réversibles, sous forme de code pour faire évoluer vos opérations au fil du temps. Vous devez utiliser CloudWatch les métriques Amazon pour surveiller vos clusters.
**[Ressources] :** [Surveillez ElastiCache (mode cluster désactivé) lisez les points de terminaison des répliques à l'aide de AWS Lambda, Amazon Route 53 et Amazon SNS](https://aws.amazon.com/blogs/database/monitor-amazon-elasticache-for-redis-cluster-mode-disabled-read-replica-endpoints-using-aws-lambda-amazon-route-53-and-amazon-sns/) pour un cas d'utilisation utilisant Lambda et SNS.
## OE 2 : Quand et comment adaptez-vous vos ElastiCache clusters existants ?
**Introduction au niveau des questions :** Le dimensionnement correct de votre ElastiCache cluster est un exercice d'équilibre qui doit être évalué chaque fois que des modifications sont apportées aux types de charge de travail sous-jacents. Votre objectif est de fonctionner avec un environnement de taille adaptée à votre charge de travail.
**Avantage au niveau de la question : **une utilisation excessive de vos ressources peut entraîner une latence élevée et une diminution globale des performances. La sous-utilisation, en revanche, peut entraîner une sur-allocation des ressources avec une optimisation des coûts non optimale. En ajustant la taille de vos environnements, vous pouvez trouver un équilibre entre efficacité des performances et optimisation des coûts. Pour remédier à la surutilisation ou à la sous-utilisation de vos ressources, vous ElastiCache pouvez effectuer une mise à l'échelle en deux dimensions. Vous pouvez effectuer une mise à l'échelle verticale en augmentant ou en diminuant la capacité des nœuds. Vous pouvez également effectuer une mise à l'échelle horizontale en ajoutant et en supprimant des nœuds.
+ **[Obligatoire]** La surutilisation de l’UC et du réseau sur les nœuds primaires doit être corrigée en déchargeant et en redirigeant les opérations de lecture vers les nœuds de réplicas. Utilisez des nœuds de réplicas pour les opérations de lecture afin de réduire l'utilisation du nœud primaire. Cela peut être configuré dans votre bibliothèque cliente Valkey ou Redis OSS en vous connectant au point de terminaison du ElastiCache lecteur pour désactiver le mode cluster, ou en utilisant la commande READONLY pour le mode cluster activé.
**[Ressources] :**
+ [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md)
+ [Cluster Right-Sizing](https://aws.amazon.com/blogs/database/five-workload-characteristics-to-consider-when-right-sizing-amazon-elasticache-redis-clusters/)
+ [Commande READONLY](https://valkey.io/commands/readonly)
+ **[Obligatoire]** Surveillez l'utilisation des ressources critiques du cluster telles que l’UC, la mémoire et le réseau. L'utilisation de ces ressources de cluster spécifiques doit faire l'objet d'un suivi afin de prendre des décisions éclairées quant à la mise à l'échelle et le type d'opération de mise à l’échelle. Lorsque le mode ElastiCache cluster est désactivé, les nœuds principaux et répliques peuvent être redimensionnés verticalement. Les nœuds de réplicas peuvent également être mis à l’échelle horizontalement de 0 à 5 nœuds. Si le mode cluster est activé, il en va de même pour chaque partition de votre cluster. En outre, vous pouvez augmenter ou réduire le nombre de partitions.
**[Ressources] :**
+ [Surveillance des meilleures pratiques liées à ElastiCache l'utilisation d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [Mise à l'échelle des ElastiCache clusters pour Valkey et Redis OSS](Scaling.md)
+ [Mise à l'échelle ElastiCache des clusters pour Memcached](Scaling.md)
+ **[Meilleure pratique]** La surveillance des tendances au fil du temps peut vous aider à détecter les modifications de la charge de travail qui passeraient inaperçues si elles étaient surveillées à un moment donné. Pour détecter les tendances à long terme, utilisez CloudWatch des métriques pour rechercher des plages temporelles plus longues. Les enseignements tirés de l'observation de longues périodes de CloudWatch mesures devraient éclairer vos prévisions concernant l'utilisation des ressources du cluster. CloudWatch les points de données et les mesures sont disponibles pendant 455 jours au maximum.
**[Ressources] :**
+ [Surveillance à ElastiCache l'aide de CloudWatch métriques](CacheMetrics.md)
+ [Surveillance de Memcached avec des métriques CloudWatch ](CacheMetrics.md)
+ [Surveillance des meilleures pratiques liées à ElastiCache l'utilisation d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Idéal]** Si vos ElastiCache ressources sont créées avec, CloudFormation il est recommandé d'effectuer des modifications à l'aide de CloudFormation modèles afin de préserver la cohérence opérationnelle et d'éviter les modifications de configuration non gérées et les dérives de pile.
**[Ressources] :**
+ [ElastiCache référence de type de ressource pour CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[Mieux]** Automatisez vos opérations de dimensionnement à l'aide des données opérationnelles du cluster et définissez des seuils CloudWatch pour configurer les alarmes. Utilisez CloudWatch Events and Simple Notification Service (SNS) pour déclencher des fonctions Lambda et exécuter une ElastiCache API afin de dimensionner automatiquement vos clusters. Par exemple, vous pouvez ajouter une partition à votre cluster lorsque la métrique `EngineCPUUtilization` atteint 80 % pendant une période prolongée. Une autre option serait d'utiliser `DatabaseMemoryUsedPercentages` pour un seuil basé sur la mémoire.
**[Ressources] :**
+ [Utilisation d'Amazon CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Que sont les CloudWatch événements Amazon ?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Utilisation AWS Lambda avec Amazon Simple Notification Service](https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html)
+ [Référence d’API ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
## OE 3 : Comment gérez-vous les ressources de votre ElastiCache cluster et entretenez-vous votre cluster up-to-date ?
**Introduction au niveau des questions :** Lorsque vous opérez à grande échelle, il est essentiel que vous soyez en mesure d'identifier et d'identifier toutes vos ressources. ElastiCache Lorsque vous déployez de nouvelles fonctionnalités d'application, vous devez créer une symétrie entre les versions de cluster dans tous vos types d' ElastiCache environnement : développement, test et production. Les attributs de ressources vous permettent de séparer les environnements pour différents objectifs opérationnels, par exemple lors du déploiement de nouvelles fonctionnalités et de l'activation de nouveaux mécanismes de sécurité.
**Avantage au niveau de la question : **la meilleure pratique opérationnelle consiste à séparer vos environnements de développement, de test et de production. Il est également recommandé que les derniers correctifs logiciels soient appliqués à vos clusters et nœuds dans tous les environnements à l'aide de processus bien compris et documentés. Tirer parti des ElastiCache fonctionnalités natives permet à votre équipe d'ingénierie de se concentrer sur l'atteinte des objectifs commerciaux et non sur la ElastiCache maintenance.
+ **[Mieux]** Utilisez la dernière version du moteur disponible et appliquez les mises à jour en libre-service dès qu'elles sont disponibles. ElastiCache met automatiquement à jour son infrastructure sous-jacente pendant la période de maintenance que vous avez spécifiée pour le cluster. Toutefois, les nœuds qui s'exécutent dans vos clusters sont mis à jour via les mises à jour en libre-service. Ces mises à jour peuvent être de deux types : correctifs de sécurité ou mises à jour logicielles mineures. Assurez-vous de bien comprendre la différence entre les types de correctifs et le moment où ils sont appliqués.
**[Ressources] :**
+ [Mises à jour en libre-service sur Amazon ElastiCache](Self-Service-Updates.md)
+ [Page d'aide ElastiCache relative à la maintenance gérée et aux mises à jour des services Amazon](https://aws.amazon.com/elasticache/elasticache-maintenance/)
+ **[Idéal]** Organisez vos ElastiCache ressources à l'aide de balises. Utilisez des balises sur des groupes de réplication et non sur des nœuds individuels. Vous pouvez configurer les balises à afficher lorsque vous interrogez des ressources et vous pouvez utiliser des balises pour effectuer des recherches et appliquer des filtres. Vous devez utiliser les groupes de ressources pour créer et gérer facilement des collections de ressources qui partagent des ensembles de balises communs.
**[Ressources] :**
+ [Tagging Best Practices](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)
+ [ElastiCache référence de type de ressource pour CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [Groupes de paramètres](ParameterGroups.Engine.md#ParameterGroups.Redis)
## OE 4 : Comment gérez-vous les connexions des clients à vos ElastiCache clusters ?
**Introduction au niveau des questions :** lorsque vous opérez à grande échelle, vous devez comprendre comment vos clients se connectent au ElastiCache cluster pour gérer les aspects opérationnels de votre application (tels que les temps de réponse).
**Avantage au niveau de la question : **le choix du mécanisme de connexion le plus approprié garantit que votre application ne se déconnecte pas en raison d'erreurs de connectivité, telles que des délais d'expiration.
+ **[Obligatoire]** Séparez les opérations de lecture des opérations d'écriture et connectez-vous aux nœuds de réplicas pour exécuter les opérations de lecture. Sachez toutefois que lorsque vous séparez les écritures des lectures, vous perdrez la possibilité de lire une clé immédiatement après l'avoir écrite en raison de la nature asynchrone de la réplication Valkey et Redis OSS. La commande WAIT peut être utilisée pour améliorer la sécurité des données réelles et forcer les réplicas à accuser réception des écritures avant de répondre aux clients, moyennant un coût global en termes de performances. L'utilisation de nœuds de réplication pour les opérations de lecture peut être configurée dans votre bibliothèque ElastiCache cliente à l'aide du point de terminaison du ElastiCache lecteur pour désactiver le mode cluster. Pour activer le mode cluster, utilisez la commande READONLY. Pour de nombreuses bibliothèques ElastiCache clientes, READONLY est implémenté par défaut ou via un paramètre de configuration.
**[Ressources] :**
+ [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md)
+ [READONLY](https://valkey.io/commands/readonly)
+ **[Obligatoire] **Utilisez le regroupement de connexions. L'établissement d'une connexion TCP entraîne des coûts en termes de temps UC, à la fois côté client et côté serveur, et le regroupement permet de réutiliser la connexion TCP.
Pour réduire la surcharge de connexion, vous devez utiliser le regroupement de connexions. Avec un pool de connexions, votre application peut réutiliser et libérer des connexions « à volonté », sans les coûts liés à l'établissement de la connexion. Vous pouvez implémenter le regroupement de connexions via votre bibliothèque ElastiCache cliente (si elle est prise en charge), avec un framework disponible pour votre environnement d'application, ou le créer à partir de zéro.
+ **[Meilleure pratique]** Assurez-vous que le délai d'expiration du socket du client est défini sur au moins une seconde (la valeur par défaut « aucun » est généralement définie dans certains clients).
+ Si la valeur du délai d'attente est trop faible, cela peut entraîner des délais d'expiration lorsque la charge du serveur est élevée. Si cette valeur est trop élevée, votre application peut mettre du temps à détecter les problèmes de connexion.
+ Contrôlez le volume des nouvelles connexions en implémentant le regroupement de connexions dans votre application client. Cela réduit la latence et l'utilisation de l’UC nécessaires à l'ouverture et à la fermeture de connexions, et à l'établissement d'une liaison TLS si le protocole TLS est activé sur le cluster.
**[Ressources] :** [Configuration ElastiCache pour une meilleure disponibilité](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ **[Bonne pratique]** La mise en pipeline (lorsque vos cas d'utilisation le permettent) peut améliorer les performances de manière significative.
+ Grâce à la mise en pipeline, vous réduisez le temps d'aller-retour (RTT) entre vos clients d'applications et le cluster et les nouvelles demandes peuvent être traitées même si le client n'a pas encore lu les réponses précédentes.
+ Avec la mise en pipeline, vous pouvez envoyer plusieurs commandes au serveur sans attendre de réponse/accusé de réception. La mise en pipeline a toutefois un inconvénient : lorsque vous finissez par extraire toutes les réponses en bloc, il se peut qu'une erreur se soit produite et que vous ne la détectiez pas avant la fin.
+ Implémentez des méthodes pour renouveler les demandes lorsque l’erreur renvoyée omet la mauvaise demande.
**[Ressources] :** [Pipelining](https://valkey.io/topics/pipelining/)
## OE 5 : Comment déployez-vous des ElastiCache composants pour une charge de travail ?
**Introduction au niveau des questions :** ElastiCache les environnements peuvent être déployés manuellement via la AWS console, ou par programmation via une APIs CLI, des boîtes à outils, etc. Les meilleures pratiques en matière d'excellence opérationnelle suggèrent d'automatiser les déploiements par le biais du code chaque fois que cela est possible. En outre, les ElastiCache clusters peuvent être isolés par charge de travail ou combinés à des fins d'optimisation des coûts.
**Avantage au niveau des questions :** le choix du mécanisme de déploiement le mieux adapté à vos ElastiCache environnements peut améliorer l'excellence opérationnelle au fil du temps. Il est recommandé d'effectuer les opérations sous forme de code dans la mesure du possible afin de minimiser les erreurs humaines et d'augmenter la reproductibilité, la flexibilité et le temps de réponse aux événements.
En comprenant les exigences d'isolation des charges de travail, vous pouvez choisir d'avoir ElastiCache des environnements dédiés par charge de travail ou de combiner plusieurs charges de travail en clusters uniques, ou des combinaisons des deux. Comprendre les compromis peut aider à trouver un équilibre entre excellence opérationnelle et optimisation des coûts.
+ **[Obligatoire]** Comprenez les options de déploiement disponibles et automatisez ces procédures dans la mesure du possible. ElastiCache Les voies d'automatisation possibles incluent CloudFormation AWS CLI/SDK et. APIs
**[Ressources] : **
+ [Référence du type de ElastiCache ressource Amazon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [elasticache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
+ [Référence ElastiCache d'API Amazon](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
+ **[Obligatoire]** Pour toutes les charges de travail, déterminez le niveau d'isolation du cluster requis.
+ **[Meilleure pratique] :** Isolation élevée : mappage 1:1 de la charge de travail au cluster. Permet un contrôle précis de l'accès, du dimensionnement, de la mise à l'échelle et de la gestion des ElastiCache ressources par charge de travail.
+ **[Pratique encore meilleure] :** Isolation moyenne : M:1 isolé par objectif, mais peut-être partagé entre plusieurs charges de travail (par exemple, un cluster dédié à la mise en cache des charges de travail et un autre dédié à la messagerie).
+ **[Bonne pratique] :** Faible isolation : M:1 polyvalent, entièrement partagé. Recommandé pour les charges de travail où l'accès partagé est admis.
## EO 6 : Comment planifiez-vous et atténuez-vous les défaillances ?
**Introduction au niveau des questions : L'**excellence opérationnelle consiste notamment à anticiper les défaillances en effectuant régulièrement des exercices « pré-mortem » afin d'identifier les sources potentielles de défaillance afin de les éliminer ou de les atténuer. ElastiCache propose une API Failover qui permet de simuler des événements de défaillance d'un nœud, à des fins de test.
**Avantage au niveau de la question : **en testant les scénarios de défaillance à l'avance, vous pouvez découvrir leur impact sur votre charge de travail. Cela permet de tester en toute sécurité les procédures de réponse et leur efficacité, tout en familiarisant votre équipe avec leur exécution.
**[Obligatoire]** Effectuez régulièrement des tests de basculement dans les comptes de développement/test. [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)
## OE 7 : Comment résoudre les événements du moteur Valkey ou Redis OSS ?
**Introduction au niveau des questions : l'**excellence opérationnelle nécessite la capacité d'étudier à la fois les informations relatives au niveau du service et au niveau du moteur afin d'analyser l'état et l'état de vos clusters. ElastiCache peut émettre des journaux du moteur Valkey ou Redis OSS à la fois vers Amazon CloudWatch et Amazon Kinesis Data Firehose.
**Avantage au niveau des questions :** l'activation des journaux du moteur Valkey ou Redis OSS sur les ElastiCache clusters permet de mieux comprendre les événements qui ont un impact sur l'état et les performances des clusters. Les journaux du moteur Valkey ou Redis OSS fournissent des données directement à partir du moteur qui ne sont pas disponibles via le mécanisme ElastiCache des événements. En observant attentivement les ElastiCache événements (voir OE-1 précédent) et les journaux du moteur, il est possible de déterminer l'ordre des événements lors du dépannage du point de vue du ElastiCache service et du point de vue du moteur.
+ **[Obligatoire]** Assurez-vous que la fonctionnalité de journalisation du moteur Redis OSS est activée, qui est disponible depuis la ElastiCache version 6.2 pour Redis OSS et les versions ultérieures. Vous pouvez le faire lors de la création du cluster ou en modifiant le cluster après sa création.
+ Déterminez si Amazon CloudWatch Logs ou Amazon Kinesis Data Firehose est la cible appropriée pour les journaux du moteur Redis OSS.
+ Sélectionnez un journal cible approprié dans Kinesis Data Firehose CloudWatch ou dans Kinesis Data Firehose pour conserver les journaux. Si vous possédez plusieurs clusters, envisagez d’utiliser un journal cible différent pour chaque cluster. Cela vous aidera à isoler les données lors de la résolution des problèmes.
**[Ressources] :**
+ [Livraison de journaux](Log_Delivery.md)
+ Destinations de journalisation : [Amazon CloudWatch Logs](Logging-destinations.md#Destination_Specs_CloudWatch_Logs)
+ Présentation d'Amazon CloudWatch Logs : [Qu'est-ce qu'Amazon CloudWatch Logs ?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ Présentation d’Amazon Kinesis Data Firehose : [What Is Amazon Kinesis Data Firehose?](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
+ **[Mieux]** Si vous utilisez Amazon CloudWatch Logs, pensez à utiliser Amazon CloudWatch Logs Insights pour interroger le journal du moteur Valkey ou Redis OSS afin d'obtenir des informations importantes.
Par exemple, créez une requête CloudWatch sur le groupe de journaux contenant les journaux du moteur Valkey ou Redis OSS qui renverra des événements marqués LogLevel d'un « AVERTISSEMENT », tels que :
```
fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"
```
**[Ressources] :** [Analyse des données des CloudWatch journaux avec Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
# Pilier de ElastiCache sécurité Amazon Well-Architected Lens
Le pilier de sécurité se concentre sur la protection des informations et des systèmes. Les sujets clés sont les suivants : confidentialité et intégrité des données, identification et gestion de qui peut faire quoi grâce à la gestion basée sur les privilèges, protection des systèmes et mise en place de contrôles pour détecter les événements de sécurité.
**Topics**
+ [SEC 1 : Quelles mesures prenez-vous pour contrôler l'accès autorisé aux ElastiCache données ?](#SecurityPillarSEC1)
+ [SEC 2 : Vos applications nécessitent-elles une autorisation supplémentaire au-delà ElastiCache des contrôles basés sur le réseau ?](#SecurityPillarSEC2)
+ [PS 3 : Existe-t-il un risque que des commandes soient exécutées par inadvertance, entraînant une perte ou une défaillance des données ?](#SecurityPillarSEC3)
+ [SEC 4 : Comment garantir le chiffrement des données au repos avec ElastiCache](#SecurityPillarSEC4)
+ [SEC 5 : Comment cryptez-vous les données en transit ? ElastiCache](#SecurityPillarSEC5)
+ [PS 6 : Comment restreignez-vous l'accès aux ressources du plan de contrôle ?](#SecurityPillarSEC6)
+ [PS 7 : Comment détectez-vous les événements de sécurité et comment y répondez-vous ?](#SecurityPillarSEC7)
## SEC 1 : Quelles mesures prenez-vous pour contrôler l'accès autorisé aux ElastiCache données ?
**Introduction au niveau des questions :** tous les ElastiCache clusters sont conçus pour être accessibles à partir d'instances Amazon Elastic Compute Cloud dans un VPC, de fonctions sans serveur (AWS Lambda) ou de conteneurs (Amazon Elastic Container Service). Le scénario le plus courant consiste à accéder à un ElastiCache cluster depuis une instance Amazon Elastic Compute Cloud au sein du même Amazon Virtual Private Cloud (Amazon Virtual Private Cloud). Avant de pouvoir vous connecter à un cluster depuis une EC2 instance Amazon, vous devez autoriser l' EC2 instance Amazon à accéder au cluster. Pour accéder à un ElastiCache cluster exécuté dans un VPC, il est nécessaire d'autoriser l'accès réseau au cluster.
**Avantage au niveau de la question : **l'entrée réseau dans le cluster est contrôlée via les groupes de sécurité du VPC. Un groupe de sécurité agit comme un pare-feu virtuel pour vos EC2 instances Amazon afin de contrôler le trafic entrant et sortant. Les règles entrantes contrôlent le trafic entrant vers votre instance, et les règles sortantes contrôlent le trafic sortant de votre instance. Dans le cas où ElastiCache, lors du lancement d'un cluster, il est nécessaire d'associer un groupe de sécurité. Cela garantit que les règles de trafic entrant et sortant sont en place pour tous les nœuds qui composent le cluster. En outre, ElastiCache il est configuré pour être déployé exclusivement sur des sous-réseaux privés, de sorte qu'ils ne soient accessibles que via le réseau privé du VPC.
+ **[Obligatoire] **Le groupe de sécurité associé à votre cluster contrôle l’entrée réseau et l'accès au cluster. Par défaut, aucune règle entrante n'est définie pour un groupe de sécurité et, par conséquent, aucun chemin d'entrée vers celui-ci ne sera défini. ElastiCache Pour activer cela, configurez une règle entrante sur le groupe de sécurité spécifiant l'adresse/plage IP source, le trafic de type TCP et le port de votre ElastiCache cluster (port par défaut 6379 pour Valkey et Redis ElastiCache OSS par exemple). Bien qu'il soit possible d'autoriser un très large éventail de sources d'entrée, comme toutes les ressources d'un VPC (0.0.0.0/0), il est conseillé d'être aussi précis que possible dans la définition des règles entrantes, par exemple en autorisant uniquement l'accès entrant aux clients Valkey ou Redis OSS exécutés sur des instances Amazon Amazon associées à un groupe de sécurité spécifique. EC2
**[Ressources] : **
+ [Sous-réseaux et groupes de sous-réseaux](SubnetGroups.md)
+ [Accès à votre cluster ou groupe de réplication](accessing-elasticache.md)
+ [Contrôler le trafic vers vos ressources AWS à l'aide de groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#DefaultSecurityGroupdefault%20security%20group)
+ [Groupes de sécurité Amazon EC2 pour les instances Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#creating-your-own-security-groups)
+ Des Gestion des identités et des accès AWS politiques **[obligatoires]** peuvent être attribuées à des AWS Lambda fonctions leur permettant d'accéder aux ElastiCache données. Pour activer cette fonctionnalité, créez un rôle d'exécution IAM avec l'`AWSLambdaVPCAccessExecutionRole`autorisation, puis attribuez le rôle à la AWS Lambda fonction.
**[Ressources] :** Configuration d'une fonction Lambda pour accéder à Amazon ElastiCache dans un Amazon VPC : [Tutoriel : Configuration d'une fonction Lambda pour accéder à Amazon dans un Amazon](https://docs.aws.amazon.com/lambda/latest/dg/services-elasticache-tutorial.html) VPC ElastiCache
## SEC 2 : Vos applications nécessitent-elles une autorisation supplémentaire au-delà ElastiCache des contrôles basés sur le réseau ?
**Introduction au niveau des questions :** dans les scénarios où il est nécessaire de restreindre ou de contrôler l'accès aux clusters au niveau d'un client individuel, il est recommandé de s'authentifier via la commande AUTH. ElastiCache les jetons d'authentification, avec gestion optionnelle des utilisateurs et des groupes d'utilisateurs, permettent ElastiCache d'exiger un mot de passe avant de permettre aux clients d'exécuter des commandes et des clés d'accès, améliorant ainsi la sécurité du plan de données.
**Avantage au niveau des questions :** pour garantir la sécurité de vos données, ElastiCache fournit des mécanismes de protection contre tout accès non autorisé à vos données. Cela inclut l'application du contrôle d'accès basé sur les rôles (RBAC) AUTH ou du jeton AUTH (mot de passe) auquel les clients doivent se connecter avant d'exécuter des commandes autorisées. ElastiCache
+ **[Idéal]** Pour les ElastiCache versions 6.x et supérieures pour Redis OSS, et les ElastiCache versions 7.2 et supérieures pour Valkey, définissez les contrôles d'authentification et d'autorisation en définissant les groupes d'utilisateurs, les utilisateurs et les chaînes d'accès. Attribuez des utilisateurs à des groupes d'utilisateurs, puis attribuez des groupes d'utilisateurs à des clusters. Pour utiliser le RBAC, il doit être sélectionné lors de la création du cluster et le chiffrement en transit doit être activé. Assurez-vous d'utiliser un client Valkey ou Redis OSS compatible avec le protocole TLS pour pouvoir tirer parti du RBAC.
**[Ressources] : **
+ [Appliquer le RBAC à un groupe de réplication pour ElastiCache](Clusters.RBAC.md#rbac-using)
+ [Définition des autorisations à l'aide d'une chaîne d'accès](Clusters.RBAC.md#Access-string)
+ [ACL](https://valkey.io/topics/acl/)
+ [ ElastiCache Versions prises en charge](VersionManagement.md#supported-engine-versions)
+ **[Idéal]** Pour ElastiCache les versions antérieures à la version 6.x pour Redis OSS, en plus de définir une politique de mot de passe stricte token/password et de maintenir une politique de mot de passe stricte pour AUTH, il est recommandé de faire pivoter le mot de passe/jeton. ElastiCache peut gérer jusqu'à deux (2) jetons d'authentification à la fois. Vous pouvez également modifier le cluster pour exiger explicitement l'utilisation de jetons d'authentification.
**[Ressources] :** [Modification du jeton AUTH sur un cluster existant ElastiCache](auth.md#auth-modifyng-token)
## PS 3 : Existe-t-il un risque que des commandes soient exécutées par inadvertance, entraînant une perte ou une défaillance des données ?
**Introduction au niveau des questions :** Un certain nombre de commandes Valkey ou Redis OSS peuvent avoir un impact négatif sur les opérations si elles sont exécutées par erreur ou par des acteurs malveillants. Ces commandes peuvent avoir des conséquences imprévues du point de vue des performances et de la sécurité des données. Par exemple, un développeur peut appeler régulièrement la commande FLUSHALL dans un environnement de développement et, en raison d'une erreur, peut tenter par inadvertance d'appeler cette commande sur un système de production, ce qui entraîne une perte de données accidentelle.
**Avantage au niveau des questions :** à partir de ElastiCache la version 5.0.3 pour Redis OSS, il est possible de renommer certaines commandes susceptibles de perturber votre charge de travail. Le fait de renommer les commandes permet d'éviter qu'elles ne soient exécutées par inadvertance sur le cluster.
+ **[Obligatoire] **
**[Ressources] : **
+ [ElastiCache version 5.0.3 pour Redis OSS (obsolète, utilisez la version 5.0.6)](engine-versions.md#redis-version-5-0.3)
+ [ElastiCache version 5.0.3 pour les modifications des paramètres de Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3)
+ [Sécurité Redis OSS](https://redis.io/docs/management/security/)
## SEC 4 : Comment garantir le chiffrement des données au repos avec ElastiCache
**Introduction au niveau des questions :** Bien qu'il ElastiCache s'agisse d'un magasin de données en mémoire, il est possible de chiffrer toutes les données susceptibles d'être conservées (sur le stockage) dans le cadre des opérations standard du cluster. Cela inclut à la fois les sauvegardes planifiées et manuelles écrites sur Amazon S3, mais également les données enregistrées dans le stockage sur disque à la suite d'opérations de synchronisation et d'échange. Les types d'instances des familles M6g et R6g proposent également le chiffrement en mémoire permanent.
**Avantage au niveau des questions :** ElastiCache fournit un chiffrement au repos en option pour renforcer la sécurité des données.
+ **[Obligatoire]** Le chiffrement au repos ne peut être activé sur un ElastiCache cluster (groupe de réplication) que lors de sa création. Un cluster existant ne peut pas être modifié pour commencer à chiffrer les données au repos. Par défaut, ElastiCache fournira et gérera les clés utilisées pour le chiffrement au repos.
**[Ressources] : **
+ [Contraintes de chiffrement au repos](at-rest-encryption.md#at-rest-encryption-constraints)
+ [Activation du chiffrement au repos](at-rest-encryption.md#at-rest-encryption-enable)
+ **[Mieux]** Tirez parti des types d' EC2 instances Amazon qui chiffrent les données lorsqu'elles sont en mémoire (comme M6g ou R6g). Dans la mesure du possible, envisagez de gérer vos propres clés pour le chiffrement au repos. Pour les environnements de sécurité des données plus stricts, AWS Key Management Service (KMS) peut être utilisé pour gérer automatiquement les clés principales du client (CMK). Grâce à ElastiCache l'intégration avec AWS Key Management Service, vous pouvez créer, posséder et gérer les clés utilisées pour le chiffrement des données au repos pour votre ElastiCache cluster.
**[Ressources] : **
+ [Utilisation de clés gérées par le client depuis AWS Key Management Service](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)
+ [AWS Service de gestion des clés](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
+ [AWS KMS concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)
## SEC 5 : Comment cryptez-vous les données en transit ? ElastiCache
**Introduction au niveau de la question : **il est souvent exigé d'éviter que les données ne soient compromises pendant leur transit. Cela représente les données au sein des composants d'un système distribué, ainsi qu'entre les clients d'applications et les nœuds de cluster. ElastiCache répond à cette exigence en permettant le chiffrement des données en transit entre les clients et le cluster, et entre les nœuds du cluster eux-mêmes. Les types d'instances des familles M6g et R6g proposent également le chiffrement en mémoire permanent.
**Avantage détaillé : le chiffrement ElastiCache en transit d'Amazon** est une fonctionnalité facultative qui vous permet de renforcer la sécurité de vos données aux points les plus vulnérables, lorsqu'elles sont en transit d'un endroit à un autre.
+ **[Obligatoire]** Le chiffrement en transit ne peut être activé que sur un cluster (groupe de réplication) lors de sa création. Veuillez noter qu'en raison du traitement supplémentaire requis pour le chiffrement/déchiffrement des données, la mise en œuvre du chiffrement en transit aura un certain impact sur les performances. Pour comprendre l'impact, il est recommandé de comparer votre charge de travail avant et après l'activationencryption-in-transit.
**[Ressources] : **
+ [Présentation du chiffrement en transit](in-transit-encryption.md#in-transit-encryption-overview)
## PS 6 : Comment restreignez-vous l'accès aux ressources du plan de contrôle ?
**Introduction au niveau des questions : les politiques** IAM et l'ARN permettent des contrôles d'accès précis ElastiCache pour Valkey et Redis OSS, permettant ainsi un contrôle plus strict de la gestion de la création, de la modification et de la suppression des clusters.
**Avantage au niveau des questions :** la gestion des ElastiCache ressources Amazon, telles que les groupes de réplication, les nœuds, etc., peut être limitée aux AWS comptes dotés d'autorisations spécifiques basées sur les politiques IAM, ce qui améliore la sécurité et la fiabilité des ressources.
+ **[Obligatoire]** Gérez l'accès aux ElastiCache ressources Amazon en attribuant des Gestion des identités et des accès AWS politiques spécifiques aux AWS utilisateurs, afin de mieux contrôler quels comptes peuvent effectuer quelles actions sur les clusters.
**[Ressources] : **
+ [Vue d'ensemble de la gestion des autorisations d'accès à vos ElastiCache ressources](IAM.Overview.md)
+ [Utilisation de politiques basées sur l'identité (politiques IAM) pour Amazon ElastiCache](IAM.IdentityBasedPolicies.md)
## PS 7 : Comment détectez-vous les événements de sécurité et comment y répondez-vous ?
**Introduction au niveau des questions :** ElastiCache lorsqu'il est déployé avec le RBAC activé, exporte des CloudWatch métriques pour informer les utilisateurs des événements de sécurité. Ces métriques permettent d'identifier les tentatives infructueuses d'authentification, d'accès aux clés ou d'exécution des commandes que les utilisateurs RBAC connectés ne sont pas autorisés à effectuer.
En outre, AWS les ressources relatives aux produits et services contribuent à sécuriser votre charge de travail globale en automatisant les déploiements et en enregistrant toutes les actions et modifications pour un examen ou un audit ultérieurs.
**Avantage au niveau de la question : **en surveillant les événements, vous permettez à votre organisation de répondre conformément à vos exigences, vos politiques et vos procédures. L'automatisation de la surveillance et des réponses à ces événements de sécurité renforce votre posture de sécurité globale.
+ **[Obligatoire]** Familiarisez-vous avec les CloudWatch métriques publiées concernant les échecs d'authentification et d'autorisation RBAC.
+ AuthenticationFailures = Tentatives d'authentification infructueuses auprès de Valkey ou Redis OSS
+ KeyAuthorizationFailures = Tentatives infructueuses des utilisateurs pour accéder aux clés sans autorisation
+ CommandAuthorizationFailures = Tentatives infructueuses d'exécution de commandes par des utilisateurs sans autorisation
**[Ressources] : **
+ [Métriques pour Valkey ou Redis OSS](CacheMetrics.Redis.md)
+ **[Meilleure pratique] **Il est recommandé de configurer des alertes et des notifications sur ces métriques et d'y répondre si nécessaire.
**[Ressources] : **
+ [Utilisation des CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ **[Mieux]** Utilisez la commande Valkey ou Redis OSS ACL LOG pour recueillir plus de détails
**[Ressources] : **
+ [ACL LOG](https://valkey.io/commands/acl-log/)
+ **[Mieux]** Familiarisez-vous avec les fonctionnalités AWS des produits et services en matière de surveillance, de journalisation et d'analyse des ElastiCache déploiements et des événements
**[Ressources] : **
+ [Journalisation des appels ElastiCache d'API Amazon avec AWS CloudTrail](logging-using-cloudtrail.md)
+ [elasticache-redis-cluster-automatic-vérification des sauvegardes](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)
+ [Surveillance de l'utilisation à l'aide de CloudWatch métriques](CacheMetrics.md)
# Pilier de fiabilité des objectifs Amazon ElastiCache Well-Architected
Le pilier de la fiabilité met l'accent sur les charges de travail exécutant les fonctions prévues et sur la manière de se remettre rapidement en cas d'incapacité à répondre aux demandes. Les sujets clés incluent la conception de systèmes distribués, la planification de la restauration et l'adaptation à l'évolution des exigences.
**Topics**
+ [PF 1 : Comment prenez-vous en charge les déploiements d'architecture haute disponibilité ?](#ReliabilityPillarREL1)
+ [REL 2 : Comment atteignez-vous vos objectifs de point de reprise (RPOs) ElastiCache ?](#ReliabilityPillarREL2)
+ [PF 3 : Comment répondez-vous aux exigences de reprise après sinistre (DR) ?](#ReliabilityPillarREL3)
+ [PF 4 : Comment planifiez-vous efficacement les basculements ?](#ReliabilityPillarREL4)
+ [REL 5 : Vos ElastiCache composants sont-ils conçus pour évoluer ?](#ReliabilityPillarREL5)
## PF 1 : Comment prenez-vous en charge les déploiements d'architecture haute disponibilité ?
**Introduction au niveau des questions :** Comprendre l'architecture de haute disponibilité d'Amazon vous ElastiCache permettra de fonctionner de manière résiliente lors d'événements de disponibilité.
**Avantage au niveau des questions : l'architecture de vos ElastiCache clusters de manière à ce qu'ils soient résilients aux défaillances garantit une meilleure disponibilité de vos déploiements**. ElastiCache
+ **[Obligatoire]** Déterminez le niveau de fiabilité dont vous avez besoin pour votre ElastiCache cluster. Les différentes charges de travail sont soumises à des normes de résilience différentes, qu'il s'agisse de charges de travail entièrement éphémères ou de charges de travail essentielles à la mission. Définissez les besoins pour chaque type d'environnement que vous exploitez, tel que le développement, le test et la production.
Moteur de mise en cache : ElastiCache pour Memcached ou ElastiCache pour Valkey et Redis OSS
1. ElastiCache for Memcached ne fournit aucun mécanisme de réplication et est principalement utilisé pour les charges de travail éphémères.
1. ElastiCache pour Valkey et Redis, OSS propose des fonctionnalités HA décrites ci-dessous
+ **[Idéal]** Pour les charges de travail nécessitant une haute disponibilité, utilisez-les ElastiCache en mode cluster avec un minimum de deux répliques par partition, même pour les charges de travail nécessitant un faible débit qui ne nécessitent qu'une seule partition.
1. Lorsque le mode cluster est activé, la configuration Multi-AZ est activée automatiquement.
Multi-AZ minimise les interruptions en effectuant des basculements automatiques du nœud primaire vers les réplicas, en cas de maintenance planifiée ou non planifiée, et en atténuant les défaillances de la zone de disponibilité.
1. Pour les charges de travail partitionnées, un minimum de trois partitions permet une restauration plus rapide en cas de basculement, car le protocole de cluster Valkey ou Redis OSS exige que la majorité des nœuds principaux soient disponibles pour atteindre le quorum.
1. Configurez deux réplicas ou plus selon la disponibilité.
Le fait de disposer de deux réplicas améliore la capacité de mise à l’échelle en lecture ainsi que la disponibilité en lecture dans les scénarios où un réplica est en cours de maintenance.
1. Utilisez des types de nœuds basés sur Graviton2 (nœuds par défaut dans la plupart des régions).
ElastiCache a ajouté des performances optimisées sur ces nœuds. Vous bénéficiez ainsi de meilleures performances en termes de réplication et de synchronisation, ce qui se traduit par une disponibilité globale améliorée.
1. Surveillez et ajustez la taille pour faire face aux pics de trafic prévus : en cas de forte charge, le moteur peut ne plus répondre, ce qui affecte la disponibilité. `BytesUsedForCache`et `DatabaseMemoryUsagePercentage` sont de bons indicateurs de votre utilisation de la mémoire, alors `ReplicationLag` qu'ils indiquent l'état de votre réplication en fonction de votre taux d'écriture. Vous pouvez utiliser ces métriques pour déclencher la mise à l'échelle du cluster.
1. Assurez la résilience côté client en effectuant des tests à l'aide de l'[API Failover avant un événement de basculement de production](https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/APIReference/API_TestFailover.html).
**[Ressources] : **
+ [Configuration ElastiCache pour Redis OSS pour une meilleure disponibilité](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Haute disponibilité avec les groupes de réplication](Replication.md)
## REL 2 : Comment atteignez-vous vos objectifs de point de reprise (RPOs) ElastiCache ?
**Introduction au niveau des questions :** comprenez le RPO de la charge de travail pour éclairer les décisions relatives aux stratégies de ElastiCache sauvegarde et de restauration.
**Avantage au niveau de la question : **la mise en place d'une stratégie de RPO peut améliorer la continuité des activités en cas de scénario de reprise après sinistre. La conception de vos politiques de sauvegarde et de restauration peut vous aider à atteindre vos objectifs de point de restauration (RPO) pour vos ElastiCache données. ElastiCache propose des fonctionnalités de capture instantanée stockées dans Amazon S3, ainsi qu'une politique de conservation configurable. Ces instantanés sont pris au cours d'une fenêtre de sauvegarde définie et sont gérés automatiquement par le service. Si votre charge de travail nécessite une granularité de sauvegarde supplémentaire, vous avez la possibilité de créer jusqu'à 20 sauvegardes manuelles par jour. Les sauvegardes créées manuellement ne sont pas soumises à une politique de conservation de service et peuvent être conservées indéfiniment.
+ **[Obligatoire]** Comprenez et documentez le RPO de vos ElastiCache déploiements.
+ Sachez que Memcached ne propose aucun processus de sauvegarde.
+ Passez en revue les fonctionnalités de ElastiCache Backup and Restore.
+ **[Meilleure pratique] **Mettez en place un processus bien communiqué pour la sauvegarde de votre cluster.
+ Lancez des sauvegardes manuelles selon vos besoins.
+ Passez en revue les politiques de conservation pour les sauvegardes automatiques.
+ Notez que les sauvegardes manuelles seront conservées indéfiniment.
+ Planifiez vos sauvegardes automatiques pendant les périodes de faible utilisation.
+ Effectuez des opérations de sauvegarde sur des réplicas en lecture afin de minimiser l'impact sur les performances du cluster.
+ **[Bien]** Tirez parti de la fonction de sauvegarde planifiée ElastiCache pour sauvegarder régulièrement vos données pendant une période définie.
+ Testez régulièrement les restaurations à partir de vos sauvegardes.
+ **[Ressources] : **
+ [Système d'exploitation Redis](https://aws.amazon.com/elasticache/faqs/#Redis)
+ [Backup et restauration pour ElastiCache](backups.md)
+ [Réalisation de sauvegardes manuelles](backups-manual.md)
+ [Planification des sauvegardes automatiques](backups-automatic.md)
+ [ ElastiCache Clusters de sauvegarde et de restauration](https://aws.amazon.com/blogs/aws/backup-and-restore-elasticache-redis-nodes/)
## PF 3 : Comment répondez-vous aux exigences de reprise après sinistre (DR) ?
**Introduction au niveau des questions :** La reprise après sinistre est un aspect important de toute planification de la charge de travail. ElastiCache propose plusieurs options pour mettre en œuvre la reprise après sinistre en fonction des exigences de résilience de la charge de travail. Avec Amazon ElastiCache Global Datastore, vous pouvez écrire dans votre cluster situé dans une région et disposer des données disponibles pour être lues à partir de deux autres clusters de répliques interrégionaux, ce qui permet des lectures à faible latence et une reprise après sinistre dans toutes les régions.
**Avantage au niveau de la question : **la compréhension et la planification de divers scénarios de sinistre peuvent garantir la continuité des activités. Les stratégies de reprise après sinistre doivent être équilibrées en termes de coût, d'impact sur les performances et de risque de perte de données.
+ **[Obligatoire]** Développez et documentez des stratégies de reprise après sinistre pour tous vos ElastiCache composants en fonction des exigences de charge de travail. ElastiCache est unique en ce sens que certains cas d'utilisation sont totalement éphémères et ne nécessitent aucune stratégie de reprise après sinistre, tandis que d'autres se situent à l'opposé et nécessitent une stratégie de reprise après sinistre extrêmement robuste. Toutes les options doivent être évaluées par rapport à l'optimisation des coûts : une meilleure résilience exige de plus grandes quantités d'infrastructure.
Découvrez les options de reprise après sinistre disponibles au niveau régional et multirégional.
+ Les déploiements multi-AZ sont recommandés pour se prémunir contre les pannes de zone de disponibilité. Assurez-vous de déployer avec le mode cluster activé dans les architectures multi-AZ, avec un minimum de 3 disponibles. AZs
+ L’entrepôt de données global est recommandé pour se prémunir contre les défaillances régionales.
+ **[Meilleure pratique] **Activez l’entrepôt de données global pour les charges de travail qui nécessitent une résilience au niveau de la région.
+ Prévoyez un basculement vers la région secondaire en cas de dégradation du cluster principal.
+ Testez le processus de basculement multirégional avant un basculement en production.
+ Surveillez la métrique `ReplicationLag` pour comprendre l'impact potentiel de la perte de données lors des événements de basculement.
+ **[Ressources] : **
+ [Atténuation des défaillances](disaster-recovery-resiliency.md#FaultTolerance)
+ [Réplication entre AWS régions à l'aide de banques de données mondiales](Redis-Global-Datastore.md)
+ [Restauration à partir d'une sauvegarde avec redimensionnement facultatif du cluster](backups-restoring.md)
+ [Minimiser les temps d'arrêt ElastiCache pour Valkey et Redis OSS avec Multi-AZ](AutoFailover.md)
## PF 4 : Comment planifiez-vous efficacement les basculements ?
**Introduction au niveau des questions : L'**activation du multi-AZ avec des basculements automatiques est une bonne pratique. ElastiCache Dans certains cas, ElastiCache pour Valkey et Redis, OSS remplace les nœuds principaux dans le cadre des opérations de service. Par exemple, lors d’événements de maintenance planifiée et dans le cas improbable d'une défaillance du nœud ou d’un problème avec la zone de disponibilité. La réussite d'un basculement dépend à la fois de la configuration de votre bibliothèque cliente ElastiCache et de votre bibliothèque cliente.
**Avantage au niveau des questions : le respect** des meilleures pratiques en matière de ElastiCache basculement en conjonction avec votre bibliothèque ElastiCache client spécifique vous permet de minimiser les temps d'arrêt potentiels lors d'événements de basculement.
+ **[Obligatoire] **Lorsque le mode cluster est désactivé, utilisez les délais d'expiration afin que vos clients détectent s'ils doivent se déconnecter de l'ancien nœud primaire et se reconnecter au nouveau nœud primaire, à l'aide de l'adresse IP du point de terminaison principal mise à jour. Lorsque le mode cluster est activé, la bibliothèque cliente est chargée de détecter les modifications de la topologie du cluster sous-jacent. Cela se fait le plus souvent par le biais des paramètres de configuration de la bibliothèque ElastiCache cliente, qui vous permettent également de configurer la fréquence et la méthode d'actualisation. Chaque bibliothèque cliente propose ses propres paramètres et des détails supplémentaires sont disponibles dans la documentation correspondante.
**[Ressources] : **
+ [Minimiser les temps d'arrêt ElastiCache pour Valkey et Redis OSS avec Multi-AZ](AutoFailover.md)
+ Passez en revue les meilleures pratiques de votre bibliothèque ElastiCache cliente.
+ **[Obligatoire] **La réussite des basculements dépend de l'intégrité de l'environnement de réplication entre le nœud primaire et le nœud de réplica. Examinez et comprenez la nature asynchrone de la réplication Valkey et Redis OSS, ainsi que les CloudWatch mesures disponibles pour signaler le délai de réplication entre les nœuds principaux et les nœuds de réplication. Pour les cas d'utilisation nécessitant une plus grande sécurité des données, utilisez la commande WAIT pour forcer les répliques à accuser réception des écritures avant de répondre aux clients connectés.
**[Ressources] : **
+ [Métriques pour Valkey ou Redis OSS](CacheMetrics.Redis.md)
+ [Surveillance des meilleures pratiques liées à ElastiCache l'utilisation d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Mieux]** Validez régulièrement la réactivité de votre application lors du basculement à l'aide de l'API ElastiCache Test Failover.
**[Ressources] : **
+ [Test du basculement automatique vers une réplique en lecture sur ElastiCache](https://aws.amazon.com/blogs/database/testing-automatic-failover-to-a-read-replica-on-amazon-elasticache-for-redis/)
+ [Test du basculement automatique](AutoFailover.md#auto-failover-test)
## REL 5 : Vos ElastiCache composants sont-ils conçus pour évoluer ?
**Introduction au niveau des questions :** en comprenant les capacités de mise à l'échelle et les topologies de déploiement disponibles, vos ElastiCache composants peuvent s'adapter au fil du temps pour répondre à l'évolution des exigences de charge de travail. ElastiCachepropose une mise à l'échelle à 4 voies : in/out (horizontale) et up/down (verticale).
**Avantage au niveau des questions :** le respect des meilleures pratiques en matière de ElastiCache déploiement garantit la plus grande flexibilité de mise à l'échelle, tout en respectant le principe Well Architected qui consiste à effectuer une mise à l'échelle horizontale afin de minimiser l'impact des défaillances.
+ **[Obligatoire] **Comprenez la différence entre les topologies « mode cluster activé » et « mode cluster désactivé ». Dans presque tous les cas, il est recommandé d’effectuer un déploiement en ayant activé le mode Cluster, car il permet de renforcer la capacité de mise à l’échelle au fil du temps. Les composants pour lesquels le mode cluster est désactivé sont limités dans leur capacité à être mis à l’échelle horizontalement en ajoutant des réplicas en lecture.
+ **[Obligatoire] **Sachez quand et comment procéder à une mise à l'échelle.
+ Pour augmenter le nombre de READIOPS : ajoutez des réplicas.
+ Pour augmenter le nombre de WRITEOPS : ajoutez des partitions (montée en puissance).
+ Pour augmenter le nombre d'E/S sur le réseau : utilisez des instances optimisées pour le réseau, augmentez la capacité.
+ **[Mieux]** Déployez vos ElastiCache composants en activant le mode cluster, en privilégiant un plus grand nombre de nœuds plus petits plutôt qu'un nombre réduit de nœuds plus grands. Cela limite efficacement le rayon d'explosion d'une défaillance de nœud.
+ **[Meilleure pratique] **Incluez des réplicas dans vos clusters pour améliorer la réactivité lors des événements de mise à l’échelle.
+ **[Bien] Si** le mode cluster est désactivé, utilisez les répliques de lecture pour augmenter la capacité de lecture globale. ElastiCache prend en charge jusqu'à 5 répliques de lecture en mode cluster désactivée, ainsi que la mise à l'échelle verticale.
+ **[Ressources] : **
+ [Dimensionnement ElastiCache des clusters](Scaling.md)
+ [Augmentation en ligne](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
# Pilier d'efficacité des ElastiCache performances des objectifs Amazon Well-Architected
Le pilier Efficacité des performances met l'accent sur l'utilisation efficace des ressources informatiques et de calcul. Les sujets clés incluent la sélection des types et des tailles de ressources appropriés en fonction des exigences de charge de travail, la surveillance des performances et la prise de décisions éclairées pour maintenir l'efficacité à mesure que les besoins de l'entreprise évoluent.
**Topics**
+ [PE 1 : Comment surveillez-vous les performances de votre ElastiCache cluster Amazon ?](#PerformanceEfficiencyPillarPE1)
+ [PE 2 : Comment répartissez-vous le travail entre les nœuds de votre ElastiCache cluster ?](#PerformanceEfficiencyPillarPE2)
+ [EP 3 : Pour la mise en cache des charges de travail, comment suivez-vous et rendez-vous compte de l'efficacité et des performances de votre cache ?](#PerformanceEfficiencyPillarPE3)
+ [EP 4 : Comment votre charge de travail optimise-t-elle l'utilisation des ressources de mise en réseau et des connexions ?](#PerformanceEfficiencyPillarPE4)
+ [PE 5 : Comment gérez-vous l' and/or expulsion par suppression de clés ?](#PerformanceEfficiencyPillarPE5)
+ [PE 6 : Comment modélisez-vous les données et interagissez-vous avec celles-ci ElastiCache ?](#PerformanceEfficiencyPillarPE6)
+ [PE 7 : Comment enregistrez-vous les commandes lentes dans votre ElastiCache cluster Amazon ?](#PerformanceEfficiencyPillarPE7)
+ [PE8: Comment Auto Scaling contribue-t-il à améliorer les performances du ElastiCache cluster ?](#PerformanceEfficiencyPillarPE8)
## PE 1 : Comment surveillez-vous les performances de votre ElastiCache cluster Amazon ?
**Introduction au niveau de la question : **en comprenant les métriques de surveillance existantes, vous pouvez identifier l'utilisation actuelle. Une surveillance appropriée peut aider à identifier les goulots d'étranglement potentiels ayant une incidence sur les performances de votre cluster.
**Avantage au niveau de la question : **la compréhension des métriques associées à votre cluster peut aider à orienter les techniques d'optimisation susceptibles de réduire la latence et d'augmenter le débit.
+ **[Obligatoire] **Tests de performance de base en utilisant un sous-ensemble de votre charge de travail.
+ Vous devez surveiller les performances de la charge de travail réelle à l'aide de mécanismes tels que les tests de charge.
+ Surveillez les CloudWatch indicateurs lors de l'exécution de ces tests afin de comprendre les indicateurs disponibles et d'établir une référence de performance.
+ **[Idéal]** ElastiCache Pour les charges de travail Valkey et Redis OSS, renommez les commandes coûteuses en termes de calcul, par exemple pour limiter la capacité des utilisateurs à exécuter des commandes de blocage sur des clusters de production. `KEYS`
+ ElastiCache les charges de travail exécutant le moteur 6.x pour Redis OSS peuvent tirer parti du contrôle d'accès basé sur les rôles pour restreindre certaines commandes. L'accès aux commandes peut être contrôlé en créant des utilisateurs et des groupes d'utilisateurs à l'aide de la AWS console ou de la CLI, et en associant les groupes d'utilisateurs à un cluster. Dans Redis OSS 6, lorsque le RBAC est activé, nous pouvons utiliser « - @dangerous » et cela interdira les commandes coûteuses telles que KEYS, MONITOR, SORT, etc. pour cet utilisateur.
+ Pour la version 5.x du moteur, renommez les commandes à l'aide du `rename-commands` paramètre du groupe de paramètres du cluster.
+ **[Pratique encore meilleure] **Analysez les requêtes lentes et recherchez des techniques d'optimisation.
+ ElastiCache Pour les charges de travail Valkey et Redis OSS, apprenez-en plus sur vos requêtes en analysant le Slow Log. Par exemple, vous pouvez utiliser la commande suivante `valkey-cli slowlog get 10` pour afficher les 10 dernières commandes qui ont dépassé les seuils de latence (10 millisecondes par défaut).
+ Certaines requêtes peuvent être effectuées plus efficacement à l'aide de structures de données complexes ElastiCache pour Valkey et Redis OSS. Par exemple, pour les consultations de plages de style numérique, une application peut implémenter des index numériques simples avec des ensembles triés. La gestion de ces index permet de réduire les analyses effectuées sur l'ensemble de données et de renvoyer les données avec une meilleure efficacité en termes de performances.
+ ElastiCache Pour les charges de travail Valkey et Redis OSS, `redis-benchmark` fournit une interface simple pour tester les performances de différentes commandes à l'aide d'entrées définies par l'utilisateur, telles que le nombre de clients et la taille des données.
+ Étant donné que Memcached ne prend en charge que les commandes simples au niveau de la clé, pensez à créer des clés supplémentaires sous forme d'index afin d'éviter d'itérer dans l'espace de clé pour répondre aux requêtes des clients.
+ **[Ressources] : **
+ [Surveillance de l'utilisation à l'aide de CloudWatch métriques](CacheMetrics.md)
+ [Utilisation des CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Paramètres spécifiques à Valkey et Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [SLOWLOG](https://valkey.io/commands/slowlog/)
+ [point de référence](https://valkey.io/topics/benchmark/)
## PE 2 : Comment répartissez-vous le travail entre les nœuds de votre ElastiCache cluster ?
**Introduction au niveau des questions :** la façon dont votre application se connecte ElastiCache aux nœuds Amazon peut avoir un impact sur les performances et l'évolutivité du cluster.
**Avantage au niveau de la question : **l'utilisation appropriée des nœuds disponibles dans le cluster garantira la répartition du travail entre les ressources disponibles. Les techniques suivantes permettent également d'éviter les ressources inactives.
+ **[Obligatoire]** Demandez aux clients de se connecter au point de ElastiCache terminaison approprié.
+ ElastiCache pour Valkey et Redis OSS implémente différents points de terminaison en fonction du mode cluster utilisé. Si le mode cluster est activé, ElastiCache fournira un point de terminaison de configuration. Lorsque le mode cluster est désactivé, ElastiCache fournit un point de terminaison principal, généralement utilisé pour les écritures, et un point de terminaison de lecteur pour équilibrer les lectures entre les répliques. L’implémentation correcte de ces points de terminaison se traduit par de meilleures performances et des opérations de mise à l'échelle simplifiées. Évitez de vous connecter à des points de terminaison de nœuds individuels, sauf exigences particulières.
+ Pour les clusters Memcached à nœuds multiples, ElastiCache fournit un point de terminaison de configuration qui active la découverte automatique. Il est recommandé d'utiliser un algorithme de hachage pour répartir le travail de manière uniforme entre les nœuds de cache. De nombreuses bibliothèques clientes Memcached implémentent un hachage cohérent. Consultez la documentation de la bibliothèque que vous utilisez pour voir si elle prend en charge le hachage cohérent et comment le mettre en œuvre. Vous trouverez plus d'informations sur l’implémentation de ces fonctionnalités [ici](BestPractices.LoadBalancing.md).
+ **[Mieux]** Tirez parti des clusters compatibles avec le mode cluster ElastiCache pour Valkey et Redis OSS pour améliorer l'évolutivité.
+ ElastiCache pour Valkey et Redis OSS (mode cluster activé), les clusters prennent [en charge les opérations de dimensionnement en ligne](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) (out/in and up/down) pour aider à distribuer les données de manière dynamique entre les partitions. L'utilisation du point de terminaison de configuration permet à vos clients qui connaissent le cluster de s'adapter aux modifications de la topologie du cluster.
+ Vous pouvez également rééquilibrer le cluster en déplaçant les hashslots entre les partitions disponibles dans votre cluster ElastiCache for Valkey et Redis OSS (mode cluster activé). Vous pourrez ainsi répartir le travail de manière plus efficace entre les partitions disponibles.
+ **[Pratique encore meilleure] **Implémentez une stratégie pour identifier et corriger les touches de raccourci de votre charge de travail.
+ Tenez compte de l'impact des structures de données multidimensionnelles Valkey ou Redis OSS telles que les listes, les flux, les ensembles, etc. Ces structures de données sont stockées dans des clés uniques, qui résident sur un seul nœud. Une clé multidimensionnelle très volumineuse est susceptible d'utiliser davantage de capacité réseau et de mémoire que les autres types de données et peut entraîner une utilisation disproportionnée de ce nœud. Si possible, concevez votre charge de travail de manière à répartir l'accès aux données sur de nombreuses clés discrètes.
+ Les touches de raccourci de la charge de travail peuvent avoir un impact sur les performances du nœud utilisé. ElastiCache Pour les charges de travail Valkey et Redis OSS, vous pouvez détecter les touches de raccourci en utilisant `valkey-cli --hotkeys` si une politique de mémoire maximale LFU est en place.
+ Envisagez de répliquer les touches de raccourci sur plusieurs nœuds afin de répartir leur accès de manière plus uniforme. Cette approche oblige le client à écrire sur plusieurs nœuds principaux (le nœud Valkey ou Redis OSS lui-même ne fournira pas cette fonctionnalité) et à conserver une liste de noms de clés à lire, en plus du nom de clé d'origine.
+ ElastiCache [le moteur 7.2 pour Valkey et versions ultérieures, et la ElastiCache version 6 pour Redis OSS et versions ultérieures, prennent tous en charge la mise en cache côté client assistée par le serveur.](https://valkey.io/topics/client-side-caching/) Cela permet aux applications d'attendre que des modifications soient apportées à une clé avant de renvoyer des appels réseau àElastiCache.
+ **[Ressources] : **
+ [Configuration ElastiCache pour Valkey et Redis OSS pour une meilleure disponibilité](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md)
+ [Bonnes pratiques en matière d’équilibrage de charge](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/BestPractices.LoadBalancing.html)
+ [Repartage en ligne pour Valkey ou Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Mise en cache côté client dans Valkey et Redis OSS](https://valkey.io/topics/client-side-caching/)
## EP 3 : Pour la mise en cache des charges de travail, comment suivez-vous et rendez-vous compte de l'efficacité et des performances de votre cache ?
**Introduction au niveau des questions :** La mise en cache est une charge de travail courante ElastiCache et il est important que vous sachiez comment gérer l'efficacité et les performances de votre cache.
**Avantage au niveau de la question : **votre application peut montrer des signes de lenteur des performances. Votre capacité à utiliser des métriques spécifiques au cache pour prendre des décisions éclairées quant à la manière d'améliorer les performances des applications est essentielle pour la charge de travail de votre cache.
+ **[Obligatoire] **Mesurez et suivez au fil du temps le taux d'accès au cache. L'efficacité de votre cache est déterminée par son « taux d'accès au cache ». Le taux d'accès au cache est défini par le nombre total d’accès à une clé divisé par le nombre total d’accès et d’échecs. Plus le taux est proche de 1, plus votre cache est efficace. Un faible taux d'accès au cache est dû au volume d'échecs d’accès au cache. Les échecs d’accès au cache se produisent lorsque la clé demandée n'est pas trouvée dans le cache. Une clé est introuvable dans le cache, car elle a été expulsée ou supprimée, a expiré ou n'a jamais existé. Déterminez pourquoi les clés ne figurent pas dans le cache et développez des stratégies appropriées pour les conserver dans le cache.
**[Ressources] : **
+ [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md)
+ **[Obligatoire]** Mesurez et collectez les performances du cache de votre application en conjonction avec les valeurs de latence et d'utilisation du processeur afin de déterminer si vous devez apporter des modifications à vos composants time-to-live ou à d'autres composants de l'application. ElastiCache fournit un ensemble de CloudWatch mesures pour les latences agrégées pour chaque structure de données. Ces mesures de latence sont calculées à l'aide des statistiques commandstats de la commande INFO et n'incluent ni le réseau ni le temps d'E/S. Il s'agit uniquement du temps nécessaire ElastiCache au traitement des opérations.
**[Ressources] : **
+ [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md)
+ [Surveillance des meilleures pratiques liées à ElastiCache l'utilisation d'Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Meilleure pratique] **Choisissez la stratégie de mise en cache adaptée à vos besoins. Un faible taux d'accès au cache est dû au volume d'échecs d’accès au cache. Si votre charge de travail est conçue pour présenter un faible volume d’échecs d’accès au cache (telles que les communications en temps réel), il est préférable de passer en revue vos stratégies de mise en cache et d'appliquer les résolutions les plus appropriées à votre charge de travail, telles que l'instrumentation des requêtes pour mesurer la mémoire et les performances. Les stratégies réelles que vous mettez en œuvre pour remplir et assurer la maintenance de votre cache dépendent des données que vos clients ont besoin de mettre en cache et des modèles d'accès à ces données. Par exemple, il est peu probable que vous utilisiez la même stratégie à la fois pour les recommandations personnalisées sur une application de streaming et pour les actualités tendances.
**[Ressources] : **
+ [Stratégies de mise en cache pour Memcached](Strategies.md)
+ [Caching Best Practices](https://aws.amazon.com/caching/best-practices/)
+ [Des performances à grande échelle avec le ElastiCache livre blanc Amazon](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)
## EP 4 : Comment votre charge de travail optimise-t-elle l'utilisation des ressources de mise en réseau et des connexions ?
**Introduction au niveau des questions :** ElastiCache pour Valkey, Memcached et Redis, les logiciels OSS sont pris en charge par de nombreux clients d'applications, et les implémentations peuvent varier. Vous devez comprendre la gestion de la mise en réseau et des connexions en place pour analyser l'impact potentiel sur les performances.
**Avantage au niveau de la question : **une utilisation efficace des ressources de mise en réseau peut améliorer l'efficacité des performances de votre cluster. Les recommandations suivantes peuvent réduire les demandes de mise en réseau et améliorer la latence et le débit du cluster.
+ **[Obligatoire]** Gérez les connexions à votre ElastiCache cluster de manière proactive.
+ Le regroupement des connexions dans l'application réduit la surcharge sur le cluster créée par l'ouverture et la fermeture de connexions. Surveillez le comportement de connexion sur Amazon à CloudWatch l'aide `CurrConnections` de et`NewConnections`.
+ Évitez les fuites de connexion en fermant correctement les connexions client, le cas échéant. Les stratégies de gestion des connexions consistent notamment à fermer correctement les connexions qui ne sont pas utilisées et à définir des délais d'expiration de connexion.
+ Pour les charges de travail Memcached, il existe une quantité configurable de mémoire réservée à la gestion des connexions appelée `memcached_connections_overhead`.
+ **[Pratique encore meilleure] **Compressez les objets volumineux pour réduire la mémoire et améliorer le débit du réseau.
+ La compression des données peut réduire le débit réseau requis (Gbit/s), mais augmente la charge de travail de l'application pour compresser et décompresser les données.
+ La compression réduit également la quantité de mémoire consommée par les touches.
+ En fonction des besoins de votre application, trouvez le juste équilibre entre le taux de compression et la vitesse de compression.
+ **[Ressources] : **
+ [ElastiCache - Banque de données mondiale](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [Paramètres spécifiques Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [ElastiCache la version 5.0.3 pour Redis OSS améliore la I/O manipulation pour améliorer les performances](https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-elasticache-for-redis-503-enhances-io-handling-to-boost-performance/)
+ [Métriques pour Valkey et Redis OSS](CacheMetrics.Redis.md)
+ [Configuration ElastiCache pour une meilleure disponibilité](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
## PE 5 : Comment gérez-vous l' and/or expulsion par suppression de clés ?
**Introduction au niveau des questions :** les charges de travail ont des exigences et un comportement attendu différents lorsqu'un nœud de cluster approche des limites de consommation de mémoire. ElastiCache a des politiques différentes pour gérer ces situations.
**Avantage au niveau de la question : **une gestion appropriée de la mémoire disponible et la compréhension des politiques d’expulsion permettent de prendre conscience du comportement du cluster lorsque les limites de mémoire de l'instance sont dépassées.
+ **[Obligatoire] **Instrumentez l'accès aux données pour déterminer la politique à appliquer. Identifiez une politique de mémoire maximale appropriée pour contrôler si et comment les expulsions sont effectuées sur le cluster.
+ L'expulsion se produit lorsque la mémoire maximale du cluster est consommée et qu'une politique est en place pour autoriser l'expulsion. Le comportement du cluster dans cette situation dépend de la politique d'expulsion spécifiée. Cette politique peut être gérée à l'aide du groupe de paramètres `maxmemory-policy` sur le cluster.
+ La politique par défaut `volatile-lru` libère de la mémoire en expulsant les clés dont le délai d'expiration est défini (valeur TTL). Les politiques les moins fréquemment utilisées (LFU) et les moins récemment utilisées (LRU) suppriment les clés en fonction de leur utilisation.
+ Pour les charges de travail Memcached, une politique LRU par défaut a été mise en place pour contrôler les expulsions sur chaque nœud. Le nombre d'expulsions sur votre ElastiCache cluster Amazon peut être surveillé à l'aide de la métrique Expulsions sur Amazon. CloudWatch
+ **[Pratique encore meilleure] **Normalisez le comportement de suppression de sorte à contrôler l'impact sur les performances de votre cluster afin d'éviter les goulets d'étranglement inattendus en matière de performances.
+ ElastiCache Pour les charges de travail Valkey et Redis OSS, lorsque vous supprimez explicitement des clés du cluster, cela `UNLINK` revient à supprimer les `DEL` clés spécifiées. Cependant, la commande effectue la récupération de mémoire proprement dite dans un thread différent, de sorte qu'elle ne bloque pas, contrairement à `DEL`. La suppression proprement dite se fera ultérieurement de manière asynchrone.
+ Pour les charges de travail de la ElastiCache version 6.x pour Redis OSS, le comportement de la `DEL` commande peut être modifié dans le groupe de paramètres à l'aide du paramètre. `lazyfree-lazy-user-del`
+ **[Ressources] : **
+ [Configuration des paramètres du moteur à l'aide de groupes de ElastiCache paramètres](ParameterGroups.md)
+ [UNLINK](https://valkey.io/commands/unlink/)
+ [Gestion financière dans le cloud avec AWS](https://aws.amazon.com/aws-cost-management/)
## PE 6 : Comment modélisez-vous les données et interagissez-vous avec celles-ci ElastiCache ?
**Introduction au niveau des questions :** ElastiCache dépend fortement de l'application des structures de données et du modèle de données utilisés, mais elle doit également prendre en compte le magasin de données sous-jacent (le cas échéant). Comprenez les structures de données disponibles et assurez-vous d'utiliser les structures de données les mieux adaptées à vos besoins.
**Avantage au niveau des questions :** la modélisation des données ElastiCache comporte plusieurs couches, notamment les cas d'utilisation des applications, les types de données et les relations entre les éléments de données. De plus, chaque type de données et chaque commande ont leurs propres signatures de performance bien documentées.
+ **[Meilleure pratique] **L'une des meilleures pratiques consiste à réduire la réécriture involontaire de données. Utilisez une convention de dénomination qui minimise le chevauchement des noms de clé. La dénomination conventionnelle de vos structures de données utilise une méthode hiérarchique telle que : `APPNAME:CONTEXT:ID`, par exemple : `ORDER-APP:CUSTOMER:123`.
**[Ressources] : **
+ [Key naming](https://docs.gitlab.com/ee/development/redis.html#key-naming)
+ **[Idéal]** ElastiCache pour Valkey et Redis, les commandes OSS ont une complexité temporelle définie par la notation Big O. Cette fois, la complexité d'une commande est une algorithmic/mathematical représentation de son impact. Lorsque vous introduisez un nouveau type de données dans votre application, vous devez examiner attentivement la complexité temporelle des commandes associées. Les commandes dont la complexité temporelle est O(1) sont constantes dans le temps et ne dépendent pas de la taille de l'entrée. Toutefois, les commandes dont la complexité temporelle est O(N) sont linéaires dans le temps et dépendent de la taille de l'entrée. En raison de la conception à thread unique de ElastiCache Valkey et Redis OSS, un volume important d'opérations complexes dans le temps entraînera une baisse des performances et des délais d'exécution potentiels.
**[Ressources] : **
+ [Commandes](https://valkey.io/commands/)
+ **[Idéal]** APIs À utiliser pour obtenir une visibilité de l'interface graphique sur le modèle de données de votre cluster.
**[Ressources] : **
+ [Commandant Redis OSS](https://www.npmjs.com/package/ElastiCache for Redis-commander)
+ [Navigateur Redis OSS](https://github.com/humante/redis-browser)
+ [Redsmin](https://www.redsmin.com/)
## PE 7 : Comment enregistrez-vous les commandes lentes dans votre ElastiCache cluster Amazon ?
**Introduction au niveau de la question : **l’optimisation des performances bénéficie à la capture, l'agrégation et la notification des commandes de longue durée. En comprenant le temps nécessaire à l'exécution des commandes, vous pouvez déterminer les commandes qui nuisent aux performances et celles qui empêchent le moteur de fonctionner de manière optimale. ElastiCache a également la capacité de transmettre ces informations à Amazon CloudWatch ou Amazon Kinesis Data Firehose.
**Avantage au niveau de la question : **la journalisation dans un emplacement permanent dédié et la fourniture d'événements de notification pour les commandes lentes peuvent faciliter l'analyse détaillée des performances et peuvent être utilisées pour déclencher des événements automatisés.
+ **[Obligatoire]** ElastiCache exécution d'un moteur Valkey 7.2 ou version ultérieure, ou exécution d'un moteur Redis OSS version 6.0 ou ultérieure, groupe de paramètres correctement configuré et journalisation SLOWLOG activée sur le cluster.
+ Les paramètres requis ne sont disponibles que lorsque la compatibilité des versions du moteur est définie sur Valkey 7.2 ou version ultérieure, ou sur Redis OSS version 6.0 ou supérieure.
+ La journalisation SLOWLOG se produit lorsque le temps d'exécution d'une commande par le serveur dépasse la valeur spécifiée. Le comportement du cluster dépend des paramètres du groupe de paramètres associés, qui sont `slowlog-log-slower-than` et `slowlog-max-len`.
+ Les modifications prennent effet immédiatement.
+ **[Mieux]** Tirez parti des fonctionnalités de CloudWatch Kinesis Data Firehose.
+ Utilisez les fonctionnalités de filtrage et d'alarme de CloudWatch CloudWatch Logs Insights et Amazon Simple Notification Services pour surveiller les performances et notifier les événements.
+ Utilisez les fonctionnalités de streaming de Kinesis Data Firehose pour archiver les journaux SLOWLOG dans un stockage permanent ou pour déclencher le réglage automatique des paramètres du cluster.
+ Déterminez quel format entre JSON et TEXT brut répond le mieux à vos besoins.
+ Fournissez les autorisations IAM pour publier sur Kinesis Data Firehose CloudWatch ou sur Kinesis Data Firehose.
+ **[Pratique encore meilleure] **Définissez `slowlog-log-slower-than` sur une valeur autre que la valeur par défaut.
+ Ce paramètre détermine la durée pendant laquelle une commande peut être exécutée dans le moteur Valkey ou Redis OSS avant d'être enregistrée en tant que commande lente. La valeur par défaut est 10 000 microsecondes (10 millisecondes). La valeur par défaut est peut-être trop élevée pour certaines charges de travail.
+ Déterminez une valeur plus adaptée à votre charge de travail en fonction des besoins de l'application et des résultats des tests ; toutefois, une valeur trop faible peut générer un volume de données excessif.
+ **[Pratique encore meilleure] ** Conservez `slowlog-max-len` comme valeur par défaut.
+ Ce paramètre détermine la limite supérieure du nombre de commandes lentes capturées dans la mémoire Valkey ou Redis OSS à un moment donné. La valeur 0 désactive effectivement la capture. Plus la valeur est élevée, plus le nombre d'entrées stockées en mémoire est élevé, ce qui réduit le risque d’expulsion d’informations importantes avant qu’elles aient pu être consultées. La valeur par défaut est 128.
+ La valeur par défaut convient à la plupart des charges de travail. S'il est nécessaire d'analyser les données dans une fenêtre temporelle étendue depuis le valkey-cli via la commande SLOWLOG, envisagez d'augmenter cette valeur. Cela permet à davantage de commandes de rester dans la mémoire de Valkey ou Redis OSS.
Si vous émettez les données SLOWLOG vers CloudWatch Logs ou Kinesis Data Firehose, les données seront conservées et pourront être analysées en dehors du système, ce qui réduit ElastiCache le besoin de stocker un grand nombre de commandes lentes dans la mémoire Valkey ou Redis OSS.
+ **[Ressources] : **
+ [Comment activer la journalisation lente dans un cluster ?](https://repost.aws/knowledge-center/elasticache-turn-on-slow-log)
+ [Livraison de journaux](Log_Delivery.md)
+ [Paramètres spécifiques à Redis OS](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/)Amazon CloudWatch
+ [Amazon Kinesis Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)
## PE8: Comment Auto Scaling contribue-t-il à améliorer les performances du ElastiCache cluster ?
**Introduction au niveau des questions :** en implémentant la fonctionnalité de mise à l'échelle automatique de Valkey ou Redis OSS, ElastiCache vos composants peuvent s'ajuster au fil du temps pour augmenter ou diminuer automatiquement les fragments ou les répliques souhaités. Pour ce faire, vous pouvez implémenter le suivi des cibles ou une politique de mise à l’échelle planifiée.
**Avantage au niveau des questions :** la compréhension et la planification des pics de charge de travail peuvent garantir des performances de mise en cache améliorées et la continuité des activités. ElastiCache Auto Scaling surveille en permanence l'utilisation de votre processeur et de votre mémoire pour s'assurer que votre cluster fonctionne aux niveaux de performance souhaités.
+ **[Obligatoire]** Lors du lancement d'un cluster ElastiCache pour Valkey ou Redis OSS :
1. Assurez-vous que le mode Cluster est activé.
1. Assurez-vous que l'instance appartient à une famille d'un certain type et d'une certaine taille qui prend en charge l’autoscaling.
1. Assurez-vous que le cluster ne s'exécute pas dans des entrepôts de données globaux, des outposts ou des zones locales.
**[Ressources] : **
+ [Mise à l'échelle des clusters dans Valkey et Redis OSS (mode cluster activé)](scaling-redis-cluster-mode-enabled.md)
+ [Utilisation de Auto Scaling avec des partitions](AutoScaling-Using-Shards.md)
+ [Utilisation d'Auto Scaling avec des réplicas](AutoScaling-Using-Replicas.md)
+ **[Meilleure pratique] **Déterminez si votre charge de travail est à lecture ou à écriture intensive pour définir une politique de mise à l’échelle. Pour de meilleures performances, utilisez une seule métrique de suivi. Il est recommandé de ne pas appliquer plusieurs politiques à chaque dimension. En effet, les stratégies d’autoscaling montent en puissance lorsque la cible est atteinte, mais ne sont mises à l’échelle horizontale que lorsque toutes les politiques de suivi des cibles sont prêtes à être mises à l’échelle horizontale.
**[Ressources] : **
+ [Politiques Auto Scaling](AutoScaling-Policies.md)
+ [Définition d'une politique de mise à l'échelle](AutoScaling-Scaling-Defining-Policy-API.md)
+ **[Meilleure pratique] **La surveillance des performances au fil du temps peut vous aider à détecter les modifications de la charge de travail qui passeraient inaperçues si elles étaient surveillées à un moment donné. Vous pouvez analyser les CloudWatch mesures correspondantes relatives à l'utilisation du cluster sur une période de quatre semaines afin de déterminer le seuil de valeur cible. Si vous n'êtes toujours pas sûr de la valeur à choisir, nous vous recommandons de commencer par une valeur de métrique prédéfinie minimale prise en charge.
**[Ressources] : **
+ [Surveillance de l'utilisation à l'aide de CloudWatch métriques](CacheMetrics.md)
+ **[Mieux]** Nous vous conseillons de tester votre application avec les charges de travail minimales et maximales attendues, afin d'identifier le nombre exact de charges shards/replicas requises pour que le cluster développe des politiques de dimensionnement et atténue les problèmes de disponibilité.
**[Ressources] : **
+ [Enregistrement d'une cible évolutive](AutoScaling-Register-Policy.md)
+ [Enregistrement d'une cible évolutive à l'aide du AWS CLI](AutoScaling-Scaling-Registering-Policy-CLI.md)
# Pilier d'optimisation des ElastiCache coûts d'objectif Amazon Well-Architected
Le pilier d'optimisation des coûts vise à éviter les coûts inutiles. Les sujets clés incluent la compréhension et le contrôle des dépenses, la sélection du type de nœud le plus approprié (utilisation d'instances qui prennent en charge la hiérarchisation des données en fonction des besoins de la charge de travail), le nombre approprié de types de ressources (nombre de réplicas en lecture), l'analyse des dépenses au fil du temps et la mise à l'échelle pour répondre aux besoins de l'entreprise sans dépenses excessives.
**Topics**
+ [COÛT 1 : Comment identifiez-vous et suivez-vous les coûts associés à vos ElastiCache ressources ? Comment développez-vous des mécanismes permettant aux utilisateurs de créer, gérer et supprimer les ressources créées ?](#CostOptimizationPillarCOST1)
+ [COÛT 2 : Comment utilisez-vous les outils de surveillance continue pour vous aider à optimiser les coûts associés à vos ElastiCache ressources ?](#CostOptimizationPillarCOST2)
+ [POC 3 : Devez-vous utiliser un type d'instance prenant en charge la hiérarchisation des données ? Quels sont les avantages de la hiérarchisation des données ? Quand ne pas utiliser les instances de hiérarchisation des données ?](#CostOptimizationPillarCOST3)
## COÛT 1 : Comment identifiez-vous et suivez-vous les coûts associés à vos ElastiCache ressources ? Comment développez-vous des mécanismes permettant aux utilisateurs de créer, gérer et supprimer les ressources créées ?
**Introduction au niveau de la question : **la compréhension des métriques de coût nécessite la participation et la collaboration de plusieurs équipes : ingénierie logicielle, gestion des données, propriétaires de produits, finances et direction. Pour identifier les principaux facteurs de coûts, toutes les parties concernées doivent comprendre les leviers de contrôle de l'utilisation des services et les compromis en matière de gestion des coûts. C'est ce qui différencie souvent les efforts d'optimisation des coûts réussis et moins réussis. En vous assurant que vous disposez de processus et d'outils pour suivre les ressources créées, du développement à la production et au retrait, vous pouvez gérer les coûts associés àElastiCache.
**Avantage au niveau des questions :** le suivi continu de tous les coûts associés à votre charge de travail nécessite une compréhension approfondie de l'architecture qui inclut ElastiCache l'un de ses composants. En outre, vous devez disposer d'un plan de gestion des coûts pour collecter et comparer l'utilisation par rapport à votre budget.
+ **[Obligatoire]** Créez un centre d'excellence cloud (CCoE) doté de l'une de ses chartes fondatrices pour définir, suivre et prendre des mesures en fonction des indicateurs relatifs à l'utilisation de votre organisationElastiCache . Si un CCo E existe et fonctionne, assurez-vous qu'il sait comment lire et suivre les coûts associés ElastiCache. Lorsque des ressources sont créées, utilisez les rôles et les politiques IAM pour vérifier que seuls des équipes et des groupes spécifiques peuvent instancier des ressources. Cela garantit que les coûts sont associés aux résultats commerciaux et qu'une ligne de responsabilité claire est établie, du point de vue des coûts.
1. CCoE doit identifier, définir et publier des indicateurs de coûts qui sont mis à jour régulièrement (mensuellement) en fonction de ElastiCache l'utilisation clé de données catégorielles telles que :
1. Types de nœuds utilisés et leurs attributs : standard ou à mémoire optimisée, instances à la demande ou réservées, régions et zones de disponibilité
1. Types d'environnements : libre, développement, test et production
1. Stratégies de stockage et de conservation des sauvegardes
1. Transfert de données au sein des régions et entre elles
1. Instances s’exécutant sur Amazon Outposts
1. CCoE se compose d'une équipe interfonctionnelle composée de représentants non exclusifs des équipes de génie logiciel, de gestion des données, de l'équipe produit, des finances et de direction de votre organisation.
**[Ressources] : **
+ [Create a Cloud Center of Excellence](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
+ [ ElastiCacheTarifs Amazon](https://aws.amazon.com/elasticache/pricing/)
+ **[Obligatoire] **Utilisez des balises de répartition des coûts pour suivre les coûts avec un faible niveau de granularité. Utilisez la gestion des AWS coûts pour visualiser, comprendre et gérer vos AWS coûts et votre utilisation au fil du temps.
1. Utilisez des balises pour organiser vos ressources et des balises de répartition des coûts pour suivre vos AWS coûts de manière détaillée. Après avoir activé les balises de répartition des coûts, AWS utilise les balises de répartition des coûts pour organiser les coûts des ressources dans votre rapport de répartition des coûts, afin de faciliter la catégorisation et le suivi de vos AWS coûts. AWS fournit deux types de balises de répartition des coûts : les balises AWS générées et les balises définies par l'utilisateur. AWS définit, crée et applique les balises AWS générées pour vous, et vous définissez, créez et appliquez des balises définies par l'utilisateur. Vous devez activer les deux types d'étiquettes séparément pour qu'elles apparaissent dans Cost Management ou sur un rapport de répartition des coûts.
1. Utilisez des balises de répartition des coûts pour organiser votre AWS facture afin de refléter votre propre structure de coûts. Lorsque vous ajoutez des balises de répartition des coûts à vos ressources sur Amazon ElastiCache, vous pouvez suivre les coûts en regroupant les dépenses sur vos factures par valeur d'étiquette de ressource. Vous devriez également envisager de combiner des balises pour suivre les coûts plus détaillés.
**[Ressources] : **
+ [Utilisation des balises AWS de répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [Surveillance des coûts avec des balises de répartition des coûts](Tagging.md)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ **[Mieux]** Connectez les ElastiCache coûts aux indicateurs qui concernent l'ensemble de l'organisation.
1. Prenez en compte les métriques commerciales ainsi que les métriques opérationnelles telles que la latence. Quels concepts de votre modèle commercial sont compréhensibles pour tous les rôles ? Les métriques doivent être compréhensibles par le plus grand nombre de rôles possible au sein de l'organisation.
1. Exemples : utilisateurs servis simultanément, latence maximale et moyenne par opération et par utilisateur, scores d'engagement des utilisateurs, taux de retour des utilisateursrates/week, session length/user, taux d'abandon, taux de réussite du cache et suivi des clés
**[Ressources] : **
+ [Surveillance de l'utilisation à l'aide de CloudWatch métriques](CacheMetrics.md)
+ **[Bon]** Maintenez une visibilité up-to-date architecturale et opérationnelle sur les indicateurs et les coûts sur l'ensemble de la charge de travail utilisée ElastiCache.
1. Comprenez l'ensemble de votre écosystème de solutions, qui fait ElastiCache généralement partie d'un écosystème complet de AWS services dans leur ensemble technologique, qu'il s'agisse des clients, d'API Gateway, de Redshift ou des QuickSight outils de reporting (par exemple).
1. Cartographiez les composants de votre solution (clients, connexions, sécurité, opérations en mémoire, stockage, automatisation des ressources, accès aux données et gestion des données) sur votre diagramme d'architecture. Chaque couche est connectée à l'ensemble de la solution et possède ses propres besoins et fonctionnalités qui contribuent à vous and/or aider à gérer le coût global.
1. Votre diagramme doit inclure l'utilisation du calcul, de la mise en réseau, du stockage, des politiques de cycle de vie, de la collecte de métriques ainsi que les ElastiCache éléments opérationnels et fonctionnels de votre application
1. Les exigences de votre charge de travail sont susceptibles d'évoluer au fil du temps et il est essentiel que vous continuiez à maintenir et à documenter votre compréhension des composants sous-jacents ainsi que de vos principaux objectifs fonctionnels afin de rester proactif dans la gestion des coûts de votre charge de travail.
1. Le soutien de la direction en matière de visibilité, de responsabilité, de priorisation et de ressources est essentiel pour que vous disposiez d'une stratégie de gestion des coûts efficace pour votre ElastiCache entreprise.
## COÛT 2 : Comment utilisez-vous les outils de surveillance continue pour vous aider à optimiser les coûts associés à vos ElastiCache ressources ?
**Introduction au niveau des questions :** vous devez rechercher un juste équilibre entre vos indicateurs de ElastiCache coût et de performance des applications. Amazon CloudWatch fournit une visibilité sur les indicateurs opérationnels clés qui peuvent vous aider à déterminer si vos ElastiCache ressources sont surutilisées ou sous-utilisées, par rapport à vos besoins. Du point de vue de l'optimisation des coûts, vous devez comprendre à quel moment vous êtes surapprovisionné et être en mesure de développer des mécanismes appropriés pour redimensionner vos ElastiCache ressources tout en maintenant vos besoins opérationnels, de disponibilité, de résilience et de performance.
**Avantage au niveau de la question : **dans l’idéal, vous aurez alloué suffisamment de ressources pour répondre aux besoins opérationnels de votre charge de travail et vous n’aurez pas de ressources sous-utilisées pouvant entraîner un état des coûts sous-optimal. Vous devez être en mesure d'identifier et d'éviter d'exploiter ElastiCache des ressources surdimensionnées pendant de longues périodes.
+ **[Obligatoire]** CloudWatch À utiliser pour surveiller vos ElastiCache clusters et analyser le lien entre ces indicateurs et vos tableaux de bord AWS Cost Explorer.
1. ElastiCache fournit à la fois des métriques au niveau de l'hôte (par exemple, l'utilisation du processeur) et des métriques spécifiques au logiciel du moteur de cache (par exemple, les mises en cache et les erreurs de cache). Ces métriques sont mesurées et publiées pour chaque nœud de cache toutes les 60 secondes.
1. ElastiCache les indicateurs de performance (CPUUtilization, EngineUtilization, SwapUsage CurrConnections, et évictions) peuvent indiquer que vous devez effectuer une mise à l'échelle up/down (utiliser des types de nœuds de larger/smaller cache) ou des in/out (add more/less partitions). Comprenez les implications financières des décisions de mise à l'échelle en créant une matrice stratégique qui estime les coûts supplémentaires et les délais minimum et maximum nécessaires pour atteindre les seuils de performance de vos applications.
**[Ressources] : **
+ [Surveillance de l'utilisation à l'aide de CloudWatch métriques](CacheMetrics.md)
+ [Quelles métriques dois-je surveiller ?](CacheMetrics.WhichShouldIMonitor.md)
+ [ ElastiCacheTarifs Amazon](https://aws.amazon.com/elasticache/pricing/)
+ **[Obligatoire] **Comprenez et documentez votre stratégie de sauvegarde et ses implications financières.
1. Avec ElastiCache, les sauvegardes sont stockées dans Amazon S3, qui fournit un stockage durable. Vous devez comprendre les implications financières liées à votre capacité à récupérer en cas de panne.
1. Activez les sauvegardes automatiques qui supprimeront les fichiers de sauvegarde qui dépassent la limite de conservation.
**[Ressources] : **
+ [Planification des sauvegardes automatiques](backups-automatic.md)
+ [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/)
+ **[Meilleure pratique] **Utilisez des nœuds réservés pour vos instances dans le cadre d'une stratégie délibérée visant à gérer les coûts liés à des charges de travail bien comprises et documentées. Des frais initiaux sont facturés pour les nœuds réservés en fonction du type de nœud et de la durée de réservation : un ou trois ans. Ces frais sont largement inférieurs aux frais d'utilisation horaire facturés pour les nœuds à la demande.
1. Vous devrez peut-être exploiter vos ElastiCache clusters à l'aide de nœuds à la demande jusqu'à ce que vous ayez collecté suffisamment de données pour estimer les exigences en matière d'instances réservées. Planifiez et documentez les ressources nécessaires pour répondre à vos besoins et comparez les coûts attendus selon les types d'instances (à la demande ou réservées)
1. Évaluez régulièrement les nouveaux types de nœuds de cache disponibles et déterminez s'il est judicieux, du point de vue des métriques de coût et opérationnelles, de migrer votre flotte d'instances vers de nouveaux types de nœuds de cache.
## POC 3 : Devez-vous utiliser un type d'instance prenant en charge la hiérarchisation des données ? Quels sont les avantages de la hiérarchisation des données ? Quand ne pas utiliser les instances de hiérarchisation des données ?
**Introduction au niveau de la question : **la sélection du type d'instance approprié peut non seulement avoir un impact sur les performances et le niveau de service, mais également un impact financier. Les types d'instances sont associés à des coûts différents. La sélection d'un ou de plusieurs types d'instances de grande taille capables de répondre à tous les besoins de stockage en mémoire peut s'avérer une décision naturelle. Cela pourrait toutefois avoir un impact financier important à mesure que le projet arrivera à maturité. Pour s'assurer que le type d'instance sélectionné est correct, il faut examiner périodiquement le temps d'inactivité de ElastiCache l'objet.
**Avantage au niveau de la question : **vous devez bien comprendre l'impact des différents types d'instances sur vos coûts actuels et futurs. Les modifications marginales ou périodiques de la charge de travail ne doivent pas entraîner de modifications disproportionnées des coûts. Si la charge de travail le permet, les types d'instances qui prennent en charge la hiérarchisation des données offrent un meilleur prix par stockage disponible. En raison du stockage SSD disponible par instance, les instances de hiérarchisation des données prennent en charge une capacité totale de données par instance bien supérieure.
+ **[Obligatoire] **Comprenez les limites des instances de hiérarchisation des données :
1. Disponible uniquement ElastiCache pour les clusters Valkey ou Redis OSS.
1. Seuls certains types d'instances prennent en charge la hiérarchisation des données.
1. Seule ElastiCache la version 6.2 pour Redis OSS et versions ultérieures est prise en charge
1. Les éléments volumineux ne sont pas échangés sur le SSD. Les objets supérieurs à 128 Mio sont conservés en mémoire.
**[Ressources] : **
+ [Mise à niveau des données](data-tiering.md)
+ [ ElastiCacheTarifs Amazon](https://aws.amazon.com/elasticache/pricing/)
+ **[Obligatoire] **Déterminez quel pourcentage de votre base de données est régulièrement consulté par votre charge de travail.
1. Les instances de hiérarchisation des données sont idéales pour les charges de travail qui accèdent souvent à une petite partie de votre jeu de données global, mais qui nécessitent tout de même un accès rapide aux données restantes. En d'autres termes, le rapport entre les données chaudes et chaudes est d'environ 20:80.
1. Développez le suivi du temps d'inactivité des objets au niveau du cluster.
1. Il est judicieux d’utiliser des implémentations à grande échelle de plus de 500 Go de données.
+ **[Obligatoire]**Sachez que les instances de hiérarchisation des données ne sont pas facultatives pour certaines charges de travail.
1. L'accès à des objets moins fréquemment utilisés entraîne un faible coût en termes de performances, car ceux-ci sont échangés sur un SSD local. Si votre application est sensible au temps de réponse, testez l'impact sur votre charge de travail.
1. Elles ne conviennent pas aux caches qui stockent principalement des objets volumineux d'une taille supérieure à 128 Mio.
**[Ressources] : **
+ [Limites](data-tiering.md#data-tiering-prerequisites)
+ **[Meilleure pratique] **Les types d'instances réservées prennent en charge la hiérarchisation des données. Cela garantit le coût le plus bas en termes de quantité de stockage de données par instance.
1. Vous devrez peut-être exploiter vos ElastiCache clusters à l'aide d'instances autres que la hiérarchisation des données jusqu'à ce que vous ayez une meilleure compréhension de vos besoins.
1. Analysez le modèle d'utilisation des données de vos ElastiCache clusters.
1. Créez une tâche automatisée qui collecte régulièrement le temps d'inactivité des objets.
1. Si vous remarquez qu'un pourcentage élevé (environ 80 %) d'objets sont inactifs pendant une période jugée appropriée à votre charge de travail, documentez les résultats et suggérez de migrer le cluster vers des instances prenant en charge la hiérarchisation des données.
1. Évaluez régulièrement les nouveaux types de nœuds de cache disponibles et déterminez s'il est judicieux, du point de vue des métriques de coût et opérationnelles, de migrer votre flotte d'instances vers de nouveaux types de nœuds de cache.
**[Ressources] : **
+ [OBJECT IDLETIME](https://valkey.io/commands/object-idletime/)
+ [ ElastiCacheTarifs Amazon](https://aws.amazon.com/elasticache/pricing/)
# Étapes de dépannage courantes et meilleures pratiques avec ElastiCache
Les rubriques suivantes fournissent des conseils de résolution des erreurs et des problèmes que vous pourriez rencontrer lors de l'utilisation ElastiCache. Si vous rencontrez un problème qui n’est pas répertorié ici, vous pouvez utiliser le bouton de commentaire sur cette page pour le signaler.
Pour obtenir des conseils de dépannage supplémentaires et des réponses aux questions d'assistance les plus courantes, consultez le [centre de AWS connaissances](https://aws.amazon.com/premiumsupport/knowledge-center/)
**Topics**
+ [Problèmes de connexion](#wwe-troubleshooting.connection)
+ [Erreurs du client Valkey ou Redis OSS](#wwe-troubleshooting.clienterrors)
+ [Résolution des problèmes de latence élevée en mode ElastiCache Serverless](#wwe-troubleshooting.latency)
+ [Résolution des problèmes de régulation dans Serverless ElastiCache](#wwe-troubleshooting.throttling)
+ [Problèmes de connexion persistants](TroubleshootingConnections.md)
+ [Rubriques connexes](#wwe-troubleshooting.related)
## Problèmes de connexion
Si vous ne parvenez pas à vous connecter à votre ElastiCache cache, envisagez l'une des solutions suivantes :
1. **Utilisation du protocole TLS :** si votre connexion est bloquée lorsque vous essayez de vous connecter à votre ElastiCache point de terminaison, il se peut que vous n'utilisiez pas le protocole TLS dans votre client. Si vous utilisez ElastiCache Serverless, le chiffrement en transit est toujours activé. Assurez-vous que votre client utilise le protocole TLS pour se connecter au cache. [En savoir plus sur la connexion à un cache compatible TLS](connect-tls.md).
1. **VPC :** les ElastiCache caches ne sont accessibles que depuis un VPC. Assurez-vous que l' EC2 instance à partir de laquelle vous accédez au cache et le ElastiCache cache sont créés dans le même VPC. Vous devez également activer le [peering VPC entre](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) le VPC où EC2 réside votre instance et le VPC dans lequel vous créez votre cache.
1. **Groupes de sécurité :** ElastiCache utilise des groupes de sécurité pour contrôler l'accès à votre cache. Éléments à prendre en compte :
1. Assurez-vous que le groupe de sécurité utilisé par votre ElastiCache cache autorise l'accès entrant à celui-ci depuis votre EC2 instance. Cliquez [ici](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) pour savoir comment configurer correctement les règles de trafic entrant dans votre groupe de sécurité.
1. Assurez-vous que le groupe de sécurité utilisé par votre ElastiCache cache autorise l'accès aux ports de votre cache (6379 et 6380 pour les serveurs sans serveur, et 6379 par défaut pour les clusters basés sur des nœuds). ElastiCache utilise ces ports pour accepter les commandes Valkey ou Redis OSS. Pour en savoir plus sur la configuration de l'accès aux ports, [cliquez ici](set-up.md#elasticache-install-grant-access-VPN).
Si la connexion continue d'être difficile, consultez [Problèmes de connexion persistants](TroubleshootingConnections.md) les autres étapes.
## Erreurs du client Valkey ou Redis OSS
ElastiCache Le mode Serverless n'est accessible qu'à l'aide de clients prenant en charge le protocole en mode cluster Valkey ou Redis OSS. Les clusters basés sur des nœuds sont accessibles depuis les clients dans l'un ou l'autre mode, en fonction de la configuration du cluster.
Si vous rencontrez des erreurs dans votre client, prenez en compte les points suivants :
1. **Mode cluster :** si vous rencontrez des erreurs CROSSLOT ou des erreurs avec la commande [SELECT](https://valkey.io/commands/select/), vous essayez peut-être d'accéder à un cache activé en mode cluster avec un client Valkey ou Redis OSS qui ne prend pas en charge le protocole Cluster. ElastiCache Serverless ne prend en charge que les clients qui prennent en charge le protocole de cluster Valkey ou Redis OSS. Si vous souhaitez utiliser Valkey ou Redis OSS en mode « Cluster Disabled » (CMD), vous devez créer un cluster basé sur des nœuds.
1. **Erreurs CROSSLOT :** si vous rencontrez cette `ERR CROSSLOT Keys in request don't hash to the same slot` erreur, vous tentez peut-être d'accéder à des clés qui n'appartiennent pas au même emplacement dans un cache en mode cluster. Pour rappel, ElastiCache Serverless fonctionne toujours en mode cluster. Les opérations multiclés, les transactions ou les scripts Lua impliquant plusieurs clés ne sont autorisés que si toutes les clés impliquées se trouvent dans le même emplacement de hachage.
Pour connaître les meilleures pratiques supplémentaires concernant la configuration des clients Valkey ou Redis OSS, veuillez consulter ce [billet de blog](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/).
## Résolution des problèmes de latence élevée en mode ElastiCache Serverless
Si votre charge de travail semble présenter une latence élevée, vous pouvez analyser les `SuccessfulWriteRequestLatency` métriques CloudWatch `SuccessfulReadRequestLatency` et pour vérifier si la latence est liée au mode ElastiCache Serverless. Ces mesures mesurent la latence interne à ElastiCache Serverless. La latence côté client et les temps de trajet réseau entre votre client et le point de terminaison ElastiCache sans serveur ne sont pas inclus.
**Résolution des problèmes de latence côté client**
Si vous remarquez une latence élevée côté client, mais aucune augmentation correspondante, `` CloudWatch `SuccessfulReadRequestLatency` et si `SuccessfulWriteRequestLatency` des mesures mesurent la latence côté serveur, tenez compte des points suivants :
+ **Assurez-vous que le groupe de sécurité autorise l'accès aux ports 6379 et 6380 :** ElastiCache Serverless utilise le port 6379 pour le point de terminaison principal et le port 6380 pour le point de terminaison du lecteur. Certains clients établissent une connectivité aux deux ports pour chaque nouvelle connexion, même si votre application n'utilise pas la fonctionnalité Read from Replica. Si votre groupe de sécurité n'autorise pas l'accès entrant aux deux ports, l'établissement de la connexion peut prendre plus de temps. Pour en savoir plus sur la configuration de l'accès aux ports, [cliquez ici](set-up.md#elasticache-install-grant-access-VPN).
**Résolution des problèmes de latence côté serveur**
Une certaine variabilité et des pics occasionnels ne devraient pas être une source de préoccupation. Toutefois, si les `Average` statistiques indiquent une forte augmentation et persistent, vous devriez consulter le Personal Health Dashboard Tableau de bord Health et votre Personal Health Dashboard pour plus d'informations. Si nécessaire, pensez à ouvrir un étui de support avec Support.
Tenez compte des meilleures pratiques et stratégies suivantes pour réduire le temps de latence :
+ **Activer la lecture depuis une réplique :** si votre application le permet, nous vous recommandons d'activer la fonctionnalité « Lire depuis une réplique » dans votre client Valkey ou Redis OSS afin de dimensionner les lectures et de réduire la latence. Lorsqu'il est activé, ElastiCache Serverless tente d'acheminer vos demandes de lecture vers des nœuds de cache répliqués situés dans la même zone de disponibilité (AZ) que votre client, évitant ainsi la latence du réseau inter-AZ. Notez que l'activation de la fonctionnalité Read from Replica dans votre client signifie que votre application accepte une éventuelle cohérence des données. Votre application peut recevoir des données plus anciennes pendant un certain temps si vous essayez de les lire après avoir écrit sur une clé.
+ **Assurez-vous que votre application est déployée au même endroit AZs que votre cache :** vous pouvez observer une latence plus élevée côté client si votre application n'est pas déployée au même AZs endroit que votre cache. Lorsque vous créez un cache sans serveur, vous pouvez fournir les sous-réseaux à partir desquels votre application va accéder au cache, et ElastiCache Serverless crée des points de terminaison VPC dans ces sous-réseaux. Assurez-vous que votre application est déployée dans le même environnement AZs. Dans le cas contraire, votre application risque de subir un saut cross-AZ lors de l'accès au cache, ce qui augmentera la latence côté client.
+ **Réutilisation des connexions : les** demandes ElastiCache sans serveur sont effectuées via une connexion TCP compatible TLS à l'aide du protocole RESP. L'établissement de la connexion (y compris l'authentification de la connexion, si elle est configurée) prend du temps, de sorte que la latence de la première demande est supérieure à la normale. Les requêtes via une connexion déjà initialisée offrent une ElastiCache faible latence constante. Pour cette raison, vous devez envisager d'utiliser le regroupement de connexions ou de réutiliser les connexions Valkey ou Redis OSS existantes.
+ **Vitesse de mise à l'échelle :** ElastiCache Serverless évolue automatiquement à mesure que votre taux de demandes augmente. Une augmentation soudaine et importante du taux de requêtes, plus rapide que la vitesse à laquelle ElastiCache Serverless évolue, peut entraîner une latence élevée pendant un certain temps. ElastiCache Les applications sans serveur peuvent généralement augmenter rapidement le taux de demandes prises en charge, ce qui prend jusqu'à 10 à 12 minutes pour doubler le taux de demandes.
+ **Inspectez les commandes de longue durée :** certaines commandes Valkey ou Redis OSS, notamment les scripts Lua ou les commandes sur de grandes structures de données, peuvent s'exécuter pendant une longue période. Pour identifier ces commandes, ElastiCache publie des métriques au niveau des commandes. Avec [ElastiCache Serverless](serverless-metrics-events-redis.md#serverless-metrics), vous pouvez utiliser les `BasedECPUs` métriques.
+ **Demandes limitées : lorsque les demandes** sont limitées en mode ElastiCache Serverless, vous pouvez constater une augmentation de la latence côté client dans votre application. [Lorsque les demandes sont limitées dans ElastiCache Serverless, vous devriez constater une augmentation de la `ThrottledRequests` ElastiCache métrique Serverless.](serverless-metrics-events-redis.md#serverless-metrics) Consultez la section ci-dessous pour résoudre les problèmes liés aux demandes limitées.
+ **Distribution uniforme des clés et des requêtes :** dans ElastiCache Valkey et Redis OSS, une répartition inégale des clés ou des demandes par emplacement peut entraîner un hot slot, ce qui peut entraîner une latence élevée. ElastiCache Serverless prend en charge jusqu'à 30 000 ECPUs/second (90 000 en ECPUs/second cas d'utilisation de Read from Replica) sur un seul emplacement, dans une charge de travail qui exécute des commandes simples. SET/GET Nous vous recommandons d'évaluer la distribution de vos clés et de vos demandes entre les emplacements et de garantir une distribution uniforme si votre taux de demandes dépasse cette limite.
## Résolution des problèmes de régulation dans Serverless ElastiCache
Dans les architectures orientées services et les systèmes distribués, la limitation de la vitesse à laquelle les appels d'API sont traités par les différents composants du service est appelée limitation. Cela atténue les pics, contrôle les incohérences dans le débit des composants et permet des restaurations plus prévisibles en cas d'événement opérationnel inattendu. ElastiCache Le mode Serverless est conçu pour ces types d'architectures, et la plupart des clients Valkey ou Redis OSS proposent des tentatives intégrées pour les demandes limitées. Un certain degré de limitation ne constitue pas nécessairement un problème pour votre application, mais la limitation persistante d'une partie sensible à la latence de votre flux de données peut avoir un impact négatif sur l'expérience utilisateur et réduire l'efficacité globale du système.
[Lorsque les demandes sont limitées dans ElastiCache Serverless, vous devriez constater une augmentation de la `ThrottledRequests` ElastiCache métrique Serverless.](serverless-metrics-events-redis.md#serverless-metrics) Si vous constatez un nombre élevé de demandes limitées, tenez compte des points suivants :
+ **Vitesse de mise à l'échelle :** le mode ElastiCache sans serveur évolue automatiquement à mesure que vous ingérez de nouvelles données ou que vous augmentez le taux de demandes. Si votre application évolue plus rapidement que la vitesse à laquelle le mode ElastiCache sans serveur évolue, vos demandes peuvent être limitées tandis ElastiCache que le mode sans serveur évolue en fonction de votre charge de travail. ElastiCache Le mode Serverless permet généralement d'augmenter rapidement la taille de stockage, en doublant la taille de stockage de votre cache en 10 à 12 minutes.
+ **Distribution uniforme des clés et des demandes :** dans ElastiCache Valkey et Redis OSS, une répartition inégale des clés ou des demandes par emplacement peut entraîner un hot slot. Un hot slot peut entraîner une limitation du nombre de demandes si le taux de demandes pour un seul emplacement dépasse 30 000 ECPUs/second et s'il s'agit d'une charge de travail qui exécute des commandes simples. SET/GET De même, ElastiCache pour Memcached, un raccourci clavier peut entraîner une limitation du nombre de demandes si le taux de requêtes dépasse 30 000 €/seconde. ECPUs
+ **Lire depuis une réplique :** si votre application le permet, pensez à utiliser la fonction « Lire depuis une réplique ». La plupart des clients Valkey ou Redis OSS peuvent être configurés pour « dimensionner les lectures » afin de diriger les lectures vers des nœuds de réplication. Cette fonctionnalité vous permet de dimensionner le trafic de lecture. En outre, ElastiCache Serverless achemine automatiquement la lecture depuis les demandes de réplication vers les nœuds situés dans la même zone de disponibilité que votre application, ce qui permet de réduire le temps de latence. Lorsque Read from Replica est activé, vous pouvez atteindre jusqu'à 90 000 points ECPUs/second sur un seul emplacement, pour des charges de travail utilisant de simples SET/GET commandes.
# Problèmes de connexion persistants
Les éléments suivants doivent être vérifiés lors de la résolution des problèmes de connectivité persistants avec ElastiCache :
**Topics**
+ [Groupes de sécurité](#Security_groups)
+ [Réseau ACLs](#Network_ACLs)
+ [Tables de routage](#Route_tables)
+ [Résolution DNS](#DNS_Resolution)
+ [Identification des problèmes liés aux diagnostics côté serveur](#Diagnostics)
+ [Validation de connectivité réseau](#Connectivity)
+ [Limites liées au réseau](#Network-limits)
+ [Utilisation de l'UC](#CPU-Usage)
+ [Connexions résiliées côté serveur](#Connections-server)
+ [Résolution des problèmes côté client pour les instances Amazon EC2](#Connections-client)
+ [Disséquer le temps nécessaire pour compléter une seule demande](#Dissecting-time)
## Groupes de sécurité
Les groupes de sécurité sont des pare-feux virtuels qui protègent votre ElastiCache client (EC2 instance, AWS Lambda fonction, conteneur Amazon ECS, etc.) et votre ElastiCache cache. Les groupes de sécurité sont avec état, ce qui signifie qu'une fois le trafic entrant ou sortant autorisé, les réponses pour ce trafic seront automatiquement autorisées dans le contexte de ce groupe de sécurité spécifique.
La fonction avec état exige que le groupe de sécurité suive constamment toutes les connexions autorisées, et il existe une limite pour les connexions suivies. Si la limite est atteinte, les nouvelles connexions échoueront. Reportez-vous à la section de résolution des problèmes pour savoir comment déterminer si les limites ont été atteintes du côté du client ou du ElastiCache côté du client.
Vous pouvez avoir un seul groupe de sécurité attribué en même temps au client et au ElastiCache cluster, ou des groupes de sécurité individuels pour chacun d'entre eux.
Dans les deux cas, vous devez autoriser le trafic sortant TCP sur le ElastiCache port depuis la source et le trafic entrant sur le même port à destination. ElastiCache Le port par défaut est 11211 pour Memcached et 6379 pour Valkey ou Redis OSS. Par défaut, les groupes de sécurité autorisent la totalité du trafic sortant. Dans ce cas, seule la règle entrante dans le groupe de sécurité cible est requise.
Pour plus d'informations, consultez [Modèles d'accès pour accéder à un ElastiCache cluster dans un Amazon VPC](elasticache-vpc-accessing.md).
## Réseau ACLs
Les listes de contrôle d'accès réseau (ACLs) sont des règles apatrides. Le trafic doit être autorisé dans les deux sens (entrant et sortant) pour réussir. ACLs Les réseaux sont affectés à des sous-réseaux, et non à des ressources spécifiques. Il est possible que la même ACL soit assignée ElastiCache et que la même ressource client soit affectée, surtout s'ils se trouvent dans le même sous-réseau.
Par défaut, le réseau ACLs autorise tout le trafic. Toutefois, il est possible de les personnaliser pour refuser ou autoriser le trafic. En outre, l'évaluation des règles ACL est séquentielle, ce qui signifie que la règle avec le nombre le plus bas correspondant au trafic l'autorisera ou le refusera. La configuration minimale pour autoriser le trafic Valkey ou Redis OSS est la suivante :
ACL réseau côté client :
+ **Règles entrantes :**
+ Numéro de règle : de préférence inférieur à toute règle de refus ;
+ Type : Règle TCP personnalisée ;
+ Protocole : TCP
+ Plage de ports : 1024-65535
+ Source : 0.0.0.0/0 (ou créez des règles individuelles pour les sous-réseaux du cluster) ElastiCache
+ Autoriser/Refuser : Autoriser
+ **Règles sortantes :**
+ Numéro de règle : de préférence inférieur à toute règle de refus ;
+ Type : Règle TCP personnalisée ;
+ Protocole : TCP
+ Plage de ports : 6379
+ Source : 0.0.0.0/0 (ou les sous-réseaux du ElastiCache cluster. (N'oubliez pas que l'utilisation de produits spécifiques IPs peut créer des problèmes en cas de basculement ou de dimensionnement du cluster)
+ Autoriser/Refuser : Autoriser
ElastiCache ACL réseau :
+ **Règles entrantes :**
+ Numéro de règle : de préférence inférieur à toute règle de refus ;
+ Type : Règle TCP personnalisée ;
+ Protocole : TCP
+ Plage de ports : 6379
+ Source : 0.0.0.0/0 (ou créez des règles individuelles pour les sous-réseaux du cluster) ElastiCache
+ Autoriser/Refuser : Autoriser
+ **Règles sortantes :**
+ Numéro de règle : de préférence inférieur à toute règle de refus ;
+ Type : Règle TCP personnalisée ;
+ Protocole : TCP
+ Plage de ports : 1024-65535
+ Source : 0.0.0.0/0 (ou les sous-réseaux du ElastiCache cluster. (N'oubliez pas que l'utilisation de produits spécifiques IPs peut créer des problèmes en cas de basculement ou de dimensionnement du cluster)
+ Autoriser/Refuser : Autoriser
Pour plus d'informations, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html).
## Tables de routage
Comme dans le cas du réseau ACLs, chaque sous-réseau peut avoir des tables de routage différentes. Si les clients et le ElastiCache cluster se trouvent dans des sous-réseaux différents, assurez-vous que leurs tables de routage leur permettent de communiquer entre eux.
Les environnements plus complexes, impliquant plusieurs VPCs routeurs dynamiques ou pare-feux réseau, peuvent s'avérer difficiles à dépanner. Veuillez consulter [Validation de connectivité réseau](#Connectivity) pour confirmer que vos paramètres réseau sont appropriés.
## Résolution DNS
ElastiCache fournit les points de terminaison du service en fonction des noms DNS. Les points de terminaison disponibles sont `Configuration`, `Primary`, `Reader` et `Node`. Pour plus d'informations, voir [Recherche de points de terminaison de connexion](Endpoints.md).
En cas de basculement ou de modification de cluster, l'adresse associée au nom du point de terminaison peut changer et sera automatiquement mise à jour.
Les paramètres DNS personnalisés (c'est-à-dire ceux qui n'utilisent pas le service DNS VPC) ne connaissent peut-être pas les noms DNS ElastiCache fournis. Assurez-vous que votre système parvient à résoudre les ElastiCache points de terminaison à l'aide d'outils système tels que `dig` (comme indiqué ci-dessous) ou`nslookup`.
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4
```
Vous pouvez également forcer la résolution de noms via le service DNS VPC :
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4
```
## Identification des problèmes liés aux diagnostics côté serveur
CloudWatch les métriques et les informations d'exécution du ElastiCache moteur sont des sources ou informations courantes permettant d'identifier les sources potentielles de problèmes de connexion. Une bonne analyse commence généralement par les éléments suivants :
+ Utilisation du processeur : Valkey et Redis OSS sont des applications multithread. Cependant, l'exécution de chaque commande se produit dans un seul thread (principal). Pour cette raison, ElastiCache fournit les métriques `CPUUtilization` et`EngineCPUUtilization`. `EngineCPUUtilization`fournit l'utilisation du processeur dédiée au processus Valkey ou Redis OSS, et `CPUUtilization` l'utilisation dans tous les v. CPUs Les nœuds dotés de plusieurs vCPU ont généralement des valeurs différentes pour `CPUUtilization` et`EngineCPUUtilization`, la seconde étant généralement plus élevée. Une `EngineCPUUtilization` élevée peut être causée par un nombre élevé de requêtes ou d'opérations complexes qui prennent beaucoup de temps d'UC à finaliser. Vous pouvez identifier les deux avec les éléments suivants :
+ Nombre élevé de demandes : recherchez des augmentations sur d'autres métriques correspondant au modèle `EngineCPUUtilization`. Les métriques utiles sont les suivantes :
+ `CacheHits` et `CacheMisses` : le nombre de demandes réussies ou de demandes qui n'ont pas trouvé d'élément valide dans le cache. Si le ratio des manquements par rapport aux résultats est élevé, l'application perd du temps et des ressources avec des demandes infructueuses.
+ `SetTypeCmds` et `GetTypeCmds` : ces métriques en corrélation avec `EngineCPUUtilization` peuvent aider à comprendre si la charge est significativement plus élevée pour les demandes d'écriture, mesurées par `SetTypeCmds`, ou les lectures, mesurées par `GetTypeCmds`. Si la charge est principalement composée de lectures, l'utilisation de plusieurs réplicas en lecture peut équilibrer les demandes sur plusieurs nœuds et épargner le principal pour les écritures. Dans les clusters désactivés en mode cluster, l'utilisation de répliques en lecture peut être effectuée en créant une configuration de connexion supplémentaire dans l'application à l'aide du point de terminaison du lecteur. ElastiCache Pour plus d'informations, voir [Recherche de points de terminaison de connexion](Endpoints.md). Les opérations de lecture doivent être soumises à cette connexion supplémentaire. Les opérations d'écriture seront effectuées via le point de terminaison principal normal. En mode cluster activé, il est conseillé d'utiliser une bibliothèque qui prend en charge les réplicas en lecture de façon native. Avec les bons indicateurs, la bibliothèque sera en mesure de découvrir automatiquement la topologie du cluster, les nœuds de réplication, d'activer les opérations de [lecture via la commande READONLY](https://valkey.io/commands/readonly) Valkey ou Redis OSS et de soumettre les demandes de lecture aux répliques.
+ Nombre élevé de connexions :
+ `CurrConnections` et `NewConnections` : `CurrConnection` est le nombre de connexions établies au moment de la collectie de données, tandis que`NewConnections` indique le nombre de connexions créées au cours de la période.
La création et la gestion des connexions impliquent une surcharge d'UC importante. En outre, la connexion en trois temps TCP requise pour créer des connexions affectera négativement les temps de réponse globaux.
Un ElastiCache nœud avec des milliers `NewConnections` par minute indique qu'une connexion est créée et utilisée par quelques commandes seulement, ce qui n'est pas optimal. Le fait de maintenir les connexions établies et de les réutiliser pour de nouvelles opérations est une bonne pratique. Ceci est possible lorsque l'application client prend en charge et implémente correctement le regroupement de connexions ou les connexions persistantes. Avec le regroupement de connexions, le nombre de `currConnections` n'a pas de grandes variations et les `NewConnections` doivent être aussi faibles que possible. Valkey et Redis OSS offrent des performances optimales avec un petit nombre de CurrConnections. En maintenant currConnection dans l'ordre de dizaines ou de centaines, on minimise l'utilisation des ressources nécessaires à la prise en charge des connexions individuelles, comme les tampons client et les cycles d'UC pour servir la connexion.
+ Débit réseau :
+ Déterminez la bande passante : la bande passante du réseau des ElastiCache nœuds est proportionnelle à la taille du nœud. Comme les applications ont des caractéristiques différentes, les résultats peuvent varier en fonction de la charge de travail. Par exemple, les applications avec un nombre élevé de petites demandes ont tendance à affecter davantage l'utilisation de l'UC que le débit réseau, tandis que les clés plus grandes provoqueront une utilisation plus élevée du réseau. Pour cette raison, il est conseillé de tester les nœuds avec la charge de travail réelle pour une meilleure compréhension des limites.
La simulation de la charge à partir de l'application donnerait des résultats plus précis. Cependant, les outils de référence peuvent donner une bonne idée des limites.
+ Dans les cas où les requêtes sont principalement des lectures, l'utilisation de réplicas pour les opérations de lecture allégera la charge sur le nœud primaire. Si le cas d'utilisation est principalement des écritures, l'utilisation de nombreux réplicas amplifiera l'utilisation du réseau. Pour chaque octet écrit sur le nœud primaire, N octets seront envoyés aux réplicas, N étant le nombre de réplicas. La meilleure pratique pour les charges de travail intensives en écriture consiste à utiliser ElastiCache Redis OSS avec le mode cluster activé afin que les écritures puissent être équilibrées sur plusieurs partitions ou être étendues à un type de nœud offrant davantage de capacités réseau.
+ Les CloudWatchmetrics `NetworkBytesIn` et `NetworkBytesOut` indiquent la quantité de données entrant ou sortant du nœud, respectivement. `ReplicationBytes`est le trafic dédié à la réplication des données.
Pour de plus amples informations, veuillez consulter [Limites liées au réseau](#Network-limits).
+ Commandes complexes : les commandes Redis OSS sont diffusées sur un seul thread, ce qui signifie que les demandes sont traitées de manière séquentielle. Une seule commande lente peut affecter d'autres demandes et connexions, aboutissant ainsi à des délais d'expiration. L'utilisation de commandes qui agissent sur plusieurs valeurs, clés ou types de données doit être effectuée avec soin. Les connexions peuvent être bloquées ou interrompues en fonction du nombre de paramètres ou de la taille de ses valeurs d'entrée ou de sortie.
Un exemple bien connu est la commande `KEYS`. Il balaie le keyspace entier en recherchant un modèle donné et bloque l'exécution d'autres commandes lors de son exécution. Redis OSS utilise la notation « Big O » pour décrire la complexité de ses commandes.
La commande de clés a une complexité temporelle O(N), N étant le nombre de clés dans la base de données. Par conséquent, plus le nombre de clés est grand, plus la commande sera lente. `KEYS` peut causer des problèmes de différentes manières : si aucun modèle de recherche n'est utilisé, la commande retournera tous les noms de clés disponibles. Dans les bases de données contenant des milliers ou des millions d'éléments, une sortie énorme sera créée et inondera les tampons réseau.
Si un modèle de recherche est utilisé, seules les clés correspondant au modèle seront retournées au client. Cependant, le moteur balaie toujours le keyspace entier pour le rechercher, et le temps nécessaire pour finaliser la commande sera le même.
Une alternative pour `KEYS` est la commande `SCAN`. Elle itère sur le keyspace et limite les itérations dans un nombre spécifique d'éléments, en évitant les blocs prolongés sur le moteur.
L'analyse dispose du paramètre `COUNT`, utilisé pour définir la taille des blocs d'itération. La valeur par défaut est de 10 (10 éléments par itération).
Selon le nombre d'éléments dans la base de données, les petits blocs de valeur `COUNT` nécessitent plus d'itérations pour effectuer une analyse complète, tandis que des valeurs plus grandes garderont le moteur occupé plus longtemps à chaque itération. Alors que les petites valeurs de nombre ralentiront `SCAN` sur les grandes bases de données, des valeurs plus grandes peuvent causer les mêmes problèmes que ceux mentionnés pour `KEYS`.
À titre d'exemple, l'exécution de la commande `SCAN` avec la valeur de nombre 10 nécessite 100 000 répétitions sur une base de données avec 1 million de clés. Si le temps de transmission aller-retour moyen du réseau est de 0,5 milliseconde, environ 50 000 millisecondes (50 secondes) seront consacrées au transfert de demandes.
D'autre part, si la valeur de comptage était de 100 000, une seule itération serait nécessaire et seulement 0,5 ms serait dépensé pour le transférer. Cependant, le moteur serait complètement bloqué pour d'autres opérations jusqu'à ce que la commande ait fini de balayer tout le keyspace.
En outre `KEYS`, plusieurs autres commandes sont potentiellement nuisibles si elles ne sont pas utilisées correctement. Pour voir la liste de toutes les commandes et leur complexité temporelle respective, accédez aux commandes [Valkey et Redis OSS](https://valkey.io/commands).
Exemples de problèmes potentiels :
+ Scripts Lua : Valkey et Redis OSS fournissent un interpréteur Lua intégré, permettant l'exécution de scripts côté serveur. Les scripts Lua sur Valkey et Redis OSS sont exécutés au niveau du moteur et sont atomiques par définition, ce qui signifie qu'aucune autre commande ou script ne sera autorisé à s'exécuter pendant qu'un script est en cours d'exécution. Les scripts Lua offrent la possibilité d'exécuter plusieurs commandes, algorithmes de prise de décision, analyse de données, etc. directement sur le moteur. Alors que l'atomicité des scripts et les chances de décharger l'application sont tentantes, les scripts doivent être utilisés avec prudence et pour de petites opérations. ElastiCacheActivé, le temps d'exécution des scripts Lua est limité à 5 secondes. Les scripts qui n'ont pas été écrits dans le keyspace seront automatiquement résiliés après la période de 5 secondes. Pour éviter la corruption des données et les incohérences, le nœud basculera si l'exécution du script n'a pas été terminée en 5 secondes et a eu une écriture pendant son exécution. Les [transactions](https://valkey.io/topics/transactions) sont l'alternative pour garantir la cohérence des multiples modifications clés associées dans Redis OSS. Une transaction permet l'exécution d'un bloc de commandes, en surveillant les clés existantes pour les modifications. Si l'une des clés surveillées change avant la fin de la transaction, toutes les modifications sont supprimées.
+ Suppression en masse d'éléments : la commande `DEL` accepte plusieurs paramètres, qui sont les noms de clés à supprimer. Les opérations de suppression sont synchrones et prennent beaucoup de temps d'UC si la liste des paramètres est volumineuse ou contient une liste, un ensemble, un ensemble trié ou un hachage de grande taille (structures de données contenant plusieurs sous-éléments). En d'autres termes, même la suppression d'une seule clé peut prendre beaucoup de temps si elle comporte de nombreux éléments. L'alternative à `DEL` is est `UNLINK` une commande asynchrone disponible depuis Redis OSS 4. `UNLINK`doit être préféré dans la `DEL` mesure du possible. À partir ElastiCache de Redis OSS 6x, le `lazyfree-lazy-user-del` paramètre fait en sorte que la `DEL` commande se comporte comme si `UNLINK` elle était activée. Pour plus d'informations, consultez la section [Modifications des paramètres de Redis OSS 6.0](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
+ Commandes agissant sur plusieurs clés : `DEL` a été mentionné précédemment comme une commande qui accepte plusieurs arguments et son temps d'exécution sera directement proportionnel à cela. Cependant, Redis OSS fournit de nombreuses autres commandes qui fonctionnent de la même manière. À titre d'exemple, `MSET` et `MGET` permettent l'insertion ou la récupération de plusieurs clés de chaîne à la fois. Leur utilisation peut être bénéfique pour réduire la latence réseau inhérente à plusieurs commandes `SET` ou `GET`. Cependant, une liste exhaustive de paramètres affectera l'utilisation de l'UC.
Bien que l'utilisation de l'UC seule ne soit pas la cause des problèmes de connectivité, passer trop de temps pour traiter une seule ou quelques commandes sur plusieurs clés peut provoquer l'échec d'autres demandes et augmenter l'utilisation globale de l'UC.
Le nombre de clés et leur taille affecteront la complexité de la commande et, par conséquent, le temps d'exécution.
Autres exemples de commandes qui peuvent agir sur plusieurs clés : `HMGET`, `HMSET`, `MSETNX`, `PFCOUNT`, `PFMERGE`, `SDIFF`, `SDIFFSTORE`, `SINTER`, `SINTERSTORE`, `SUNION`, `SUNIONSTORE`, `TOUCH`, `ZDIFF`, `ZDIFFSTORE`, `ZINTER` ou `ZINTERSTORE`.
+ Commandes agissant sur plusieurs types de données : Redis OSS fournit également des commandes qui agissent sur une ou plusieurs touches, quel que soit leur type de données. ElastiCache pour Redis OSS fournit la métrique permettant `KeyBasedCmds` de surveiller ces commandes. Cette métrique additionne l'exécution des commandes suivantes dans la période sélectionnée :
+ Complexité O(N) :
+ `KEYS`
+ O(1)
+ `EXISTS`
+ `OBJECT`
+ `PTTL`
+ `RANDOMKEY`
+ `TTL`
+ `TYPE`
+ `EXPIRE`
+ `EXPIREAT`
+ `MOVE`
+ `PERSIST`
+ `PEXPIRE`
+ `PEXPIREAT`
+ `UNLINK (O(N)` pour récupérer de la mémoire. Cependant, la tâche de récupération de mémoire se produit dans un thread séparé et ne bloque pas le moteur
+ Différents temps de complexité en fonction du type de données :
+ `DEL`
+ `DUMP`
+ `RENAME` est considéré comme une commande avec une complexité O(1), mais exécute `DEL` en interne. Le temps d'exécution varie en fonction de la taille de la clé renommée.
+ `RENAMENX`
+ `RESTORE`
+ `SORT`
+ Gros hachages : le hachage est un type de données qui autorise une seule clé avec plusieurs sous-éléments clé-valeur. Chaque hachage peut stocker 4 294 967 295 éléments et les opérations sur de gros hachages peuvent devenir coûteuses. De même que pour `KEYS`, les hachages ont la commande `HKEYS` avec une complexité temporelle O(N), N étant le nombre d'éléments dans le hachage. `HSCAN` doit avoir la préférence sur `HKEYS` pour éviter les commandes à exécution longue. `HDEL`, `HGETALL`, `HMGET`, `HMSET` et `HVALS` sont des commandes qui doivent être utilisées avec prudence sur les gros hachages.
+ Autres structures big data : outre les hachages, d'autres structures de données peuvent être intensives en UC. Les ensembles, les listes, les ensembles triés et les Hyperloglogs peuvent également prendre beaucoup de temps à être manipulés en fonction de leur taille et des commandes utilisées. Pour plus d'informations sur ces commandes, consultez les commandes [Valkey et Redis OSS](https://valkey.io/commands).
## Validation de connectivité réseau
Après avoir examiné les configurations réseau liées à la résolution DNS, aux groupes de sécurité, au réseau et aux tables de routage ACLs, la connectivité peut être validée à l'aide de l'Analyzer de Reachability VPC et des outils système.
Reachability Analyzer testera la connectivité réseau et confirmera que toutes les exigences et autorisations sont satisfaites. Pour les tests ci-dessous, vous aurez besoin de l'ENI ID (Elastic Network Interface Identification) de l'un des ElastiCache nœuds disponibles dans votre VPC. Vous pouvez le trouver en procédant comme suit :
1. Passer à la [https://console.aws.amazon.com/ec2/version 2/home ? \$1NIC :](https://console.aws.amazon.com/ec2/v2/home?#NIC)
1. Filtrez la liste des interfaces en fonction du nom de votre ElastiCache cluster ou de l'adresse IP obtenue lors des validations DNS précédentes.
1. Notez ou enregistrez l'ID ENI. Si plusieurs interfaces sont affichées, consultez la description pour vérifier qu'elles appartiennent au bon ElastiCache cluster et choisissez-en une.
1. Passez à l'étape suivante.
1. Créer un parcours d'analyse [https://console.aws.amazon.com/vpc/chez vous ? ](https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer)\$1 ReachabilityAnalyzer et choisissez les options suivantes :
+ **Type de source** : Choisissez l'**instance** si votre ElastiCache client fonctionne sur une EC2 instance Amazon ou une **interface réseau** (s'il utilise un autre service, tel qu' AWS Fargate Amazon ECS avec le réseau awsvpc AWS Lambda, etc.), et l'ID de ressource correspondant (EC2 instance ou ID ENI) ;
+ **Type de destination** : choisissez **Network Interface (Interface réseau)** et sélectionnez l'**ENI Elasticache** dans la liste.
+ **Port de destination** : spécifiez 6379 ElastiCache pour Redis OSS ou 11211 pour ElastiCache Memcached. Ce sont les ports définis avec la configuration par défaut et cet exemple suppose qu'ils ne sont pas modifiés.
+ **Protocole** : TCP
Créez le chemin d'analyse et attendez le résultat quelques instants. Si le statut n'est pas accessible, ouvrez les détails de l'analyse et veuillez consulter l'**explorateur d'analyse** pour plus de détails sur les cas où les demandes ont été bloquées
Si les tests d'accessibilité aboutissent, passez à la vérification au niveau du système d'exploitation.
Pour valider la connectivité TCP sur le port de ElastiCache service : sur Amazon Linux, elle `Nping` est disponible dans le package `nmap` et permet de tester la connectivité TCP sur le ElastiCache port, tout en fournissant le temps d'aller-retour entre le réseau et l'établissement de la connexion. Utilisez-le pour valider la connectivité réseau et la latence actuelle du ElastiCache cluster, comme indiqué ci-dessous :
```
$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )
Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds
```
Par défaut, `nping` envoie 5 sondes avec un délai de 1 seconde entre elles. Vous pouvez utiliser l'option « -c » pour augmenter le nombre de sondes et « --delay » pour modifier la durée avant l'envoi d'un nouveau test.
Si les tests avec `nping` échouent et si les tests *VPC Reachability Analyzer* aboutissent, demandez à votre administrateur système d'examiner les règles de pare-feu basées sur l'hôte, les règles de routage asymétrique ou toute autre restriction possible au niveau du système d'exploitation.
Sur la ElastiCache console, vérifiez si le **chiffrement en transit** est activé dans les détails de votre ElastiCache cluster. Si le chiffrement en transit est activé, vérifiez si la session TLS peut être établie à l'aide de la commande suivante :
```
openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379
```
Une sortie étendue est attendue si la connexion et la négociation TLS aboutissent. Vérifiez le code de retour disponible sur la dernière ligne, la valeur doit être `0 (ok)`. [Si openssl renvoie quelque chose de différent, vérifiez la raison de l'erreur sur https://www.openssl.org/docs/man1.0.2/man1/verify.html \$1DIAGNOSTICS.](https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS)
Si tous les tests d'infrastructure et de système d'exploitation ont réussi mais que votre application ne parvient toujours pas à se connecter ElastiCache, vérifiez si les configurations de l'application sont conformes aux ElastiCache paramètres. Les erreurs les plus courantes sont les suivantes :
+ Votre application ne prend pas en charge le mode ElastiCache cluster et le mode cluster ElastiCache est activé ;
+ Votre application ne prend pas en charge le protocole TLS/SSL et le chiffrement en transit ElastiCache est activé ;
+ L'application prend en charge TLS/SSL mais ne dispose pas des indicateurs de configuration appropriés ni des autorités de certification fiables ;
## Limites liées au réseau
+ Nombre maximal de connexions : il existe des limites strictes pour les connexions simultanées. Chaque ElastiCache nœud permet jusqu'à 65 000 connexions simultanées entre tous les clients. Cette limite peut être surveillée à l'aide `CurrConnections` des métriques activées CloudWatch. Cependant, les clients ont également leurs limites pour les connexions sortantes. Sous Linux, vérifiez la plage de ports éphémères autorisée à l'aide de la commande :
```
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
```
Dans l'exemple précédent, 28231 connexions seront autorisées à partir de la même source, vers la même adresse IP de destination (ElastiCache nœud) et le même port. La commande suivante indique le nombre de connexions existantes pour un ElastiCache nœud spécifique (IP 1.2.3.4) :
```
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l
```
Si le nombre est trop élevé, votre système peut devenir surchargé en essayant de traiter les demandes de connexion. Il est conseillé d'envisager d'implémenter des techniques telles que le regroupement de connexions ou les connexions persistantes pour mieux gérer les connexions. Dans la mesure du possible, configurez le groupe de connexions pour limiter le nombre maximal de connexions à quelques centaines. En outre, une logique d'interruptions exponentielles pour gérer les expirations de délai d'attente ou d'autres exceptions de connexion serait souhaitable pour éviter l'abandon de connexion en cas de problème.
+ Limites du trafic réseau : vérifiez les [CloudWatch indicateurs suivants pour Redis OSS](CacheMetrics.Redis.md) afin d'identifier les limites réseau possibles sur le ElastiCache nœud :
+ `NetworkBandwidthInAllowanceExceeded` / `NetworkBandwidthOutAllowanceExceeded` : paquets réseau formés parce que le débit dépassait la limite de bande passante agrégée.
Il est important de noter que chaque octet écrit sur le nœud primaire sera répliqué sur N réplicas, N étant le nombre de réplicas. Les clusters avec de petits types de nœuds, plusieurs réplicas et des demandes d'écriture intensives peuvent ne pas être en mesure de faire face à l'arriéré de réplication. Dans de tels cas, la bonne pratique consiste à effectuer une augmentation d'échelle (changer le type de nœud), une évolutivité horizontale (ajouter des partitions dans des clusters activés en mode cluster), de réduire le nombre de réplicas ou de réduire le nombre d'écritures.
+ `NetworkConntrackAllowanceExceeded` : paquets formés, car le nombre maximal de connexions suivies dans tous les groupes de sécurité affectés au nœud a été dépassé. Les nouvelles connexions échoueront probablement pendant cette période.
+ `NetworkPackets PerSecondAllowanceExceeded` : nombre maximal de paquets par seconde dépassé. Les charges de travail basées sur un taux élevé de très petites demandes peuvent atteindre cette limite avant la bande passante maximale.
Les mesures ci-dessus sont le moyen idéal de confirmer que les nœuds atteignent leurs limites réseau. Cependant, les limites sont également identifiables par des plateaux sur les métriques du réseau.
Si les plateaux sont observés pendant des périodes prolongées, ils seront probablement suivis d'un retard de réplication, d'une augmentation des octets utilisés pour le cache, d'une chute de la mémoire libérable, d'une hausse des échanges et de l'utilisation de l'UC. EC2 Les instances Amazon ont également des limites réseau qui peuvent être suivies grâce aux [métriques des pilotes ENA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html). Les instances Linux avec prise en charge réseaux améliorée et les pilotes ENA version 2.2.10 ou plus récente peuvent consulter les compteurs de limite avec la commande suivante :
```
# ethtool -S eth0 | grep "allowance_exceeded"
```
## Utilisation de l'UC
La métrique d'utilisation du processeur est le point de départ de l'enquête, et les éléments suivants peuvent aider à réduire les éventuels problèmes ElastiCache secondaires :
+ Redis OSS SlowLogs : La configuration ElastiCache par défaut conserve les 128 dernières commandes dont l'exécution a pris plus de 10 millisecondes. L'historique des commandes lentes est conservé pendant l'exécution du moteur et sera perdu en cas d'échec ou de redémarrage. Si la liste atteint 128 entrées, les anciens événements seront supprimés pour faire de la place aux nouveaux. La taille de la liste des événements lents et le temps d'exécution considéré comme lent peuvent être modifiés via les paramètres `slowlog-max-len` et `slowlog-log-slower-than` dans un [groupe de paramètres personnalisé](ParameterGroups.md). La liste des journaux lents peut être récupérée en exécutant `SLOWLOG GET 128` sur le moteur, 128 étant les 128 dernières commandes lentes signalées. Chaque entrée contient les champs suivants :
```
1) 1) (integer) 1 -----------> Sequential ID
2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
3) (integer) 4823378 -----> Time in microseconds to complete the command.
4) 1) "keys" -------------> Command
2) "*" ----------------> Arguments
5) "1.2.3.4:57004"-> Source
```
L'événement ci-dessus s'est produit le 26 décembre à 19:26:07 UTC, a pris 4,8 secondes (4 823 ms) et a été causé par la commande `KEYS` demandée auprès du client 1.2.3.4.
Sous Linux, l'horodatage peut être converti avec la date de commande :
```
$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020
```
Avec Python :
```
>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)
```
Ou sous Windows avec PowerShell :
```
PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime : 12/26/2020 7:26:07 PM
UtcDateTime
: 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date : 12/26/2020 12:00:00 AM
Day : 26
DayOfWeek
: Saturday
DayOfYear : 361
Hour : 19
Millisecond : 0
Minute : 26
Month
: 12
Offset : 00:00:00Ticks : 637446075670000000
UtcTicks
: 637446075670000000
TimeOfDay : 19:26:07
Year : 2020
```
Beaucoup de commandes lentes dans un court laps de temps (même minute ou moins) sont une source de préoccupation. Examinez la nature des commandes et la façon dont elles peuvent être optimisées (voir les exemples précédents). Si des commandes avec une complexité temporelle O(1) sont fréquemment signalées, vérifiez les autres facteurs d'utilisation élevée de l'UC mentionnés précédemment.
+ Métriques de latence : ElastiCache pour Redis, OSS fournit CloudWatch des métriques pour surveiller la latence moyenne pour différentes classes de commandes. Le point de données est calculé en divisant le nombre total d'exécutions de commandes dans la catégorie par le temps total d'exécution de la période. Il est important de comprendre que les résultats des métriques de latence sont un agrégat de commandes multiples. Une seule commande peut entraîner des résultats inattendus, tels que des délais d'expiration, sans impact significatif sur les métriques. Dans de tels cas, les événements de journaux lents constitueraient une source d'information plus précise. La liste suivante contient les métriques de latence disponibles et les commandes correspondantes qui les affectent.
+ EvalBasedCmdsLatency: lié aux commandes Lua Script,`eval`, ; `evalsha`
+ GeoSpatialBasedCmdsLatency: `geodist`, `geohash`, `geopos`, `georadius`, `georadiusbymember`, `geoadd`;
+ GetTypeCmdsLatency: commandes de lecture, quel que soit le type de données ;
+ HashBasedCmdsLatency: `hexists`, `hget`, `hgetall`, `hkeys`, `hlen`, `hmget`, `hvals`, `hstrlen`, `hdel`, `hincrby`, `hincrbyfloat`, `hmset`, `hset`, `hsetnx`;
+ HyperLogLogBasedCmdsLatency: `pfselftest`, `pfcount`, `pfdebug`, `pfadd`, `pfmerge`;
+ KeyBasedCmdsLatency: commandes qui peuvent agir sur différents types de données :`dump`,`exists`,`keys`,`object`,`pttl`,,`randomkey`,`ttl`,`type`,`del`,`expire`,`expireat`,`move`,`persist`,`pexpire`,`pexpireat`,,`rename`,`renamenx`,`restoreK`,`sort`, `unlink` ;
+ ListBasedCmdsLatency: lindex, len, lrange, blpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, roplpush, rpush, rpushx ;
+ PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe ;
+ SetBasedCmdsLatency: `scard`, `sdiff`, `sinter`, `sismember`, `smembers`, `srandmember`, `sunion`, `sadd`, `sdiffstore`, `sinterstore`, `smove`, `spop`, `srem`, `sunionstore`;
+ SetTypeCmdsLatency: écrire des commandes, quel que soit le type de données ;
+ SortedSetBasedCmdsLatency: `zcard`, `zcount`, `zrange`, `zrangebyscore`, `zrank`, `zrevrange`, `zrevrangebyscore`, `zrevrank`, `zscore`, `zrangebylex`, `zrevrangebylex`, `zlexcount`, `zadd`. `zincrby`, `zinterstore`, `zrem`, `zremrangebyrank`, `zremrangebyscore`, `zunionstore`, `zremrangebylex`, `zpopmax`, `zpopmin`, `bzpopmin`, `bzpopmax`;
+ StringBasedCmdsLatency: `bitcount`, `get`, `getbit`, `getrange`, `mget`, `strlen`, `substr`, `bitpos`, `append`, `bitop`, `bitfield`, `decr`, `decrby`, `getset`, `incr`, `incrby`, `incrbyfloat`, `mset`, `msetnx`, `psetex`, `set`, `setbit`, `setex`, `setnx`, `setrange`;
+ StreamBasedCmdsLatency: `xrange`, `xrevrange`, `xlen`, `xread`, `xpending`, `xinfo`, `xadd`, `xgroup`, `readgroup`, `xack`, `xclaim`, `xdel`, `xtrim`, `xsetid`;
+ Commandes d'exécution de Redis OSS :
+ info commandstats : fournit une liste des commandes exécutées depuis le démarrage du moteur, leur nombre cumulé d'exécutions, leur durée d'exécution totale et le temps d'exécution moyen par commande ;
+ client list : fournit une liste des clients actuellement connectés et des informations pertinentes comme l'utilisation des tampons, la dernière commande exécutée, etc.
+ Sauvegarde et réplication : ElastiCache pour les versions de Redis OSS antérieures à 2.8.22, utilisez un processus bifurqué pour créer des sauvegardes et effectuer des synchronisations complètes avec les répliques. Cette méthode peut entraîner une surcharge de mémoire importante pour les cas d'utilisation intensifs en écriture.
À partir de ElastiCache Redis OSS 2.8.22, une méthode de sauvegarde et de réplication sans fourche a AWS été introduite. La nouvelle méthode peut retarder les écritures afin d'éviter les échecs. Les deux méthodes peuvent provoquer des périodes d'utilisation de l'UC plus élevée, conduire à des temps de réponse plus élevés et, par conséquent, conduire à des délais d'attente du client pendant leur exécution. Vérifiez toujours si les échecs du client se produisent pendant la fenêtre de sauvegarde ou si la métrique `SaveInProgress` était de 1 au cours de la période. Il est conseillé de planifier la fenêtre de sauvegarde pour les périodes de faible utilisation afin de minimiser les risques de problèmes avec les clients ou d'échecs de sauvegarde.
## Connexions résiliées côté serveur
La configuration par défaut ElastiCache de Redis OSS maintient les connexions client établies indéfiniment. Toutefois, dans certains cas, la résiliation de la connexion peut être souhaitable. Par exemple :
+ Les bogues dans l'application client peuvent entraîner l'oubli de connexions et leur maintien avec un état inactif. C'est ce que l'on appelle une « fuite de connexion » et sa conséquence est une augmentation constante du nombre de connexions établies observées sur les métriques `CurrConnections`. Ce comportement peut entraîner une saturation du ElastiCache côté ou du client. Lorsqu'une solution immédiate n'est pas possible du côté client, certains administrateurs définissent une valeur de « délai d'attente » dans leur groupe de ElastiCache paramètres. Le délai d'expiration est le temps, en secondes, autorisé pour que les connexions inactives persistent. Si le client ne soumet aucune demande pendant cette période, le moteur mettra fin à la connexion dès que la connexion atteindra le délai d'expiration. De petites valeurs de délai d'expiration peuvent entraîner des déconnexions inutiles et les clients devront les gérer correctement et se reconnecter, ce qui entraîne des retards.
+ La mémoire utilisée pour stocker les clés est partagée avec les tampons client. Les clients lents avec des demandes ou des réponses importantes peuvent exiger une quantité importante de mémoire pour gérer ses tampons. La valeur par défaut ElastiCache pour les configurations Redis OSS ne limite pas la taille des tampons de sortie clients ordinaires. Si la limite `maxmemory` est atteinte, le moteur essaiera d'expulser les éléments pour remplir l'utilisation de la mémoire tampon. Dans des conditions de mémoire extrêmement limitées, ElastiCache Redis OSS peut choisir de déconnecter les clients qui consomment de grandes quantités de mémoire tampon de sortie afin de libérer de la mémoire et de préserver l'intégrité du cluster.
Il est possible de limiter la taille des tampons client avec des configurations personnalisées et les clients atteignant la limite seront déconnectés. Cependant, les clients devraient être en mesure de gérer des déconnexions inattendues. Les paramètres permettant de gérer la taille des tampons pour les clients réguliers sont les suivants :
+ client-query-buffer-limit: taille maximale d'une seule demande d'entrée ;
+ client-output-buffer-limit- normal-soft-limit : Limite souple pour les connexions client. La connexion sera interrompue si elle reste au-dessus de la limite souple pendant plus de temps que le temps en secondes défini sur client-output-buffer-limit - normal-soft-seconds ou si elle atteint la limite stricte ;
+ client-output-buffer-limit- normal-soft-seconds : Durée autorisée pour les connexions dépassant le client-output-buffer-limit - normal-soft-limit ;
+ client-output-buffer-limit- normal-hard-limit : Une connexion atteignant cette limite sera immédiatement interrompue.
Outre les tampons clients classiques, les options suivantes contrôlent la mémoire tampon pour les nœuds de réplication et les clients Pub/Sub (Publish/Subscribe) :
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-replica-soft-seconds;
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-pubsub-soft-limit;
+ client-output-buffer-limit-pubsub-soft-seconds;
+ client-output-buffer-limit-pubsub-hard-limit;
## Résolution des problèmes côté client pour les instances Amazon EC2
La charge et la réactivité du côté client peuvent également affecter les demandes adressées à ElastiCache. EC2 les limites des instances et du système d'exploitation doivent être soigneusement examinées lors de la résolution des problèmes de connectivité intermittents ou de temporisation. Quelques points clés à observer :
+ UC :
+ EC2 utilisation du processeur de l'instance : assurez-vous que le processeur n'est pas saturé ou qu'il n'est pas presque saturé à 100 %. L'analyse historique peut être effectuée via CloudWatch, mais gardez à l'esprit que la granularité des points de données est de 1 minute (avec la surveillance détaillée activée) ou de 5 minutes ;
+ Si vous utilisez des [ EC2 instances burstable](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html), assurez-vous que le solde créditeur de leur processeur n'a pas été épuisé. Ces informations sont disponibles sur la `CPUCreditBalance` CloudWatch métrique.
+ De courtes périodes d'utilisation élevée du processeur peuvent entraîner des délais d'attente sans que cela ne se répercute sur une utilisation à 100 %. CloudWatch De tels cas nécessitent une surveillance en temps réel avec des outils de système d'exploitation tels que `top`, `ps` et `mpstat`.
+ Réseau
+ Vérifiez si le débit réseau est inférieur à des valeurs acceptables en fonction des capacités de l'instance. Pour plus d'informations, consultez [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/)
+ Sur les instances avec le pilote réseau amélioré `ena`, cochez la case [ena statistics (statistiques ena)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-ena.html#statistics-ena) pour les délais d'expiration ou les limites dépassés. Les statistiques suivantes sont utiles pour confirmer la saturation des limites réseau :
+ `bw_in_allowance_exceeded` / `bw_out_allowance_exceeded` : nombre de paquets formés en raison d'un débit entrant ou sortant excessif ;
+ `conntrack_allowance_exceeded` : nombre de paquets abandonnés en raison de [limites de suivi de connexion](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#connection-tracking-throttling) des groupes de sécurité. Les nouvelles connexions échouent lorsque cette limite est saturée ;
+ `linklocal_allowance_exceeded` : nombre de paquets abandonnés en raison de requêtes excessives vers des métadonnées d'instance, NTP via VPC DNS. La limite est de 1 024 paquets par seconde pour tous les services ;
+ `pps_allowance_exceeded` : nombre de paquets abandonnés en raison d'un rapport excessif de paquets par seconde. La limite PPS peut être atteinte lorsque le trafic réseau consiste en des milliers ou des millions de très petites requêtes par seconde. ElastiCache le trafic peut être optimisé pour mieux utiliser les paquets réseau via des pipelines ou des commandes qui effectuent plusieurs opérations à la fois, par exemple `MGET` au lieu de`GET`.
## Disséquer le temps nécessaire pour compléter une seule demande
+ Sur le réseau : `Tcpdump` et `Wireshark` (tshark sur la ligne de commande) sont des outils pratiques qui permettent de comprendre combien de temps il a fallu à la demande pour parcourir le réseau, atteindre le ElastiCache moteur et obtenir un retour. L'exemple suivant met en évidence une demande unique créée à l'aide de la commande suivante :
```
$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG
```
Parallèlement à la commande ci-dessus, tcpdump était en exécution et retourné :
```
$ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
> 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
```
À partir de la sortie ci-dessus, nous pouvons confirmer que la connexion en trois temps TCP a été terminée en 222 microsecondes (918 091 - 917 869) et que la commande ping a été envoyée et retournée en 173 microsecondes (918 295 - 918 122).
Il a fallu 438 microsecondes (918 307 - 917 869) entre la demande et la fermeture de la connexion. Ces résultats confirmeraient que les temps de réponse du réseau et du moteur sont bons et que l'enquête peut se concentrer sur d'autres composants.
+ Sur le système d'exploitation : `Strace` peut contribuer à identifier les écarts de temps au niveau du système d'exploitation. L'analyse des applications réelles serait beaucoup plus étendue et des profileurs d'applications ou des débogueurs spécialisés sont conseillés. L'exemple suivant montre simplement si les composants du système d'exploitation de base fonctionnent comme prévu, sinon une enquête plus approfondie peut s'avérer nécessaire. En utilisant la même `PING` commande Redis OSS, `strace` nous obtenons :
```
$ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
(+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
(+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
(+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
(Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
(+ 0.003569) +++ exited with 0 +++
```
Dans l'exemple ci-dessus, la commande a pris un peu plus de 54 millisecondes (752 110 - 697 712 = 54 398 microsecondes).
Un temps important, environ 20 ms, était nécessaire pour instancier nc et effectuer la résolution de nom (de 697 712 à 717 890). Ensuite, 2 ms ont été nécessaires pour créer le socket TCP (745 659 à 747 858), et 0,4 ms (747 858 à 748 330) pour envoyer et recevoir la réponse à la demande.
## Rubriques connexes
+ [ElastiCache meilleures pratiques et stratégies de mise en cache](BestPractices.md)