Visão geral da replicação

Com a replicação do Cloud Bigtable, é possível aumentar a disponibilidade e a durabilidade dos dados com a respectiva cópia em várias regiões ou zonas. Também é possível isolar cargas de trabalho encaminhando tipos diferentes de solicitações para clusters distintos.

Nesta página, explicaremos como a replicação funciona no Cloud Bigtable e alguns casos de uso para replicação. Você conhecerá o modelo de consistência usado pelo Cloud Bigtable quando a replicação está ativada e saberá o que acontece quando ocorre um failover de um cluster para outro.

Antes de ler esta página, conheça a visão geral do Cloud Bigtable.

Como a replicação funciona

Para usar a replicação em uma instância do Cloud Bigtable, crie uma nova instância com mais de um cluster ou adicione clusters a uma atual.

O Cloud Bigtable aceita até quatro clusters replicados localizados nas zonas do Google Cloud Platform em que o Cloud Bigtable estiver disponível. Os clusters de uma instância precisam estar em zonas exclusivas. É possível criar outro cluster em qualquer zona em que o Cloud Bigtable esteja disponível. Colocar clusters em zonas ou regiões diferentes permite que você acesse os dados mesmo que uma zona ou região do Google Cloud se torne indisponível.

Quando uma instância com mais de um cluster é criada, o Cloud Bigtable começa imediatamente a sincronizar os dados entre os clusters. Isso cria uma cópia separada e independente de seus dados em cada zona em que sua instância tem um cluster. Da mesma maneira, quando um cluster novo é adicionado a uma instância atual, o Cloud Bigtable copia os dados da zona do cluster original para a nova zona e sincroniza as alterações nos dados entre as zonas.

O Cloud Bigtable replica todas as alterações feitas nos dados automaticamente, inclusive todas dos seguintes tipos:

  • atualizações feitas nos dados em tabelas existentes
  • tabelas novas e excluídas
  • famílias de colunas adicionadas e removidas
  • alterações feitas na política de coleta de lixo da família de colunas

O Cloud Bigtable trata cada cluster na instância como um cluster principal. Dessa maneira, é possível realizar leituras e gravações em cada cluster. Também é possível configurar a instância. Dessa maneira, as solicitações de tipos diferentes de aplicativos são encaminhadas para clusters distintos.

Antes de adicionar clusters a uma instância, conheça as restrições que se aplicam quando você altera as políticas de coleta de lixo para tabelas replicadas.

Casos de uso

Nesta seção, descrevemos casos de uso comuns para a replicação do Cloud Bigtable. Para encontrar as melhores configurações de cada caso de uso, bem como as dicas de implementação para outros casos de uso, consulte Exemplos de configurações de replicação.

Isolar aplicativos de serviço de leituras em lote

Quando você usa um único cluster para executar um job de análise em lote que executa várias leituras grandes junto de um aplicativo que realiza uma mescla de leituras e gravações, o job em lote grande pode atrasar as tarefas para os usuários do aplicativo. Com a replicação, é possível usar perfis de aplicativos com encaminhamento de cluster único para enviar jobs de análise em lote e tráfego de aplicativos até clusters diferentes. Assim, os jobs em lote não afetarão os usuários de seus aplicativos. Saiba mais sobre como implementar esse caso de uso.

Melhorar a disponibilidade

Se uma instância tiver apenas um cluster, a durabilidade e a disponibilidade dos seus dados estarão limitadas à zona em que o cluster estiver. A replicação pode melhorar a durabilidade e a disponibilidade armazenando cópias separadas de seus dados em várias zonas ou regiões e fazendo failover automático entre clusters se necessário. Saiba mais sobre como implementar esse caso de uso.

Criar backup quase em tempo real

Em alguns casos, por exemplo, quando você não quiser pagar pela leitura de dados desatualizados, precisará encaminhar as solicitações a um cluster único. No entanto, você ainda pode usar a replicação processando as solicitações com um cluster e mantendo outro cluster como backup quase em tempo real. Se o cluster de serviço ficar indisponível, você poderá minimizar o tempo de inatividade realizando um failover manual no cluster de backup. Saiba mais sobre como implementar esse caso de uso.

Garantir que os dados tenham uma presença global

É possível configurar a replicação em locais em todo o mundo para que seus dados fiquem mais próximos dos seus clientes. Por exemplo, é possível criar uma instância com clusters replicados nos EUA, Europa e Ásia e configurar perfis de aplicativos para encaminhar o tráfego de aplicativos para o cluster mais próximo. Saiba mais sobre como implementar esse caso de uso.

Modelo de consistência

Por padrão, a replicação do Cloud Bigtable tem consistência posterior. Este termo significa que ao gravar uma alteração em um cluster, em algum momento, você conseguirá ler essa alteração de outro cluster na instância, mas só depois que a alteração for replicada entre os clusters.

Caso a instância seja responsiva, o atraso da replicação normalmente levará alguns segundos ou minutos, mas não horas. Porém, caso você esteja gravando um grande volume de dados em um cluster ou caso um cluster esteja sobrecarregado ou indisponível temporariamente, pode demorar algum tempo para a replicação acompanhar. Além disso, a replicação poderá levar mais tempo se os clusters estiverem distantes. Por isso, não pressuponha que você esteja lendo sempre o valor mais recente gravado ou que aguardar alguns segundos após a gravação dê ao Cloud Bigtable tempo suficiente para replicar a alteração.

Se você precisar de uma garantia de consistência diferente, o Cloud Bigtable também poderá oferecer consistência na leitura das gravações quando a replicação estiver ativada, garantindo que um aplicativo jamais lerá dados anteriores às gravações mais recentes. Para conseguir consistência na leitura das gravações para um grupo de aplicativos, cada aplicativo no grupo precisa usar um perfil de aplicativo configurado para o encaminhamento de cluster único e todos os perfis de aplicativo precisam encaminhar pedidos para o mesmo cluster. É possível usar outros clusters da instância simultaneamente para outras finalidades.

Em alguns casos de uso de replicação, o Cloud Bigtable também pode fornecer consistência forte, o que garante que todos os aplicativos vejam os dados no mesmo estado. Para conseguir uma consistência forte, use a configuração de perfil de aplicativo de roteamento de cluster único para ter consistência na leitura das gravações descrita acima. Porém, não use os clusters adicionais da instância, a menos que precise fazer o failover para um cluster diferente. Analise os exemplos de configurações de replicação para ver se isso é possível no seu caso de uso.

Perfis de aplicativo

Caso uma instância use replicação, você usa perfis de aplicativo, ou perfis de app, para controlar quais clusters processam solicitações de entrada com base nos aplicativos. Os perfis de app também determinam se é possível realizar transações de linha única, que incluem operações de leitura/modificação/gravação (inclusive incrementos e acréscimos) e operações de verificação e mutação, também conhecidas como mutações ou gravações condicionais.

Para ver detalhes, consulte Perfis de aplicativo. Para ver exemplos de configurações que podem ser usadas para implementar casos de uso comuns, veja Exemplos de configurações de replicação.

Failovers

Se um cluster do Cloud Bigtable parar de responder, a replicação possibilitará o failover do tráfego de entrada 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.

Para ver detalhes, consulte Failovers.

Como descartar intervalos de linhas quando a replicação estiver ativada

A API Cloud Bigtable Admin permite descartar um intervalo contíguo de linhas de uma tabela com base nas chaves de linha delas. Em instâncias que não usam a replicação, o Cloud Bigtable pode descartar um intervalo de linhas de maneira rápida e eficiente. Porém, quando a replicação está ativada, descartar um intervalo de linhas é bem mais lento e muito menos eficiente.

A seguir