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 diferença entre os dados do primário e da réplica está abaixo de 30 MB antes de 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á cancelado se o maior delta de deslocamento entre o primário e cada réplica for de 30 MB ou mais. Se você puder tolerar mais perda de dados e quiser executar o failover de forma agressiva, 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 a instância principal e as réplicas antes de iniciar o failover. Portanto, é possível perder mais de 30 MB de alterações 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. É possível observar um aumento nos bytes pendentes à medida que a instância principal é replicada para a réplica durante um failover. Se o failover for acionado por um erro de hardware, talvez você observe um valor vazio em "bytes pendentes de replicação", já que o valor de deslocamento não pode ser obtido até que a nova réplica seja corrigida do erro do host.
Acesse essa 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.
Se preferir, 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 de nível Básico não funciona porque as instâncias desse nível não têm réplicas para as quais a principal pode fazer failover.
Se a instância do Redis não estiver íntegra, uma operação de failover manual com perda de dados limitada vai falhar porque está bloqueada para minimizar a perda de dados.
Se você estiver executando um script Lua que está sendo executado indefinidamente, use
force-data-losspara 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
READYpara 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 com o
consoleGoogle Cloud ou gcloud.
Verificação do consoleGoogle 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.
Em seguida, na guia Configuração, ao lado de Local principal, veja em qual zona o nó principal está. Anote a zona. Entre nessa página novamente quando concluir o failover manual para confirmar se o nó principal 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:
-
No console Google Cloud , acesse a página leaderboard Metrics Explorer:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.
- Na barra de ferramentas do console Google Cloud , selecione seu projeto Google Cloud . Para configurações do App Hub, selecione o projeto host do App Hub ou o projeto de gerenciamento da pasta habilitada para apps.
- No elemento Metric, expanda o menu Selecionar uma métrica,
digite
Node rolena barra de filtro e use os submenus para selecionar um tipo de recurso e métrica específicos:- No menu Recursos ativos, selecione Cloud Memorystore para Redis.
- No menu Categorias de métricas ativas, selecione replicação.
- No menu Métricas ativas, selecione Função do nó.
- Clique em Aplicar.
Para adicionar filtros que removem séries temporais dos resultados da consulta, use o elemento Filtro.
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.
- Para cotas e outras métricas que informam uma amostra por dia, faça as seguintes ações:
- No painel Exibição, defina o Tipo de widget como Gráfico de barras empilhadas.
- 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.