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.

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:

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:

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:

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 MemoryDB AWS CLI, o e o MemoryDB. API

Ao testar, observe o seguinte:

Testando o failover automático usando o AWS Management Console

Use o procedimento a seguir para testar o failover automático com o console.

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.

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.

Ele retornará a seguinte JSON resposta:

{
    "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.

Testando o failover automático usando o MemoryDB API

O exemplo a seguir chama FailoverShard o fragmento 0003 no clustermemorydb00.

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 seu failover, use a operação MemoryDB DescribeEventsAPI.

Para obter mais informações, consulte as informações a seguir.