Sobre o failover manual

Nesta página, você encontra uma visão geral do failover manual do Memorystore para Redis. Para saber como executar um failover, consulte Como iniciar um failover manual.

O que é um failover manual?

Uma instância de nível padrão do Memorystore para Redis usa um nó de réplica para fazer backup do nó principal. Um failover normal ocorre quando o nó principal perde a integridade, fazendo com que a réplica seja designada como o novo principal. A diferença entre o failover manual e o normal é que o manual precisa ser iniciado por você. Para mais informações sobre como funciona a replicação do Memorystore para Redis, consulte Alta disponibilidade.

Por que iniciar um failover manual?

Ao iniciar um failover manual, é possível testar como o aplicativo responde a um failover. Esse conhecimento ajuda a garantir um processo mais tranquilo se um failover inesperado ocorrer mais tarde.

Modo de proteção de dados opcional

Veja abaixo os dois modos de proteção de dados disponíveis:

  • Modo limited-data-loss (padrão).
  • Modo force-data-loss

Para definir o modo de proteção de dados, use um dos seguintes comandos:

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss

ou

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss

Como funcionam os modos de proteção de dados

O modo limited-data-loss minimiza a perda de dados verificando se a a diferença nos dados entre a instância principal e a réplica for inferior a 30 MB antes para iniciar o failover. O deslocamento no primário é incrementado para cada byte de dados que precisa ser sincronizado com as réplicas. No modo limited-data-loss, o failover será abortado se o delta de deslocamento mais alto entre o primário e cada réplica for de 30 MB ou mais. Se você pode tolerar mais perda de dados e quiser para executar o failover agressivamente, tente definir o modo de proteção de dados como force-data-loss:

O modo force-data-loss usa uma cadeia de estratégias de failover para executar o failover de forma agressiva. Ele não verifica o delta de deslocamento entre o primário e as réplicas antes de iniciar o failover. Você pode perder mais de 30 MB de mudanças de dados.

Métrica de bytes com replicação pendente

A métrica de bytes com replicação pendente informa quantos bytes restantes a réplica precisa copiar antes de fazer o backup completo do principal. Você pode observar um aumento de bytes pendentes, já que a principal replicação para a réplica é feita durante em caso de failover. Se o failover for acionado por um erro de hardware, poderá ocorrer um vazio em bytes com replicação pendente, porque o valor de deslocamento não pode ser obtido até que a nova réplica seja reparada pelo erro do host.

Você pode acessar isso métrica no console do Google Cloud, na página de detalhes da instância. Para visualizar essa página, clique no código da instância, na página da lista de instâncias do seu projeto.

Como alternativa, acesse o Metrics Explorer do seu projeto e pesquise a métrica redis.googlapis.com/replication/offset_diff.

Quando executar um failover manual

Os failovers manuais que usam o modo de proteção limited-data-loss padrão só funcionam se a métrica de bytes com replicação pendente for inferior a 30 MB. Se você quiser executar um failover manual com bytes com replicação pendente superior a 30 MB, use o modo de proteção force-data-loss.

Se você estiver tentando manter o maior número de dados possível, interrompa temporariamente a gravação do aplicativo na instância do Redis e execute o failover manual até que a métrica de bytes de replicação pendente seja reduzida a um valor aceitável.

Possíveis problemas que impedem um failover manual

  • A execução de um failover manual em uma instância do nível Básico não funciona porque a As instâncias de camada não têm réplicas para as quais a instância principal possa fazer failover.

  • Se a instância do Redis não estiver íntegra, um failover manual de perda de dados limitada falha porque ela está bloqueada para minimização da perda de dados.

  • Se você estiver executando um script Lua que está sendo executado indefinidamente, use force-data-loss para iniciar um failover. Nessa situação, uma operação de failover com perda limitada de dados não será concluída.

  • Se a instância tiver operações incompletas pendentes, como o escalonamento ou a atualização, a operação de failover manual será bloqueada. Você precisará aguardar até que a instância esteja no estado READY para executar um failover manual.

Conexão do aplicativo cliente

Quando o nó principal faz o failover para a réplica, as conexões atuais com o Memorystore para Redis são descartadas. No entanto, ao reconectar, seu aplicativo é redirecionado automaticamente para a nova instância principal usando a mesma string de conexão ou endereço IP.

Como confirmar um failover manual

É possível verificar o sucesso de uma operação de failover manual usando o Console do Google Cloud ou o gcloud.

Verificação do console do Google Cloud

Antes de iniciar um failover manual, acesse a página da lista de instâncias do Memorystore para Redis e clique no nome da instância.

Depois, na guia Configuração, ao lado de Local principal, veja qual zona em que o nó principal está. Anote a zona. Verifique esta página novamente quando conclua o failover manual para confirmar que o nó primário mudou de zona.

Verificação do Cloud Monitoring

Para visualizar as métricas de um recurso monitorado usando o Metrics Explorer, faça o seguinte:

  1. No console do Google Cloud, acesse a página do  Metrics Explorer:

    Acesse o Metrics explorer

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.

  2. No elemento Metric, expanda o menu Selecionar uma métrica, digite Node role na barra de filtro e use os submenus para selecionar um tipo de recurso e métrica específicos:
    1. No menu Recursos ativos, selecione Cloud Memorystore Redis.
    2. No menu Categorias de métrica ativas, selecione Replicação.
    3. No menu Métricas ativas, selecione Papel do nó.
    4. Clique em Aplicar.
  3. Para remover séries temporais da exibição, use o elemento Filtro.

  4. Para combinar séries temporais, use os menus no elemento Agregação. Por exemplo, para exibir a utilização da CPU para suas VMs, com base na zona, defina o primeiro menu como Média e o segundo como zona.

    Todas as séries temporais são exibidas quando o primeiro menu do elemento Agregação está definido como Não agregado. As configurações padrão do elemento Agregação são determinadas pelo tipo de métrica selecionada.

  5. Para cotas e outras métricas que informam uma amostra por dia, faça as seguintes ações:
    1. No painel Exibição, defina o Tipo de widget como Gráfico de barras empilhadas.
    2. Defina o período como pelo menos uma semana.

O gráfico do Cloud Monitoring representa os nós principal e de réplica com duas linhas. Quando o valor da linha for zero, ele será referente ao nó de réplica. Quando for um, ele representará o nó principal. O gráfico indica um failover ao mostrar como as linhas alternam entre um/zero e zero/um, respectivamente.

Verificação gcloud

Antes de iniciar um failover manual, use o seguinte comando para verificar em qual zona seu nó principal se encontra:

gcloud redis instances describe [INSTANCE_ID] --region=[REGION]

O nó principal está na zona currentLocationId. Anote essa informação.

Depois de concluir um failover manual, confirme se o nó principal mudou para uma nova zona. Basta executar o comando gcloud redis instances describe novamente e verificar se currentLocationId mudou de zona.

Além disso, o rótulo locationId informa a zona em que você provisionou originalmente o nó principal. O rótulo alternativeLocationId informa a zona em que o sistema provisionou originalmente o nó de réplica. Sempre que ocorrer um failover, o principal e a réplica alternarão entre essas duas zonas. No entanto, as zonas associadas a locationId e alternativeLocationId não são alteradas.