Habilitar Multi-AZ Cenários de falha com respostas do multi-AZ Teste do failover automático Notas sobre o Multi-AZ

Minimizando o tempo de inatividade no Redis com ElastiCache o Multi-AZ

Há vários casos ElastiCache em que o Redis pode precisar substituir um nó primário; isso inclui certos tipos de manutenção planejada e o evento improvável de uma falha no nó primário ou na zona de disponibilidade.

Essa substituição resulta em algum tempo de inatividade do cluster, mas se o multi-AZ estiver habilitado, o tempo de inatividade será minimizado. A função do nó primário fará failover automaticamente para uma das réplicas de leitura. Não há necessidade de criar e provisionar um novo nó primário, pois ElastiCache trataremos disso 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.

ElastiCache também propaga o nome do Serviço de Nomes de Domínio (DNS) da réplica promovida. Isso ocorre porque, em seguida, se o seu aplicativo estiver gravando no endpoint primário, nenhuma alteração nesse endpoint será necessária no seu aplicativo. Se estiver lendo de endpoints individuais, altere o endpoint de leitura da réplica promovida a primária para o endpoint da nova réplica.

No caso de substituições de nó planejadas, iniciadas devido a atualizações de manutenção ou atualizações de autoatendimento, esteja ciente do seguinte:

ElastiCache Para o Redis Cluster, as substituições planejadas dos nós são concluídas enquanto o cluster atende às solicitações de gravação recebidas.
Para clusters desabilitados do modo de cluster do Redis com o Multi-AZ habilitado que são executados no mecanismo 5.0.6 ou posterior, as substituições de nó planejadas são concluídas enquanto o cluster atende às solicitações de gravação recebidas.
Para clusters desabilitados no modo de cluster com Multi-AZ habilitado que são executados no mecanismo 4.0.10 ou anterior, é possível notar uma breve interrupção de gravação associada às atualizações de DNS. Essa interrupção pode levar até alguns segundos. Esse processo é muito mais rápido do que recriar e provisionar um novo primário, que será o caso se você não habilitar o multi-AZ.

Você pode ativar o Multi-AZ usando o ElastiCache Management Console AWS CLI, o ou a ElastiCache API.

Habilitar o ElastiCache Multi-AZ em seu cluster Redis (na API e na CLI, grupo de replicação) melhora sua tolerância a falhas. Isso é verdade, especialmente nos casos em que o cluster primário de leitura/gravação do seu cluster se torna inacessível ou falha por qualquer motivo. O Multi-AZ tem suporte em clusters do Redis que têm mais de um nó em cada fragmento.

Tópicos

Habilitar Multi-AZ
Cenários de falha com respostas do multi-AZ
Teste do failover automático
Limitações no Multi-AZ do Redis

Habilitar Multi-AZ

Você pode ativar o Multi-AZ ao criar ou modificar um cluster (API ou CLI, grupo de replicação) usando ElastiCache o console AWS CLI ou a API. ElastiCache

É possível habilitar o multi-AZ somente em clusters do Redis (modo cluster desabilitado) que têm pelo menos uma réplica de leitura disponível. Clusters sem réplicas de leitura não fornece alta disponibilidade ou tolerância a falhas. Para obter informações sobre como criar um cluster com replicação, consulte Criação de um grupo de replicação do Redis. Para obter informações sobre como adicionar uma réplica de leitura a um cluster com replicação, consulte Adicionando uma réplica de leitura, para grupos de replicação do Redis (Modo cluster desabilitado).

Habilitação do multi-AZ (console)

Você pode habilitar o Multi-AZ usando o ElastiCache console ao criar um novo cluster Redis ou modificando um cluster Redis existente com replicação.

O multi-AZ é habilitado por padrão em clusters do Redis (modo cluster habilitado).

Importante

ElastiCache ativará automaticamente o Multi-AZ somente se o cluster contiver pelo menos uma réplica em uma zona de disponibilidade diferente da primária em todos os fragmentos.

Ativando o Multi-AZ ao criar um cluster usando o console ElastiCache

Para obter mais informações sobre esse processo, consulte Criação de um cluster do Redis (modo cluster desabilitado) (console). Tenha uma ou mais réplicas e habilite o Multi-AZ.

Habilitação do multi-AZ em um cluster existente (console)

Para obter mais informações sobre esse processo, consulte Modificação de um cluster Usando o AWS Management Console.

Habilitar o recurso multi-AZ (AWS CLI)

O exemplo de código a seguir usa o AWS CLI para habilitar o Multi-AZ para o grupo de replicação. redis12

Importante

O grupo de replicação redis12 já deve existir e ter pelo menos uma réplica de leitura disponível.

Para Linux, macOS ou Unix:


aws elasticache modify-replication-group \
    --replication-group-id redis12 \
    --automatic-failover-enabled \
    --multi-az-enabled \
    --apply-immediately

Para Windows:


aws elasticache modify-replication-group ^
    --replication-group-id redis12 ^
    --automatic-failover-enabled ^
    --multi-az-enabled ^
    --apply-immediately

A saída JSON desse comando deve ser semelhante ao seguinte.


{
    "ReplicationGroup": {
        "Status": "modifying", 
        "Description": "One shard, two nodes", 
        "NodeGroups": [
            {
                "Status": "modifying", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-002"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ReplicationGroupId": "redis12", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabling", 
        "MultiAZ": "enabled", 
        "SnapshotWindow": "07:00-08:00", 
        "SnapshottingClusterId": "redis12-002", 
        "MemberClusters": [
            "redis12-001", 
            "redis12-002"
        ], 
        "PendingModifiedValues": {}
    }
}

Para obter mais informações, consulte estes tópicos na AWS CLI Referência de comandos:

create-cache-cluster
create-replication-group
modify-replication-group na AWS CLI Referência de comandos.

Ativando o Multi-AZ (ElastiCache API)

O exemplo de código a seguir usa a ElastiCache API para habilitar o Multi-AZ para o grupo de replicação. redis12

nota

Para usar esse exemplo, o grupo de replicação redis12 já deve existir e ter pelo menos uma réplica de leitura disponível.


https://elasticache.us-west-2.amazonaws.com/
    ?Action=ModifyReplicationGroup
    &ApplyImmediately=true
    &AutoFailover=true
    &MultiAZEnabled=true
    &ReplicationGroupId=redis12
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Para obter mais informações, consulte esses tópicos na Referência ElastiCache da API:

Cenários de falha com respostas do multi-AZ

Antes da introdução do Multi-AZ, ElastiCache detectou e substituiu os nós com falha de um cluster recriando e reprovisionando o nó com falha. Se você habilitar o Multi-AZ, um nó primário com falha fará failover para a réplica com o menor atraso de replicação. A réplica selecionada é promovida automaticamente para primário, 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á ativado, monitora ElastiCache 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
Cenários de falha quando o nó primário e algumas réplicas de leitura falham
Cenários de falha quando cluster inteiro falha

Cenários de falha quando somente o nó primário falha

Se somente o nó primário falhar, a réplica de leitura com o menor atraso de replicação será promovida a primária. Depois disso, uma réplica de leitura 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 ElastiCache Multi-AZ faz o seguinte:

O nó primário com falha é colocado offline.
A réplica de leitura com o menor atraso de replicação é promovida a primário.

As gravações poderão ser retomadas assim que o processo de promoção estiver concluído, normalmente depois de apenas alguns segundos. Se seu aplicativo estiver gravando no endpoint primário, você não precisará alterar o endpoint para gravações ou leituras. ElastiCachepropaga o nome DNS da réplica promovida.
Uma réplica de leitura de substituição é executada e provisionada.

A réplica de leitura 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.
As réplicas são sincronizadas com o novo nó primário.

Depois que a nova réplica estiver disponível, lembre-se dos seguintes efeitos:

Endpoint primário: não faça alterações na sua aplicação, pois o nome do DNS do novo nó primário é propagado para o endpoint primário.
Endpoint leitor: o endpoint leitor é atualizado automaticamente para apontar para os novos nós de réplica.

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 de leitura falham

Se o primário e pelo menos uma réplica de leitura falhar, a réplica disponível com o menor atraso de replicação será promovida a 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 e a réplica que foi promovida a primário.

Quando o nó primário e algumas réplicas de leitura falham, o ElastiCache Multi-AZ faz o seguinte:

O nó primário com falha e as réplicas de leitura com falha são colocadas offline.
A réplica disponível com o menor atraso de replicação é promovida a nó primário.

As gravações poderão ser retomadas assim que o processo de promoção estiver concluído, normalmente depois de apenas alguns segundos. Se seu aplicativo estiver gravando no endpoint primário, não há necessidade de alterar o endpoint para gravações. ElastiCache propaga o nome DNS da réplica promovida.
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 clusters são sincronizados com o novo nó primário.

Faça as seguintes alterações no seu aplicativo depois que os novos nós estiverem disponíveis:

Endpoint primário: não faça alterações em sua aplicação. O nome de DNS do novo nó primário é propagado para o endpoint primário.
Endpoint leitor: o endpoint leitor é atualizado automaticamente para apontar para os novos nós de réplica.

Para obter informações sobre como encontrar os endpoints de um grupo de replicação, 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.

Nesse cenário, todos os dados do cluster são perdidos devido à falha de cada nó no cluster. Essa ocorrência é rara.

Quando todo o cluster falha, o ElastiCache Multi-AZ faz o seguinte:

O nó primário e as réplicas de leitura com falha são colocados offline.
Um nó primário de substituição é criado e provisionado.
Réplicas de substituição são criadas e provisionadas.

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.

Como o cluster inteiro falhou, os dados são perdidos, e todos os novos nós são iniciados a frio.

Como cada um dos nós de substituição tem o mesmo endpoint que o nó que ele está substituindo, não é necessário fazer alterações de endpoint no seu aplicativo.

Para obter informações sobre como encontrar os endpoints de um grupo de replicação, consulte os seguintes tópicos:

Recomendamos que você crie o nó primário e as réplicas de leitura em diferentes Zonas de disponibilidade para aumentar o nível de tolerância a falhas.

Teste do failover automático

Depois de ativar o failover automático, você pode testá-lo usando o ElastiCache console AWS CLI, o e a ElastiCache API.

Ao testar, observe o seguinte:

Você pode usar essa operação para testar o failover automático em até 15 fragmentos (chamados de grupos de nós na ElastiCache API e AWS CLI) em qualquer período contínuo de 24 horas.
Se você chamar essa operação em estilhaços em clusters diferentes (chamados grupos de replicação na API e CLI), poderá fazer as chamadas simultaneamente.
Em alguns casos, é possível chamar essa operação várias vezes em diferentes fragmentos no mesmo grupo de replicação do Redis (modo cluster habilitado). 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 ElastiCache console da Amazon AWS CLI, o ou a ElastiCache API. Procure pelos seguintes eventos relacionados ao failover automático, listados aqui em ordem de ocorrência:
1. Mensagem do grupo de replicação: Test Failover API called for node group <node-group-id>
2. Mensagem do cluster de cache: Failover from primary node <primary-node-id> to replica node <node-id> completed
3. Mensagem do grupo de replicação: Failover from primary node <primary-node-id> to replica node <node-id> completed
4. Mensagem do cluster de cache: Recovering cache nodes <node-id>
5. Mensagem do cluster de cache: Finished recovery for cache nodes <node-id>
Para mais informações, consulte:
- Visualização de eventos do ElastiCache no ElastiCache Guia do usuário
- DescribeEvents na Referência de API do ElastiCache
- describe-events na AWS CLI Referência de comandos.
Essa API foi projetada para testar o comportamento do seu aplicativo em caso de ElastiCache failover. 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
Testando o failover automático usando o AWS CLI
Testando o failover automático usando a API ElastiCache

Testando o failover automático usando o AWS Management Console

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

Para testar o failover automático

Faça login no AWS Management Console e abra o ElastiCache console em https://console.aws.amazon.com/elasticache/.
No painel de navegação, escolha Redis.
Na lista de clusters Redis, escolha a caixa à esquerda do cluster que deseja testar. Esse cluster deve ter pelo menos um nó de réplica de leitura.
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 Usando o AWS Management Console.
Para o Redis (modo cluster desabilitado), escolha o nome do cluster.

Para o Redis (modo cluster habilitado), faça o seguinte:
1. Escolha o nome do cluster.
2. Na página Shards, para o estilhaço (chamado de grupo de nó na API e na CLI) no qual você deseja testar o failover, escolha o nome do estilhaço.
Na página Nodes, 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 (Test Failover 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. test-failover

Parâmetros

--replication-group-id: obrigatório. O grupo de replicação (no console, cluster) que deve ser testado.
--node-group-id: obrigatório. O nome do grupo de nós nos quais você deseja testar o failover automático. Você pode testar no máximo 15 grupos de nós em um período contínuo de 24 horas.

O exemplo a seguir usa o AWS CLI para testar o failover automático no grupo de nós redis00-0003 no cluster Redis (modo de cluster ativado). redis00

exemplo Teste de failover automático

Para Linux, macOS ou Unix:


aws elasticache test-failover \
   --replication-group-id redis00 \
   --node-group-id redis00-0003

Para Windows:


aws elasticache test-failover ^
   --replication-group-id redis00 ^
   --node-group-id redis00-0003

A saída do comando precedente é semelhante ao seguinte.


{
    "ReplicationGroup": {
        "Status": "available", 
        "Description": "1 shard, 3 nodes (1 + 2 replicas)", 
        "NodeGroups": [
            {
                "Status": "available", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2c", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-002"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-003"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ClusterEnabled": false, 
        "ReplicationGroupId": "redis1x3", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabled", 
        "MultiAZ": "enabled",
        "SnapshotWindow": "11:30-12:30", 
        "SnapshottingClusterId": "redis1x3-002", 
        "MemberClusters": [
            "redis1x3-001", 
            "redis1x3-002", 
            "redis1x3-003"
        ], 
        "CacheNodeType": "cache.m3.medium", 
        "DataTiering": "disabled",
        "PendingModifiedValues": {}
    }
}

Para acompanhar o progresso do seu failover, use a AWS CLI describe-events operação.

Para mais informações, consulte:

test-failover na AWS CLI Referência de comandos.
describe-events na AWS CLI Referência de comandos.

Testando o failover automático usando a API ElastiCache

Você pode testar o failover automático em qualquer cluster habilitado com o Multi-AZ usando a operação da ElastiCache API. TestFailover

Parâmetros

ReplicationGroupId: obrigatório. O grupo de replicação (no console ou cluster) a ser testado.
NodeGroupId: obrigatório. O nome do grupo de nós nos quais você deseja testar o failover automático. Você pode testar no máximo 15 grupos de nós em um período contínuo de 24 horas.

O exemplo a seguir testa o failover automático no grupo de nós redis00-0003 no grupo de replicação (no console, cluster) redis00.

exemplo Teste do failover automático


https://elasticache.us-west-2.amazonaws.com/
    ?Action=TestFailover
    &NodeGroupId=redis00-0003
    &ReplicationGroupId=redis00
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Para acompanhar o progresso do seu failover, use a operação da ElastiCache DescribeEvents API.

Para mais informações, consulte:

TestFailoverna Referência da ElastiCache API
DescribeEventsna Referência da ElastiCache API

Limitações no Multi-AZ do Redis

Esteja ciente das seguintes limitações para o Multi-AZ do Redis:

O Multi-AZ tem suporte no Redis versão 2.8.6 e posterior.
O Multi-AZ do Redis não tem suporte em tipos de nó T1.
A replicação do Redis é assíncrona. Portanto, quando um nó primário faz failover em uma réplica, uma pequena quantidade de dados pode ser perdida devido ao atraso da replicação.

Ao escolher a réplica a ser promovida à primária, ElastiCache o Redis escolhe a réplica com o menor atraso de replicação. Em outras palavras, ele escolha a réplica que é mais atual. Isso ajuda a minimizar a quantidade de dados perdidos. A réplica com o atraso de replicação mínimo pode estar na mesma zona de disponibilidade ou em outra em relação ao nó primário com falha.
Ao promover manualmente as réplicas de leitura para primárias no Redis (modo cluster desabilitado), é possível fazê-lo somente quando o multi-AZ e o failover automático estiverem desabilitados. Para promover uma réplica de leitura para primário, execute as seguintes etapas:
1. Desabilite o Multi-AZ no cluster.
2. Desabilite o failover automático no cluster. Isso pode ser feito usando o console do Redis desmarcando a caixa de seleção Auto failover (Failover automático) para o grupo de replicação. Você pode fazer isso usando o AWS CLI definindo a AutomaticFailoverEnabled propriedade como false ao chamar a ModifyReplicationGroup operação.
3. Promova a réplica de leitura para primário.
4. Habilite novamente o Multi-AZ.
ElastiCache para Redis Multi-AZ e AOF (Append-Only File) são mutuamente exclusivos. Se você habilitar um, não é possível habilitar o outro.
Uma falha de um nó pode ser causada pelo evento raro de falha total de uma zona de disponibilidade. Neste caso, a réplica que substitui o primário com falha é criada somente quando a zona de disponibilidade volta a ficar ativa. Por exemplo, considere um grupo de replicação com o primário em AZ-a e réplicas em AZ-b e AZ-c. Se o primário falhar, a réplica com o menor atraso de replicação será promovida a cluster primário. Em seguida, ElastiCache cria uma nova réplica no AZ-a (onde o primário com falha estava localizado) somente quando o AZ-a estiver de volta e disponível.
Uma reinicialização iniciada pelo cliente de um primário não aciona o failover automático. Outras reinicializações e falhas desencadeiam o failover automático.
Quando o primário é reiniciado, seus dados são limpos quando ele volta a ficar online. Quando as réplicas de leitura veem o cluster primário limpo, elas limpam suas cópias dos dados, o que causa perda de dados.
Depois que uma réplica de leitura foi promovida, as outras réplicas se sincronizam com o novo primário. Após a sincronização inicial, o conteúdo das réplicas é excluído, e eles sincronizam os dados do novo primário. Esse processo de sincronização causa uma breve interrupção, durante a qual as réplicas não são acessíveis. O processo de sincronização também causa um aumento de carga temporário no primário durante a sincronização com as réplicas. Esse comportamento é nativo do Redis e não é exclusivo do ElastiCache Multi-AZ. Para obter detalhes sobre esse comportamento do Redis, consulte Replication no site do Redis.

Importante

Para o Redis versão 2.8.22 e posterior, não é possível criar réplicas externas.

Para versões do Redis anteriores à 2.8.22, recomendamos que você não conecte uma réplica externa do Redis a um cluster do Redis que esteja habilitado ElastiCache para Multi-AZ. Essa configuração não suportada pode criar problemas que impedem a execução adequada ElastiCache do failover e da recuperação. Para conectar uma réplica externa do Redis a um ElastiCache cluster, certifique-se de que o Multi-AZ não esteja ativado antes de fazer a conexão.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Replicação: Redis (modo cluster desabilitado) versus Redis (modo cluster habilitado)

Como a sincronização e o backup são implementados