Failovers

Se um cluster do Bigtable parar de responder, a replicação vai possibilitar a faça o failover do tráfego para outro cluster na mesma instância. Os failovers podem ser manuais ou automáticos, dependendo do perfil de app usado por um aplicativo e de como esse perfil está configurado.

Nesta página, você verá como failovers manuais e automáticos funcionam em uma instância que usa replicação. Para saber como concluir um failover, consulte Como gerenciar failovers.

Antes de ler esta página, familiarize-se com a visão geral da replicação do Bigtable. Conheça também as opções de roteamento disponíveis.

Failovers manuais

Se um perfil de aplicativo usa roteamento de cluster único para direcionar todos os pedidos a um cluster, você precisa usar o bom senso para decidir quando começar o failover para um cluster diferente.

Aqui estão alguns sinais que podem indicar que seria útil fazer failover para um cluster diferente:

  • O cluster começa a retornar um grande número de erros de sistema temporários.
  • Um grande número de solicitações começa a expirar.
  • A latência média de resposta aumenta até um nível inaceitável.

Como esses sinais podem ser exibidos por muitos motivos diferentes, o failover para um cluster diferente não oferece garantia de que resolva o problema subjacente. Monitore a instância antes e depois do failover para verificar se as métricas melhoraram.

Para detalhes sobre como concluir um failover manual, consulte Como concluir um failover manual.

Failovers automáticos

Se um perfil de aplicativo usa roteamento de vários clusters, o Bigtable processará failovers automaticamente. Quando o cluster mais próximo não consegue processar uma solicitação, o Bigtable roteia o tráfego para outro cluster mais próximo disponível.

Os failovers automáticos poderão ocorrer mesmo se um cluster estiver indisponível por um curto período. Por exemplo, quando o Bigtable encaminha uma solicitação para um cluster que está excessivamente lento para responder ou retorna um erro transitório, o Bigtable costuma repetir essa solicitação em outro cluster.

Se você estiver usando o roteamento de vários clusters e enviar uma solicitação com um prazo, o Bigtable fará o failover automaticamente quando necessário para ajudar a cumprir o prazo. Se o prazo da solicitação estiver terminando, mas o cluster inicial não tiver enviado uma resposta, o Bigtable reencaminhará a solicitação para o cluster seguinte mais próximo.

O Bigtable usa um algoritmo interno de a última gravação prevalecer para lidar com conflitos de dados que possam ocorrer como resultado do failover antes da conclusão da replicação. Consulte Resolução de conflitos para mais detalhes.

Se você estiver usando replicação com roteamento de vários clusters para conseguir alta disponibilidade (HA, na sigla em inglês) para seu aplicativo, localize seus clientes servidores ou VMs perto ou em mais de uma região do Google Cloud. Essa recomendação se aplica mesmo que seu servidor de aplicativos não seja hospedado pelo Google Cloud, porque os dados entram na rede do Google Cloud por meio da região do Google Cloud, mais próxima do seu servidor de aplicativos. Como qualquer pedido, um failover é concluído mais rapidamente em distâncias mais curtas.

Muitos failovers automáticos são tão rápidos que nem são percebidos. É possível verificar o gráfico Failovers automáticos no Console do Google Cloud para ver o número de solicitações que foram reencaminhadas automaticamente durante um período determinado. Para isso, abra a lista de instâncias, clique no nome da instância e depois em Monitoramento.

A seguir