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. # Comprendre la réplication MemoryDB MemoryDB implémente la réplication avec des données partitionnées sur un maximum de 500 partitions. Chaque partition d'un cluster possède un seul nœud read/write principal et jusqu'à 5 nœuds de réplication en lecture seule. Chaque nœud principal peut supporter jusqu'à 100 Mo/s. Vous pouvez créer un cluster avec un plus grand nombre de partitions et un nombre inférieur de répliques, pour un total de 500 nœuds par cluster. Cette configuration de cluster peut aller de 500 partitions et 0 répliques à 100 partitions et 4 répliques, soit le nombre maximum de répliques autorisées. # Cohérence Dans MemoryDB, les nœuds principaux sont très cohérents. Les opérations d'écriture réussies sont stockées de manière durable dans des journaux transactionnels multi-AZ distribués avant d'être renvoyées aux clients. Les opérations de lecture sur les primaires renvoient toujours le plus de up-to-date données reflétant les effets de toutes les opérations d'écriture réussies précédentes. Cette forte cohérence est préservée lors des basculements principaux. Dans MemoryDB, les nœuds de réplication sont finalement cohérents. Les opérations de lecture à partir de répliques (à l'aide d'une `READONLY` commande) ne reflètent pas toujours les effets des dernières opérations d'écriture réussies, les métriques de décalage étant publiées sur CloudWatch. Cependant, les opérations de lecture à partir d'une seule réplique sont cohérentes de manière séquentielle. Les opérations d'écriture réussies prennent effet sur chaque réplique dans l'ordre dans lequel elles ont été exécutées sur la réplique principale. ## Réplication dans un cluster Chaque réplique de lecture d'une partition conserve une copie des données provenant du nœud principal de la partition. Des mécanismes de réplication asynchrones utilisant les journaux de transactions sont utilisés pour maintenir les répliques lues synchronisées avec les répliques principales. 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épliques de lecture améliorent l'évolutivité de la lecture. Comme MemoryDB stocke les données dans des journaux de transactions durables, il n'y a aucun risque de perte de données. Les données sont partitionnées entre les partitions d'un cluster MemoryDB. Les applications utilisent le point de *terminaison du cluster* MemoryDB pour se connecter aux nœuds du cluster. Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison de connexion](endpoints.md). Les clusters MemoryDB sont régionaux et ne peuvent contenir que des nœuds d'une seule région. Pour améliorer la tolérance aux pannes, vous devez approvisionner les serveurs principaux et lire les répliques dans plusieurs zones de disponibilité au sein de cette région. L'utilisation de la réplication, qui fournit le mode multi-AZ, est fortement recommandée pour tous les clusters MemoryDB. Pour de plus amples informations, veuillez consulter [Minimiser les temps d'arrêt dans MemoryDB avec Multi-AZ](autofailover.md). # Minimiser les temps d'arrêt dans MemoryDB avec Multi-AZ Dans un certain nombre de cas, MemoryDB peut 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é. La réponse à une défaillance d'un nœud dépend du nœud défaillant. Cependant, dans tous les cas, MemoryDB garantit qu'aucune donnée n'est perdue lors du remplacement ou du basculement des nœuds. Par exemple, si une réplique échoue, le nœud défaillant est remplacé et les données sont synchronisées à partir du journal des transactions. En cas de défaillance du nœud principal, un basculement est déclenché vers une réplique cohérente, ce qui garantit qu'aucune donnée n'est perdue pendant le basculement. Les écritures sont désormais effectuées depuis le nouveau nœud principal. L'ancien nœud principal est ensuite remplacé et synchronisé à partir du journal des transactions. Si un nœud principal tombe en panne sur une partition à nœud unique (pas de répliques), MemoryDB cesse d'accepter les écritures jusqu'à ce que le nœud principal soit remplacé et synchronisé à partir du journal des transactions. Le remplacement du nœud peut entraîner un certain temps d'arrêt pour le cluster, mais si Multi-AZ est actif, le temps d'arrêt est minimisé. Le rôle du nœud principal basculera automatiquement vers l'une des répliques. Il n'est pas nécessaire de créer et de provisionner un nouveau nœud principal, car MemoryDB 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. Dans le cas de remplacements de nœuds planifiés initiés en raison de mises à jour de maintenance ou de mises à jour de service, sachez que les remplacements de nœuds prévus sont terminés pendant que le cluster traite les demandes d'écriture entrantes. Le multi-AZ sur vos clusters MemoryDB améliore votre tolérance aux pannes. Cela est particulièrement vrai dans les cas où les nœuds principaux de votre cluster deviennent inaccessibles ou tombent en panne pour une raison quelconque. Le mode multi-AZ sur les clusters MemoryDB nécessite que chaque partition possède plusieurs nœuds et est automatiquement activé. **Topics** + [Scénarios de défaillance avec réponses multi-AZ](#autofailover.scenarios) + [Test du basculement automatique](#auto-failover-test) ## Scénarios de défaillance avec réponses multi-AZ Si Multi-AZ est actif, un nœud principal défaillant bascule vers une réplique disponible. La réplique est automatiquement synchronisée avec le journal des transactions et devient principale, ce qui est beaucoup plus rapide que la création et le reprovisionnement d'un nouveau nœud principal. Ce processus dure généralement quelques secondes pendant lesquelles vous ne pouvez pas écrire sur le cluster. Lorsque Multi-AZ est actif, MemoryDB surveille 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 principal et de certaines répliques](#autofailover.scenarios.primaryandeplicas) + [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 tombe en panne, une réplique deviendra automatiquement le nœud principal. Une réplique de remplacement est ensuite créée et mise en service dans la même zone de disponibilité que la réplique principale défaillante. Lorsque seul le nœud principal tombe en panne, MemoryDB Multi-AZ effectue les opérations suivantes : 1. Le nœud principal défaillant est mis hors ligne. 1. Une up-to-date réplique devient automatiquement principale. Les écritures peuvent reprendre dès que le processus de basculement est terminé, généralement quelques secondes seulement. 1. Une réplique de remplacement est lancée et provisionnée. La réplique de remplacement est lancée dans la zone de disponibilité dans laquelle se trouvait le nœud principal défaillant afin que la distribution des nœuds soit maintenue. 1. La réplique est synchronisée avec le journal des transactions. Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes : + [Trouver le point de terminaison d'un cluster MemoryDB (API MemoryDB)](endpoints.md#endpoints.find.api.clusters)   ### Scénarios de défaillance en cas de défaillance du nœud principal et de certaines répliques Si le principal et au moins un réplica échouent, un up-to-date réplica est promu en cluster principal. De nouvelles répliques sont également créées et approvisionnées dans les mêmes zones de disponibilité que les nœuds défaillants. Lorsque le nœud principal et certaines répliques échouent, MemoryDB Multi-AZ effectue les opérations suivantes : 1. Le nœud principal défaillant et les répliques défaillantes sont mis hors ligne. 1. Une réplique disponible deviendra le nœud principal. Les écritures peuvent reprendre dès que le basculement est terminé, généralement quelques secondes seulement. 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 nœuds sont synchronisés avec le journal des transactions. Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes : + [Trouver le point de terminaison d'un cluster MemoryDB (CLI)AWS](endpoints.md#endpoints.find.cli) + [Trouver le point de terminaison d'un cluster MemoryDB (API MemoryDB)](endpoints.md#endpoints.find.api.clusters)   ### 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. Il n'y a aucune perte de données dans ce scénario car les données étaient conservées dans le journal des transactions. Lorsque l'ensemble du cluster échoue, MemoryDB Multi-AZ effectue les opérations suivantes : 1. Le nœud principal défaillant et les répliques sont mis hors ligne. 1. Un nœud principal de remplacement est créé et provisionné, synchronisé avec le journal des transactions. 1. Des répliques de remplacement sont créées et approvisionnées, synchronisées avec le journal des transactions. Les remplacements sont créés dans les zones de disponibilité des nœuds ayant échoué afin que la distribution des nœuds soit maintenue. Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes : + [Trouver le point de terminaison d'un cluster MemoryDB (CLI)AWS](endpoints.md#endpoints.find.cli) + [Trouver le point de terminaison d'un cluster MemoryDB (API MemoryDB)](endpoints.md#endpoints.find.api.clusters) ## Test du basculement automatique Vous pouvez tester le basculement automatique à l'aide de la console MemoryDB, de l'API MemoryDB et de l' AWS CLI API MemoryDB. Lors du test, tenez compte des points suivants : + Vous pouvez utiliser cette opération jusqu'à cinq fois par période de 24 heures. + Si vous appelez cette opération sur des partitions de différents clusters, vous pouvez effectuer les appels simultanément. + Dans certains cas, vous pouvez appeler cette opération plusieurs fois sur différentes partitions du même cluster MemoryDB. 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 console MemoryDB, de l'API MemoryDB ou de l' AWS CLI API MemoryDB. Recherchez les événements suivants liés à`FailoverShard`, listés ici par ordre d'occurrence probable : 1. message du cluster : `FailoverShard API called for shard ` 1. message du cluster : `Failover from primary node to replica node completed` 1. message du cluster : `Recovering nodes ` 1. message du cluster : `Finished recovery for nodes ` Pour plus d’informations, consultez les ressources suivantes : + [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)dans la référence de l'*API MemoryDB* + Cette API est conçue pour tester le comportement de votre application en cas de basculement de MemoryDB. 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 MemoryDB](#failovershard-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. **** 1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) 1. Cliquez sur le bouton radio situé à gauche du cluster que vous souhaitez tester. Ce cluster doit comporter au moins un nœud de réplication. 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 [Modification d'un cluster MemoryDB](clusters.modify.md). 1. Choisissez le nom du cluster. 1. Sur la page **Partitions et nœuds**, choisissez le nom de la partition sur laquelle vous souhaitez tester le basculement. 1. Pour le nœud, 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é (`FailoverShard 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'aide de l' AWS CLI opération failover-shard.](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html) **Parameters** + `--cluster-name` : obligatoire. Le cluster qui doit être testé. + `--shard-name` : obligatoire. Nom de la partition sur laquelle vous souhaitez tester le basculement automatique. Vous pouvez tester un maximum de cinq partitions sur une période continue de 24 heures. L'exemple suivant utilise l'appel AWS CLI to `failover-shard` sur le shard `0001` du cluster MemoryDB. `my-cluster` Pour Linux, macOS ou Unix : ``` aws memorydb failover-shard \ --cluster-name my-cluster \ --shard-name 0001 ``` Pour Windows : ``` aws memorydb failover-shard ^ --cluster-name my-cluster ^ --shard-name 0001 ``` Pour suivre la progression de votre basculement, utilisez l' AWS CLI `describe-events`opération. Il renverra la réponse JSON suivante : ``` { "Events": [ { "SourceName": "my-cluster", "SourceType": "cluster", "Message": "Failover to replica node my-cluster-0001-002 completed", "Date": "2021-08-22T12:39:37.568000-07:00" }, { "SourceName": "my-cluster", "SourceType": "cluster", "Message": "Starting failover for shard 0001", "Date": "2021-08-22T12:39:10.173000-07:00" } ] } ``` Pour plus d’informations, consultez les ressources suivantes : + [failover-shard](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html) + [describe-events](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html)   ### Test du basculement automatique à l'aide de l'API MemoryDB L'exemple suivant fait `FailoverShard` appel à la partition `0003` du cluster`memorydb00`. **Example Test du basculement automatique** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=FailoverShard &ShardName=0003 &ClusterName=memorydb00 &Version=2021-01-01 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20210801T192317Z &X-Amz-Credential= ``` Pour suivre la progression de votre basculement, utilisez l'opération d'API MemoryDB. `DescribeEvents` Pour plus d’informations, consultez les ressources suivantes : + [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) + [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) # Modification du nombre de réplicas Vous pouvez augmenter ou diminuer dynamiquement le nombre de répliques de lecture dans votre cluster MemoryDB à l'aide de l'API MemoryDB ou de l'API AWS CLI MemoryDB. AWS Management Console Toutes les partitions doivent avoir le même nombre de répliques. ## Augmenter le nombre de répliques dans un cluster Vous pouvez augmenter le nombre de répliques dans un cluster MemoryDB jusqu'à un maximum de cinq par partition. Vous pouvez le faire à l'aide de l' AWS Management Console API, de AWS CLI, ou de l'API MemoryDB. **Topics** + [En utilisant le AWS Management Console](#increase-replica-count-con) + [En utilisant le AWS CLI](#increase-replica-count-cli) + [Utilisation de l'API MemoryDB](#increase-replica-count-api) ### En utilisant le AWS Management Console Pour augmenter le nombre de répliques dans un cluster MemoryDB (console), consultez. [Ajouter/supprimer des nœuds d'un cluster](clusters.deletenode.md) ### En utilisant le AWS CLI Pour augmenter le nombre de répliques dans un cluster MemoryDB, utilisez la `update-cluster` commande avec les paramètres suivants : + `--cluster-name` : obligatoire. Identifie le cluster dans lequel vous souhaitez augmenter le nombre de répliques. + `--replica-configuration` : obligatoire. Permet de définir le nombre de répliques. Pour augmenter le nombre de répliques, définissez la `ReplicaCount` propriété sur le nombre de répliques que vous souhaitez inclure dans cette partition à la fin de cette opération. **Example** L'exemple suivant augmente le nombre de répliques dans le cluster `my-cluster` à 2. Pour Linux, macOS ou Unix : ``` aws memorydb update-cluster \ --cluster-name my-cluster \ --replica-configuration \ ReplicaCount=2 ``` Pour Windows : ``` aws memorydb update-cluster ^ --cluster-name my-cluster ^ --replica-configuration ^ ReplicaCount=2 ``` Elle renvoie la réponse JSON suivante : ``` { "Cluster": { "Name": "my-cluster", "Status": "updating", "NumberOfShards": 1, "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "DataTiering": "false", "AutoMinorVersionUpgrade": true } } ``` Pour afficher les détails du cluster mis à jour une fois que son statut passe de *mise à jour* à *disponible*, utilisez la commande suivante : Pour Linux, macOS ou Unix : ``` aws memorydb describe-clusters \ --cluster-name my-cluster --show-shard-details ``` Pour Windows : ``` aws memorydb describe-clusters ^ --cluster-name my-cluster --show-shard-details ``` Il renverra la réponse JSON suivante : ``` { "Clusters": [ { "Name": "my-cluster", "Status": "available", "NumberOfShards": 1, "Shards": [ { "Name": "0001", "Status": "available", "Slots": "0-16383", "Nodes": [ { "Name": "my-cluster-0001-001", "Status": "available", "AvailabilityZone": "us-east-1a", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } }, { "Name": "my-cluster-0001-002", "Status": "available", "AvailabilityZone": "us-east-1b", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } }, { "Name": "my-cluster-0001-003", "Status": "available", "AvailabilityZone": "us-east-1a", "CreateTime": "2021-08-22T12:59:31.844000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } } ], "NumberOfNodes": 3 } ], "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "ACLName": "my-acl", "DataTiering": "false", "AutoMinorVersionUpgrade": true } ] } ``` *Pour plus d'informations sur l'augmentation du nombre de répliques à l'aide de la CLI, consultez [update-cluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) dans le AWS CLI manuel Command Reference.* ### Utilisation de l'API MemoryDB Pour augmenter le nombre de répliques dans une partition MemoryDB, utilisez l'`UpdateCluster`action avec les paramètres suivants : + `ClusterName` : obligatoire. Identifie le cluster dans lequel vous souhaitez augmenter le nombre de répliques. + `ReplicaConfiguration` : obligatoire. Permet de définir le nombre de répliques. Pour augmenter le nombre de répliques, définissez la `ReplicaCount` propriété sur le nombre de répliques que vous souhaitez inclure dans cette partition à la fin de cette opération. **Example** L'exemple suivant augmente le nombre de répliques du cluster `sample-cluster` à trois. Lorsque l'exemple est terminé, il y a trois répliques dans chaque partition. Ce numéro s'applique qu'il s'agisse d'un cluster MemoryDB avec une seule partition ou d'un cluster MemoryDB avec plusieurs partitions. ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateCluster &ReplicaConfiguration.ReplicaCount=3 &ClusterName=sample-cluster &Version=2021-01-01 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20210802T192317Z &X-Amz-Credential= ``` Pour plus d'informations sur l'augmentation du nombre de répliques à l'aide de l'API, consultez [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html). ## Diminution du nombre de répliques dans un cluster Vous pouvez réduire le nombre de répliques dans un cluster pour MemoryDB. Vous pouvez réduire le nombre de répliques à zéro, mais vous ne pouvez pas basculer vers une réplique en cas de défaillance de votre nœud principal. Vous pouvez utiliser l'API AWS Management Console, la AWS CLI ou l'API MemoryDB pour réduire le nombre de répliques dans un cluster. **Topics** + [En utilisant le AWS Management Console](#decrease-replica-count-con) + [En utilisant le AWS CLI](#decrease-replica-count-cli) + [Utilisation de l'API MemoryDB](#decrease-replica-count-api) ### En utilisant le AWS Management Console Pour réduire le nombre de répliques dans un cluster MemoryDB (console), consultez. [Ajouter/supprimer des nœuds d'un cluster](clusters.deletenode.md) ### En utilisant le AWS CLI Pour réduire le nombre de répliques dans un cluster MemoryDB, utilisez la `update-cluster` commande avec les paramètres suivants : + `--cluster-name` : obligatoire. Identifie le cluster dans lequel vous souhaitez réduire le nombre de répliques. + `--replica-configuration` : obligatoire. `ReplicaCount`— Définissez cette propriété pour spécifier le nombre de nœuds de réplication souhaités. **Example** L'exemple suivant permet `--replica-configuration` de réduire le nombre de répliques dans le cluster `my-cluster` à la valeur spécifiée. Pour Linux, macOS ou Unix : ``` aws memorydb update-cluster \ --cluster-name my-cluster \ --replica-configuration \ ReplicaCount=1 ``` Pour Windows : ``` aws memorydb update-cluster ^ --cluster-name my-cluster ^ --replica-configuration ^ ReplicaCount=1 ^ ``` Il renverra la réponse JSON suivante : ``` { "Cluster": { "Name": "my-cluster", "Status": "updating", "NumberOfShards": 1, "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "DataTiering": "false", "AutoMinorVersionUpgrade": true } } ``` Pour afficher les détails du cluster mis à jour une fois que son statut passe de *mise à jour* à *disponible*, utilisez la commande suivante : Pour Linux, macOS ou Unix : ``` aws memorydb describe-clusters \ --cluster-name my-cluster --show-shard-details ``` Pour Windows : ``` aws memorydb describe-clusters ^ --cluster-name my-cluster --show-shard-details ``` Il renverra la réponse JSON suivante : ``` { "Clusters": [ { "Name": "my-cluster", "Status": "available", "NumberOfShards": 1, "Shards": [ { "Name": "0001", "Status": "available", "Slots": "0-16383", "Nodes": [ { "Name": "my-cluster-0001-001", "Status": "available", "AvailabilityZone": "us-east-1a", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } }, { "Name": "my-cluster-0001-002", "Status": "available", "AvailabilityZone": "us-east-1b", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } } ], "NumberOfNodes": 2 } ], "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "ACLName": "my-acl", "DataTiering": "false", "AutoMinorVersionUpgrade": true } ] } ``` *Pour plus d'informations sur la réduction du nombre de répliques à l'aide de la CLI, consultez [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) dans le AWS CLI manuel Command Reference.* ### Utilisation de l'API MemoryDB Pour réduire le nombre de répliques dans un cluster MemoryDB, utilisez l'`UpdateCluster`action avec les paramètres suivants : + `ClusterName` : obligatoire. Identifie le cluster dans lequel vous souhaitez réduire le nombre de répliques. + `ReplicaConfiguration` : obligatoire. Permet de définir le nombre de répliques. `ReplicaCount`— Définissez cette propriété pour spécifier le nombre de nœuds de réplication souhaités. **Example** L'exemple suivant permet `ReplicaCount` de réduire le nombre de répliques dans le cluster `sample-cluster` à un. Lorsque l'exemple est terminé, il y a une réplique dans chaque partition. Ce numéro s'applique qu'il s'agisse d'un cluster MemoryDB avec une seule partition ou d'un cluster MemoryDB avec plusieurs partitions. ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateCluster &ReplicaConfiguration.ReplicaCount=1 &ClusterName=sample-cluster &Version=2021-01-01 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20210802T192317Z &X-Amz-Credential= ``` Pour plus d'informations sur la réduction du nombre de répliques à l'aide de l'API, consultez [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).