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á. # 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)