Comutações por falha

Se um cluster do Bigtable deixar de responder, a replicação permite que o tráfego recebido seja transferido para outro cluster na mesma instância. As comutações por falha podem ser manuais ou automáticas, consoante o perfil da app que uma aplicação está a usar e como o perfil da app está configurado.

Esta página explica como funcionam as comutações por falha manuais e automáticas numa instância que usa a replicação. Para saber como concluir uma comutação por falha, consulte o artigo Gerir comutações por falha.

Antes de ler esta página, deve conhecer a vista geral da replicação do Bigtable. Também deve conhecer as opções de encaminhamento disponíveis.

Failovers manuais

Se um perfil de app usar o encaminhamento de cluster único para direcionar todos os pedidos para um cluster, tem de usar o seu próprio julgamento para decidir quando começar a fazer failover para um cluster diferente.

Seguem-se alguns sinais que podem indicar que seria útil fazer uma comutação por falha para um cluster diferente:

  • O cluster começa a devolver um grande número de erros de sistema temporários.
  • Um grande número de pedidos começa a exceder o tempo limite.
  • A latência de resposta média aumenta para um nível inaceitável.

Uma vez que estes sinais podem aparecer por vários motivos diferentes, a comutação para um cluster diferente não garante a resolução do problema subjacente. Monitorize a sua instância antes e depois da comutação por falha para verificar se as métricas melhoraram.

Para ver detalhes sobre como concluir uma comutação por falha manual, consulte o artigo Concluir uma comutação por falha manual.

Comutações automáticas

Se um perfil de app usar o encaminhamento de vários clusters, o Bigtable processa as comutações por falha automaticamente. Quando o cluster mais próximo não consegue processar um pedido, o Bigtable encaminha o tráfego para o cluster disponível mais próximo.

As comutações automáticas podem ocorrer mesmo que um cluster esteja indisponível durante um período muito curto. Por exemplo, se o Bigtable encaminhar um pedido para um cluster e esse cluster demorar demasiado tempo a responder ou devolver um erro transitório, o Bigtable normalmente tenta novamente esse pedido noutro cluster.

Se estiver a usar o encaminhamento de vários clusters e enviar um pedido com um prazo, o Bigtable faz automaticamente a ativação pós-falha quando necessário para ajudar a cumprir o prazo. Se o prazo do pedido se aproximar, mas o cluster inicial não tiver enviado uma resposta, o Bigtable encaminha o pedido para o cluster mais próximo seguinte.

O Bigtable usa um algoritmo interno de última gravação ganha para processar quaisquer conflitos de dados que possam ocorrer como resultado da comutação por falha antes de a replicação estar concluída. Consulte a secção Resolução de conflitos para obter mais detalhes.

Se estiver a usar a replicação com o encaminhamento de vários clusters para alcançar uma elevada disponibilidade (HA) para a sua aplicação, deve localizar os servidores ou as VMs do cliente em ou perto de mais do que uma Google Cloud região. Esta recomendação aplica-se mesmo que o seu servidor de aplicações não esteja alojado pela Google Cloud, porque os seus dados entram na rede Google Cloud através da região Google Cloud mais próxima do seu servidor de aplicações. Tal como qualquer pedido, uma comutação por falha é concluída mais rapidamente em distâncias mais curtas.

Muitas comutações por falha automáticas são tão breves que não as vai notar. Pode verificar o gráfico Automatic Failovers na consola para ver o número de pedidos que foram automaticamente reencaminhados durante um determinado período: abra a lista de instâncias, clique no nome da instância e, de seguida, clique em Estatísticas do sistema. Google Cloud

O que se segue?