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.
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.
Tópicos
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:
O nó primário com falha é colocado offline.
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.
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.
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:
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:
O nó primário com falha e as réplicas com falha são colocadas offline.
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.
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.
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:
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:
O nó primário e as réplicas com falha são colocados offline.
Um nó primário substituto é criado e provisionado, sincronizado com o log de transações.
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:
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:-
mensagem do cluster:
FailoverShard API called for shard <shard-id> -
mensagem do cluster:
Failover from primary node <primary-node-id> to replica node <node-id> completed -
mensagem do cluster:
Recovering nodes <node-id> -
mensagem do cluster:
Finished recovery for nodes <node-id>
Para obter mais informações, consulte as informações a seguir.
-
DescribeEventsna 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.
Tópicos
Testando o failover automático usando o AWS Management Console
Use o procedimento a seguir para testar o failover automático com o console.
-
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.
-
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 ter mais informações, consulte Modificar um cluster do MemoryDB.
Escolha o nome do cluster.
-
Na página Fragmentos e nós, para o fragmento no qual você deseja testar o failover, escolha o nome do fragmento.
-
Para o nó, escolha Failover Primary.
-
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
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-namemy-cluster\ --shard-name0001
Para Windows:
aws memorydb failover-shard ^ --cluster-namemy-cluster^ --shard-name0001
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 obter mais informações, consulte as informações a seguir.
Testar o failover automático usando a API do MemoryDB
O exemplo a seguir chama FailoverShard o fragmento 0003 no clustermemorydb00.
exemplo 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=<credential>
Para acompanhar o progresso do failover, use a operação de DescribeEvents da API do MemoryDB.
Para obter mais informações, consulte as informações a seguir.
