Failovers

Se um cluster do Bigtable deixar de responder, a replicação permitirá que o tráfego recebido faça failover 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ê usar 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 se aproximar e o cluster inicial não tiver enviado uma resposta, o Bigtable vai redirecionar a solicitação para o cluster mais próximo. O prazo definido influencia a rapidez com que isso acontece: um prazo mais curto aciona um failover mais cedo, enquanto um prazo mais longo permite mais tempo antes do failover.

Verifique se o prazo é longo o suficiente para que a solicitação de failover seja concluída com êxito em um cluster subsequente, principalmente se o cluster subsequente estiver em uma região diferente.

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 Google Cloud região. Essa recomendação se aplica mesmo que o servidor de aplicativos não esteja hospedado pelo Google Cloud, porque os dados entram na Google Cloud rede pela Google Cloud região mais próxima do 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. Verifique o gráfico Failovers automáticos no Google Cloud console para ver o número de solicitações que foram roteadas novamente de maneira automática em determinado período. Para isso, abra a lista de instâncias, clique no nome da instância e em Insights do sistema.

A seguir