As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Noções básicas sobre a replicação do MemoryDB O MemoryDB implementa a replicação com dados particionados em até 500 fragmentos. Cada fragmento em um cluster tem um único nó primário de leitura/gravação e até cinco nós de réplica somente de leitura. Cada nó primário pode sustentar até 100 MB/s. É possível criar um cluster com alto número de fragmentos e baixo número de réplicas totalizando até 500 nós por cluster. Essa configuração do cluster pode variar de 500 fragmentos e 0 réplicas para 100 fragmentos e 4 réplicas, que é o número máximo de réplicas permitidas. # Consistência No MemoryDB, os nós primários são bastante consistentes. As operações de gravação bem-sucedidas são armazenadas de forma duradoura em um log transacional multi-AZ distribuído antes de retornar aos clientes. As operações de leitura nos primários sempre retornam os dados mais atualizados, refletindo os efeitos de todas as operações anteriores de gravação bem-sucedidas. Essa forte consistência é preservada em todos os failovers primários. No MemoryDB, os nós de réplica acabam sendo consistentes. As operações de leitura de réplicas (usando o comando `READONLY`) nem sempre refletem os efeitos das operações de gravação bem-sucedidas mais recentes, com métricas de atraso publicadas no CloudWatch. No entanto, as operações de leitura de uma única réplica são sequencialmente consistentes. As operações de gravação bem-sucedidas entram em vigor em cada réplica na mesma ordem em que foram executadas na primária. ## Replicação em um cluster Cada réplica de leitura em um fragmento mantém uma cópia dos dados do nó primário do fragmento. Mecanismos de replicação assíncronos usando os logs de transação são usados para manter as réplicas de leitura sincronizadas com o primário. Os aplicativos podem ler a partir de qualquer nó no cluster. Os aplicativos podem apenas gravar nos nós primários. As réplicas de leitura aprimoram a escalabilidade da leitura. Como o MemoryDB armazena os dados em logs de transações duráveis, não há risco de perda de dados. Os dados são particionados em todos os fragmentos em um cluster do MemoryDB. Os aplicativos usam o *endpoint do cluster* do MemoryDB para conectar com os nós do cluster. Para obter mais informações, consulte [Localização de endpoints de conexão](endpoints.md). Os clusters do MemoryDB são regionais e podem conter nós somente de uma região. Para melhorar a tolerância a falhas, você pode provisionar primários e réplicas de leitura em várias zonas de disponibilidade dentro dessa região. O uso da replicação, que fornece o Multi-AZ, é altamente recomendado para todos os clusters do MemoryDB. Para obter mais informações, consulte [Minimização do tempo de inatividade no MemoryDB com Multi-AZ](autofailover.md). # Minimização do tempo de inatividade no MemoryDB com Multi-AZ Há várias instâncias em que o MemoryDB pode precisar substituir um nó primário; elas incluem certos tipos de manutenção planejada e o evento improvável de uma falha no nó primário ou na zona de disponibilidade. A resposta à falha do nó depende de qual nó apresentou a falha. No entanto, em todos os casos, o MemoryDB garante que nenhum dado seja perdido durante a substituição de nós ou failover. Por exemplo, se uma réplica falhar, o nó com falha será substituído e os dados serão sincronizados a partir do log de transações. Se o nó primário falhar, um failover é acionado para uma réplica consistente, o que garante que nenhum dado seja perdido durante o failover. As gravações agora são atendidas a partir do novo nó primário. O nó primário antigo é então substituído e sincronizado a partir do log de transações. Se um nó primário falhar em um único fragmento de nó (sem réplicas), o MemoryDB deixará de aceitar gravações até que o nó primário seja substituído e sincronizado a partir do log de transações. Essa substituição do nó pode resultar em algum tempo de inatividade do cluster, mas, se o multi-AZ estiver ativo, o tempo de inatividade será minimizado. A função do nó primário automaticamente fará um failover para uma das réplicas. Não há necessidade de criar e provisionar um novo nó primário, porque o MemoryDB lidará com isso de forma transparente. O failover e a promoção de réplica garantem que você possa continuar a gravar no novo primário assim que a promoção estiver concluída. No caso de substituições de nó planejadas iniciadas devido a atualizações de manutenção ou de serviço, saiba que as substituições de nó planejadas agora são concluídas enquanto o cluster atende às solicitações de gravação recebidas. O Multi-AZ em seus clusters do MemoryDB melhora sua tolerância a falhas. Isso é verdade principalmente nos casos em que os nós primários de seu cluster se tornam inacessíveis ou falham por qualquer motivo. O Multi-AZ em clusters do MemoryDB exige que cada fragmento tenha mais de um nó e seja ativado automaticamente. **Topics** + [Cenários de falha com respostas do multi-AZ](#autofailover.scenarios) + [Teste do failover automático](#auto-failover-test) ## Cenários de falha com respostas do multi-AZ Se o Multi-AZ estiver ativo, um nó primário com falha fará o failover para uma réplica disponível. A réplica é sincronizada automaticamente com o log de transações e se torna primária, o que é muito mais rápido do que criar e reprovisionar um novo nó primário. Esse processo normalmente demora apenas alguns segundos até que você possa gravar novamente no cluster. Quando o Multi-AZ está ativo, o MemoryDB monitora continuamente o estado do nó primário. Se o nó primário falhar, uma das seguintes ações será realizada, dependendo do tipo da falha. **Topics** + [Cenários de falha quando somente o nó primário falha](#autofailover.scenarios.primaryonly) + [Cenários de falha quando o nó primário e algumas réplicas falham](#autofailover.scenarios.primaryandeplicas) + [Cenários de falha quando cluster inteiro falha](#autofailover.scenarios.allfail) ### Cenários de falha quando somente o nó primário falha Se somente o nó primário falhar, uma réplica se tornará automaticamente primária. Depois disso, uma réplica de substituição é criada e provisionada na mesma zona de disponibilidade que o primário com falha. Quando somente o nó primário falha, o recurso Multi-AZ do MemoryDB faz o seguinte: 1. O nó primário com falha é colocado offline. 1. Uma up-to-date réplica se torna automaticamente primária. As gravações poderão ser retomadas assim que o processo de failover estiver concluído, normalmente depois de apenas alguns segundos. 1. Uma réplica de substituição é executada e provisionada. A réplica de substituição é executada na Zona de disponibilidade em que o nó primário com falha se encontrava, para que a distribuição de nós seja mantida. 1. A réplica é sincronizada com o log de transações. Para obter informações sobre como encontrar os endpoints de um cluster, consulte os seguintes tópicos: + [Localização do endpoint para um cluster do MemoryDB (API do MemoryDB)](endpoints.md#endpoints.find.api.clusters)   ### Cenários de falha quando o nó primário e algumas réplicas falham Se o primário e pelo menos uma réplica falharem, uma up-to-date réplica será promovida ao cluster primário. Novas réplicas de leitura também são criadas e provisionadas nas mesmas Zonas de disponibilidade que os nós com falha. Quando o nó primário e algumas réplicas falham, o Multi-AZ do MemoryDB faz o seguinte: 1. O nó primário com falha e as réplicas com falha são colocadas offline. 1. Uma réplica disponível se tornará o nó primário. As gravações poderão ser retomadas assim que o processo de failover estiver concluído, normalmente depois de apenas alguns segundos. 1. Réplicas de substituição são criadas e provisionadas. As réplicas de substituição são criadas nas Zonas de disponibilidade dos nós com falha, de modo que a distribuição de nós seja mantida. 1. Todos os nós são sincronizados com o log de transações. Para obter informações sobre como encontrar os endpoints de um cluster, consulte os seguintes tópicos: + [Localização do endpoint de um cluster do MemoryDB (CLI da AWS)](endpoints.md#endpoints.find.cli) + [Localização do endpoint para um cluster do MemoryDB (API do MemoryDB)](endpoints.md#endpoints.find.api.clusters)   ### Cenários de falha quando cluster inteiro falha Se tudo falhar, todos os nós serão recriados e provisionados nas mesmas Zonas de disponibilidade que os nós originais. Não há perda de dados nesse cenário, pois os dados persistiram no log de transações. Quando o cluster inteiro falha, o Multi-AZ do MemoryDB faz o seguinte: 1. O nó primário e as réplicas com falha são colocados offline. 1. Um nó primário substituto é criado e provisionado, sincronizado com o log de transações. 1. As réplicas de substituição são criadas e provisionadas, sincronizadas com o log de transações. As substituição são criadas nas Zonas de disponibilidade dos nós com falha, de modo que a distribuição de nós seja mantida. Para obter informações sobre como encontrar os endpoints de um cluster, consulte os seguintes tópicos: + [Localização do endpoint de um cluster do MemoryDB (CLI da AWS)](endpoints.md#endpoints.find.cli) + [Localização do endpoint para um cluster do MemoryDB (API do MemoryDB)](endpoints.md#endpoints.find.api.clusters) ## Teste do failover automático Você pode testar o failover automático usando o console do MemoryDB, a AWS CLI e a API do MemoryDB. Ao testar, observe o seguinte: + Você pode usar essa operação até cinco vezes em qualquer período de 24 horas. + Se você chamar essa operação em fragmentos em clusters diferentes, poderá fazer as chamadas simultaneamente. + Em alguns casos, é possível chamar essa operação várias vezes em diferentes fragmentos no mesmo grupo de cluster do MemoryDB. Nesses casos, a substituição do primeiro nó deve ser concluída antes que uma chamada subsequente possa ser feita. + Para determinar se a substituição do nó foi concluída, verifique os eventos usando o console MemoryDB AWS CLI, o ou a API MemoryDB. Procure pelos seguintes eventos relacionados a `FailoverShard`, listados aqui em ordem de ocorrência: 1. mensagem do cluster: `FailoverShard API called for shard ` 1. mensagem do cluster: `Failover from primary node to replica node completed` 1. mensagem do cluster: `Recovering nodes ` 1. mensagem do cluster: `Finished recovery for nodes ` Para saber mais, consulte: + [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)na referência da API *MemoryDB* + Essa API foi projetada para testar o comportamento do seu aplicativo em caso de failover do MemoryDB. Ela não foi projetada para ser uma ferramenta operacional para iniciar um failover a fim de resolver um problema com o cluster. Além disso, em determinadas condições, como eventos operacionais de grande escala, AWS pode bloquear essa API. **Topics** + [Testando o failover automático usando o Console de gerenciamento da AWS](#auto-failover-test-con) + [Testando o failover automático usando o AWS CLI](#auto-failover-test-cli) + [Testar o failover automático usando a API do MemoryDB](#failovershard-test-api) ### Testando o failover automático usando o Console de gerenciamento da AWS Use o procedimento a seguir para testar o failover automático com o console. **** 1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) 1. Selecione o botão de opção à esquerda do cluster que você deseja testar. Esse cluster deve ter pelo menos um nó de réplica. 1. Na área **Details**, confirme se esse cluster está habilitado para Multi-AZ. Se o cluster não estiver habilitado para o Multi-AZ, escolha um cluster diferente ou modifique esse cluster para habilitar o Multi-AZ. Para obter mais informações, consulte [Modificar um cluster do MemoryDB](clusters.modify.md). 1. Escolha o nome do cluster. 1. Na página **Fragmentos e nós**, para o fragmento no qual você deseja testar o failover, escolha o nome do fragmento. 1. Para o nó, escolha **Failover Primary**. 1. Escolha **Continue** para fazer failover do primário ou **Cancel** para cancelar a operação e não fazer failover do nó primário. Durante o processo de failover, o console continua a mostrar o status do nó como *disponível*. Para acompanhar o progresso do seu teste de failover, escolha **Events** no painel de navegação do console. Na guia **Eventos**, observe os eventos que indicam que o failover foi iniciado (`FailoverShard API called`) e concluído (`Recovery completed`).   ### Testando o failover automático usando o AWS CLI [Você pode testar o failover automático em qualquer cluster habilitado para Multi-AZ usando a AWS CLI operação failover-shard.](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html) **Parâmetros** + `--cluster-name` – obrigatório. O cluster que será testado. + `--shard-name` – obrigatório. O nome do fragmento no qual você deseja testar o failover automático. Você pode testar um máximo de cinco fragmentos em um período contínuo de 24 horas. O exemplo a seguir usa o AWS CLI para chamar o fragmento `failover-shard` `0001` no cluster MemoryDB. `my-cluster` Para Linux, macOS ou Unix: ``` aws memorydb failover-shard \ --cluster-name my-cluster \ --shard-name 0001 ``` Para Windows: ``` aws memorydb failover-shard ^ --cluster-name my-cluster ^ --shard-name 0001 ``` Para acompanhar o progresso do seu failover, use a AWS CLI `describe-events` operação. Retorna a seguinte resposta em JSON: ``` { "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" } ] } ``` Para saber mais, consulte: + [fragmento de failover](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)   ### Testar o failover automático usando a API do MemoryDB O exemplo a seguir chama `FailoverShard` o fragmento `0003` no cluster`memorydb00`. **Example Teste do failover automático** ``` 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= ``` Para acompanhar o progresso do failover, use a operação de `DescribeEvents` da API do MemoryDB. Para saber mais, consulte: + [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) + [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) # Alteração do número de réplicas Você pode aumentar ou diminuir dinamicamente o número de réplicas de leitura no cluster do MemoryDB usando o Console de gerenciamento da AWS, a AWS CLI ou a API do MemoryDB. Todos os fragmentos devem ter o mesmo número de réplicas. ## Aumentar o número de réplicas em um cluster Você pode aumentar o número de réplicas em um cluster do MemoryDB até um máximo de cinco fragmentos. Você pode fazer isso usando o Console de gerenciamento da AWS, a AWS CLI ou a API do MemoryDB. **Topics** + [Utilização do Console de gerenciamento da AWS](#increase-replica-count-con) + [Como usar o AWS CLI](#increase-replica-count-cli) + [Usando a API do MemoryDB](#increase-replica-count-api) ### Utilização do Console de gerenciamento da AWS Para aumentar o número de réplicas em um cluster do MemoryDB (console), consulte [Adição e Remoção de nós de um cluster](clusters.deletenode.md). ### Como usar o AWS CLI Para aumentar o número de réplicas em um cluster do MemoryDB, use o comando `update-cluster` com os seguintes parâmetros: + `--cluster-name` – obrigatório. Identifica em qual cluster você deseja aumentar o número de réplicas. + `--replica-configuration` – obrigatório. Permite que você defina o número de réplicas. Para aumentar a contagem de réplicas, defina a propriedade `ReplicaCount` para o número de réplicas que você deseja nesse fragmento ao final desta operação. **Example** O exemplo a seguir aumenta o número de réplicas no cluster `my-cluster` para dois. Para Linux, macOS ou Unix: ``` aws memorydb update-cluster \ --cluster-name my-cluster \ --replica-configuration \ ReplicaCount=2 ``` Para Windows: ``` aws memorydb update-cluster ^ --cluster-name my-cluster ^ --replica-configuration ^ ReplicaCount=2 ``` Retorna a seguinte resposta em JSON: ``` { "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 } } ``` Para visualizar os detalhes do cluster atualizado quando seu status mudar de *Atualizado* para *Disponível*, use o seguinte comando: Para Linux, macOS ou Unix: ``` aws memorydb describe-clusters \ --cluster-name my-cluster --show-shard-details ``` Para Windows: ``` aws memorydb describe-clusters ^ --cluster-name my-cluster --show-shard-details ``` Retorna a seguinte resposta em JSON: ``` { "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 } ] } ``` Para obter mais informações sobre como aumentar o número de réplicas usando a CLI, consulte [update-cluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) na *referência de comandos da AWS CLI*. ### Usando a API do MemoryDB Para aumentar o número de réplicas em um fragmento do MemoryDB, use a ação `UpdateCluster` com os seguintes parâmetros: + `ClusterName` – obrigatório. Identifica em qual cluster você deseja aumentar o número de réplicas. + `ReplicaConfiguration` – obrigatório. Permite que você defina o número de réplicas. Para aumentar a contagem de réplicas, defina a propriedade `ReplicaCount` para o número de réplicas que você deseja nesse fragmento ao final desta operação. **Example** O exemplo a seguir aumenta o número de réplicas no cluster `sample-cluster` para três. Quando o exemplo é concluído, existem três réplicas em cada fragmento. Esse número se aplica se for um cluster do MemoryDB com um único fragmento ou um cluster do MemoryDB com vários fragmentos. ``` 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= ``` Para obter mais informações sobre como aumentar o número de réplicas usando a API, consulte [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html). ## Diminuição do número de réplicas em um cluster Você pode reduzir o número de réplicas em um cluster do MemoryDB. Você pode reduzir o número de réplicas para zero, mas não pode fazer o failover para uma réplica se seu nó primário falhar. Você pode usar o Console de gerenciamento da AWS, a AWS CLI ou a API do MemoryDB para reduzir o número de réplicas em um cluster. **Topics** + [Utilização do Console de gerenciamento da AWS](#decrease-replica-count-con) + [Como usar o AWS CLI](#decrease-replica-count-cli) + [Usando a API do MemoryDB](#decrease-replica-count-api) ### Utilização do Console de gerenciamento da AWS Para diminuir o número de réplicas em um cluster do MemoryDB (console), consulte [Adição e Remoção de nós de um cluster](clusters.deletenode.md). ### Como usar o AWS CLI Para diminuir o número de réplicas em um cluster do MemoryDB, use o comando `update-cluster` com os seguintes parâmetros: + `--cluster-name` – obrigatório. Identifica em qual cluster você deseja diminuir o número de réplicas. + `--replica-configuration` – obrigatório. `ReplicaCount`: defina essa propriedade para especificar o número de nós de réplica desejado. **Example** O exemplo a seguir usa `--replica-configuration` a fim de diminuir o número de réplicas no cluster `my-cluster` para o valor especificado. Para Linux, macOS ou Unix: ``` aws memorydb update-cluster \ --cluster-name my-cluster \ --replica-configuration \ ReplicaCount=1 ``` Para Windows: ``` aws memorydb update-cluster ^ --cluster-name my-cluster ^ --replica-configuration ^ ReplicaCount=1 ^ ``` Retorna a seguinte resposta em JSON: ``` { "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 } } ``` Para visualizar os detalhes do cluster atualizado quando seu status mudar de *Atualizado* para *Disponível*, use o seguinte comando: Para Linux, macOS ou Unix: ``` aws memorydb describe-clusters \ --cluster-name my-cluster --show-shard-details ``` Para Windows: ``` aws memorydb describe-clusters ^ --cluster-name my-cluster --show-shard-details ``` Retorna a seguinte resposta em JSON: ``` { "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 } ] } ``` Para obter mais informações sobre como diminuir o número de réplicas usando a CLI, consulte [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) no *referência de comandos da AWS CLI.* ### Usando a API do MemoryDB Para diminuir o número de réplicas em um cluster do MemoryDB, use a ação `UpdateCluster` com os seguintes parâmetros: + `ClusterName` – obrigatório. Identifica em qual cluster você deseja diminuir o número de réplicas. + `ReplicaConfiguration` – obrigatório. Permite que você defina o número de réplicas. `ReplicaCount`: defina essa propriedade para especificar o número de nós de réplica desejado. **Example** O exemplo a seguir usa `ReplicaCount` para diminuir o número de réplicas no cluster `sample-cluster` para um. Quando o exemplo é concluído, existe uma réplica em cada fragmento. Esse número se aplica se for um cluster do MemoryDB com um único fragmento ou um cluster do MemoryDB com vários fragmentos. ``` 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= ``` Para obter mais informações sobre como diminuir o número de réplicas usando a API, consulte [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).