Esta página oferece uma vista geral da comutação por falha manual para o Memorystore for Redis. Para saber como fazer uma comutação por falha, consulte o artigo Iniciar uma comutação por falha manual.
O que é uma comutação por falha manual?
Uma instância do Memorystore for Redis de nível padrão usa um nó de réplica para fazer uma cópia de segurança do nó principal. Uma comutação por falha normal ocorre quando o nó principal fica em mau estado, o que faz com que a réplica seja designada como o novo nó principal. Uma comutação por falha manual difere de uma comutação por falha normal porque é iniciada por si. Para mais informações sobre o funcionamento da replicação do Memorystore for Redis, consulte o artigo Alta disponibilidade.
Por que motivo deve iniciar uma comutação por falha manual?
A iniciação de uma comutação por falha manual permite-lhe testar a forma como a sua aplicação responde a uma comutação por falha. Este conhecimento pode garantir um processo de comutação por falha mais simples se ocorrer uma comutação por falha inesperada mais tarde.
Modo de proteção de dados opcional
Os dois modos de proteção de dados disponíveis são:
limited-data-loss(predefiniçã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 ao verificar se a diferença nos dados entre o principal e a réplica é inferior a 30 MB antes de iniciar a comutação por falha. O desvio no elemento principal é incrementado para cada byte de dados que tem de ser sincronizado com as respetivas réplicas. No modo limited-data-loss, a comutação em caso de falha é anulada se a maior diferença de deslocamento entre o servidor principal e cada réplica for de 30 MB ou superior. Se puder tolerar mais perda de dados e quiser executar agressivamente a comutação por falha, experimente definir o modo de proteção de dados como force-data-loss.
O modo force-data-loss usa uma cadeia de estratégias de comutação por falha para executar a comutação por falha de forma agressiva. Não verifica a diferença de deslocamento entre a principal e as réplicas antes de iniciar a comutação por falha. Potencialmente, pode perder mais de 30 MB de alterações de dados.
Métrica de bytes pendentes de replicação
A métrica bytes pendentes de replicação indica quantos bytes restantes a réplica tem de copiar antes de a cópia de segurança principal estar concluída. Pode observar um aumento nos bytes pendentes à medida que a base de dados primária é replicada para a réplica durante uma comutação por falha. Se a comutação por falha for acionada por um erro de hardware, pode observar bytes de entrada pendentes de replicação vazios, uma vez que não foi possível obter o valor de deslocamento até que a nova réplica fosse reparada a partir do erro do anfitrião.
Pode aceder a esta métrica na Google Cloud consola na página de detalhes da instância. Para ver a página de detalhes da instância, clique no ID da instância na página da lista de instâncias do seu projeto.
Em alternativa, aceda ao Explorador de métricas do seu projeto e pesquise a métrica redis.googlapis.com/replication/offset_diff.
Quando executar uma comutação por falha manual
As comutações por falha manuais que usam apenas o modo de proteção limited-data-loss predefinido
só têm êxito se a métrica bytes pendentes de replicação for inferior a 30 MB. Se quiser executar uma comutação por falha manual com bytes de replicação pendentes superiores a 30 MB, use o modo de proteção force-data-loss.
Se estiver a tentar preservar o máximo de dados possível, impeça temporariamente a sua aplicação de escrever na instância do Redis e aguarde para executar a comutação por falha manual até que a métrica bytes pendentes de replicação seja tão baixa quanto considerar aceitável.
Potenciais problemas que bloqueiam uma comutação por falha manual
A execução de uma comutação por falha manual numa instância de nível básico não funciona porque as instâncias de nível básico não têm réplicas para as quais o principal pode comutar por falha.
Se a sua instância do Redis não estiver em bom estado, uma operação de comutação por falha manual com perda de dados limitada falha porque está bloqueada para minimizar a perda de dados.
Se estiver a executar um script Lua que está a ser executado indefinidamente, tem de usar
force-data-losspara iniciar uma comutação por falha. Nesta situação, uma operação de ativação pós-falha com perda de dados limitada não é concluída com êxito.Se a sua instância tiver operações pendentes incompletas, como o ajuste de escala ou a atualização, a operação de comutação por falha manual é bloqueada. Tem de aguardar até que a instância esteja no estado
READYpara executar uma comutação por falha manual.
Ligação da aplicação cliente
Quando o nó principal comuta para a réplica, as ligações existentes ao Memorystore for Redis são eliminadas. No entanto, quando restabelece a ligação, a sua aplicação é automaticamente redirecionada para o novo nó principal através da mesma string de ligação ou endereço IP.
Validar uma comutação por falha manual
Pode validar o êxito de uma operação de comutação por falha manual com aGoogle Cloud consola ou o gcloud.
Google Cloud Validação da consola
Antes de iniciar uma comutação por falha manual, aceda à página da lista de instâncias do Memorystore para Redis e clique no nome da sua instância.
Em seguida, no separador Configuração, junto a Localização principal, veja em que zona se encontra o nó principal. Anote a zona. Verifique novamente esta página quando concluir a comutação por falha manual para confirmar que o nó principal mudou de zona.
Validação do Cloud Monitoring
Para ver as métricas de um recurso monitorizado através do Metrics Explorer, faça o seguinte:
-
Na Google Cloud consola, aceda à página leaderboard Explorador de métricas:
Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Monitorização.
- Na barra de ferramentas da Google Cloud consola, selecione o seu Google Cloud projeto. Para configurações do App Hub, selecione o projeto anfitrião do App Hub ou o projeto de gestão da pasta com apps ativadas.
- No elemento Métrica, expanda o menu Selecionar uma métrica,
introduza
Node rolena barra de filtros e, de seguida, use os submenus para selecionar um tipo de recurso e uma métrica específicos:- No menu Recursos ativos, selecione Cloud Memorystore 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 cronológicas dos resultados da consulta, use o elemento Filter.
Para combinar séries cronológicas, use os menus no elemento Agregação. Por exemplo, para apresentar a utilização da CPU das suas VMs, com base na respetiva zona, defina o primeiro menu como Média e o segundo menu como zona.
Todas as séries cronológicas são apresentadas quando o primeiro menu do elemento Agregação está definido como Não agregado. As predefinições do elemento Agregação são determinadas pelo tipo de métrica que selecionou.
- Para a quota e outras métricas que comunicam uma amostra por dia, faça o seguinte:
- No painel Apresentaçã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 principais e de réplica com duas linhas. Quando a linha de um nó tem um valor de zero no gráfico, trata-se do nó de réplica. Quando a linha de um nó tem um valor de um no gráfico, é o nó principal. O gráfico representa uma comutação por falha, mostrando como as linhas mudam de um para zero e de zero para um, respetivamente.
Validação gcloud
Antes de iniciar uma comutação por falha manual, use o seguinte comando para verificar em que zona se encontra o nó principal:
gcloud redis instances describe [INSTANCE_ID] --region=[REGION]
O seu nó principal está na zona etiquetada como currentLocationId. Anote a zona.
Depois de concluir uma comutação por falha manual, pode confirmar que o nó principal mudou para uma nova zona executando novamente o comando gcloud redis instances describe e verificando se as zonas currentLocationId foram alteradas.
Além disso, a etiqueta locationId indica a zona na qual aprovisionou originalmente o seu nó principal. A etiqueta alternativeLocationId indica a zona em que o sistema aprovisionou originalmente o nó da réplica. Sempre que ocorre uma comutação por falha, o primário e a réplica alternam entre estas duas zonas. No entanto, as zonas associadas a locationId e alternativeLocationId não são alteradas.