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.
Durante um failover manual para instâncias de nível padrão, os dados são preservados. Ao realizar um failover manual, a instância passa por uma redefinição de conexão curta de alguns minutos ou menos. Recomendamos que os aplicativos incorporem a lógica de repetição no código para que possam se reconectar à instância. O endereço IP e a string de conexão permanecem os mesmos.
Por que iniciar um failover manual?
Ao iniciar um failover manual, é possível testar como o aplicativo responde a um failover. Esse conhecimento pode garantir um processo de failover 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 nos dados entre o principal e a réplica está abaixo de 30 MB antes de iniciar o failover. O deslocamento no principal é incrementado para cada byte de dados que precisa ser sincronizado com as réplicas. No modo limited-data-loss, o failover será interrompido se o maior delta de deslocamento entre o principal 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 emprega uma cadeia de estratégias de failover para executar o failover de forma agressiva. Ele não verifica o delta de deslocamento entre o principal e as réplicas antes de iniciar o failover. É 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. Você pode observar um aumento nos bytes pendentes à medida que o principal é replicado para a réplica durante um failover. Se o failover for acionado por um erro de hardware, você poderá observar bytes pendentes vazios na replicação, já que o valor de deslocamento não poderá ser obtido até que a nova réplica seja reparada do erro do host.
Você pode acessar essa métrica no Google Cloud console 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 o principal pode fazer failover.
Se a instância do Redis não estiver íntegra, uma operação de failover manual de perda de dados limitada falhará porque será 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 de perda de dados limitada não será concluída com êxito.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 confirmar o êxito de uma operação de failover manual usando o
Google Cloud console ou gcloud.
Google Cloud Verificação do console
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 essa informação. 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 Google Cloud console, acesse a leaderboard página 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 Métrica , 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 Redis.
- No menu Categorias de métrica 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.