Replicação de conjuntos de dados entre regiões

Com a replicação de conjunto de dados do BigQuery, é possível configurar a replicação automática de um conjunto de dados entre duas regiões ou multirregiões diferentes.

Visão geral

Ao criar um conjunto de dados no BigQuery, você seleciona a região ou a multirregião em que os dados são armazenados. Uma região é uma coleção de data centers em uma área geográfica, e uma multirregião é uma área geográfica grande que contém duas ou mais regiões geográficas. Seus dados são armazenados em um dos nas regiões contidas e não é replicada na multirregião. Para mais informações sobre regiões e multirregiões, consulte BigQuery locais.

O BigQuery sempre armazena cópias dos dados em duas zonas diferentes do Google Cloud no local do conjunto de dados. Uma zona é uma área de implantação de recursos do Google Cloud em uma região. Em todas as regiões, a replicação entre zonas usa gravações duplas síncronas. A seleção de um local multirregional não oferece replicação entre regiões ou redundância regional. Portanto, não há aumento na disponibilidade do conjunto de dados no caso de uma interrupção regional. Os dados são armazenados em uma única região dentro da localização geográfica.

Para ter mais redundância geográfica, replique qualquer conjunto de dados. O BigQuery cria uma réplica secundária do conjunto de dados, localizada em outra região especificada. Essa réplica é replicada de maneira assíncrona entre duas zonas com a outra região, totalizando quatro cópias zonais.

Replicação de conjuntos de dados

Se você replicar um conjunto de dados, o BigQuery armazenará os dados na região que você especificar.

  • Região principal. Quando você cria um conjunto de dados, o BigQuery o coloca na região principal.

  • Região secundária. Quando você adiciona uma réplica do conjunto de dados, o BigQuery a coloca na região secundária.

Inicialmente, a réplica na região principal é a réplica primária e a réplica na região secundária é a réplica secundária.

A réplica primária é gravável, e a secundária é somente leitura. As gravações na réplica primária são replicadas de forma assíncrona na réplica secundária. Em cada região, os dados são armazenados de modo redundante em duas zonas. O tráfego de rede nunca sai da rede do Google Cloud.

No diagrama a seguir, mostramos a replicação que ocorre quando um conjunto de dados é replicado:

A réplica primária na zona principal da região 1 é replicada simultaneamente nas zonas primária e secundária da região 2.

Se a região principal estiver on-line, será possível alternar manualmente para a réplica secundária. Para mais informações, consulte Promover a réplica secundária.

Preços

Os seguintes conjuntos de dados replicados serão cobrados:

Capacidade de computação na região secundária

Para executar jobs e consultas na réplica na região secundária, é necessário comprar slots nessa região ou executar uma consulta sob demanda.

É possível usar os slots para realizar consultas somente leitura a partir da réplica secundária. Se você promover a réplica secundária para ser a principal, também será possível usar esses slots para gravar na réplica.

É possível comprar o mesmo número de slots que você tem na região principal ou um número diferente de slots. Se você comprar menos slots, isso pode afetar o desempenho da consulta.

Considerações sobre o local

Antes de adicionar uma réplica de conjunto de dados, crie o conjunto de dados inicial que você quer replicar no BigQuery, caso ainda não exista. O local da réplica adicionada é definido como aquele que você especifica ao adicionar a réplica. O local da réplica adicionada precisa ser diferente do local do conjunto de dados inicial. Isso significa que os dados no conjunto são replicados continuamente entre o local onde o conjunto de dados foi criado e o local da réplica. Para réplicas que exigem colocation, como visualizações, visualizações materializadas, tabelas externas não BigLake, adicionar uma réplica em um local diferente ou não compatível com o local dos dados de origem pode resultar em erros de trabalho.

Quando os clientes replicam um conjunto de dados entre regiões, o BigQuery garante que os dados estejam localizados apenas nos locais em que as réplicas foram criadas.

Requisitos de colocation

O uso da replicação de conjunto de dados depende dos requisitos de colocation a seguir.

Cloud Storage

Para consultar dados no Cloud Storage, é necessário que o bucket do Cloud Storage esteja colocado com a réplica. Use as considerações de local de tabelas externas ao decidir onde colocar sua réplica.

Limitações

A replicação do conjunto de dados do BigQuery está sujeita às seguintes limitações:

  • A replicação de conjuntos de dados entre regiões está disponível no mesmo projeto do Google Cloud. Não é possível criar réplicas se os conjuntos de dados de origem e de destino estiverem em projetos diferentes do Google Cloud.
  • Os dados nos streams que não foram confirmados não serão replicados na réplica secundária se a tabela for gravada com a API BigQuery Storage Write. A replicação de dados de streaming da API BigQuery Storage Write ou tabledata.insertAll é o melhor esforço e pode apresentar um alto atraso de replicação.
  • A API BigQuery Storage Read não aceita a leitura de tabelas contidas na réplica secundária do conjunto de dados. Para fazer a leitura de uma tabela contida na réplica secundária, ela precisa primeiro ser promovida para ser a réplica principal.
  • Não há suporte a tabelas injetadas pelo Datastream no BigQuery usando a captura de dados alterados.
  • A replicação e a alternância são gerenciadas por meio de instruções de linguagem de definição de dados (DDL) SQL.
  • Você tem o limite de uma réplica de cada conjunto de dados para cada região ou multirregião. Não é possível criar duas réplicas secundárias do mesmo conjunto de dados na mesma região de destino.
  • Os recursos nas réplicas estão sujeitos às limitações descritas em Comportamento de recursos.
  • As tags de política e as políticas de dados associadas não são replicadas para a réplica secundária. Qualquer consulta que faz referência a colunas com tags de política em regiões diferentes da região original falha, mesmo que essa réplica seja promovida.
  • A viagem no tempo só fica disponível na réplica secundária após a conclusão da criação dela.
  • Só é possível replicar conjuntos de dados com menos de 100 mil tabelas.
  • Há um limite de quatro réplicas adicionadas (e depois descartadas) à mesma região por conjunto de dados por dia.
  • Você está limitado pela largura de banda.
  • Tabelas com chaves de criptografia gerenciadas pelo cliente (CMEK) aplicadas não poderão ser consultadas na região secundária se o valor replica_kms_key não estiver configurado.
  • Não há suporte para tabelas do BigLake.
  • Não há suporte para locais do BigQuery Omni.
  • Não é possível configurar os seguintes pares de regiões se você estiver configurando a replicação de dados para recuperação de desastres:
    • us-central1 - us multirregional
    • us-west1 - us multirregional
    • eu-west1 - eu multirregional
    • eu-west4 - eu multirregional

Comportamento do recurso

As operações a seguir não são compatíveis com os recursos da réplica secundária:

Se você precisar criar uma cópia de um recurso em uma réplica secundária, copie o recurso ou consulte-o e materialize os resultados fora da réplica secundária. Por exemplo, use CREATE TABLE AS SELECT para criar um novo recurso a partir do recurso de réplica secundário.

As réplicas primárias e secundárias estão sujeitas às seguintes diferenças:

Réplica primária da região 1 Réplica secundária da região 2 Observações
Tabela do BigLake Tabela do BigLake Incompatível.
Tabela externa Tabela externa Somente a definição da tabela externa é replicada. A consulta falha quando o bucket do Cloud Storage não está colocalizado no mesmo local que uma réplica.
Visualização lógica Visualização lógica As visualizações lógicas que fazem referência a um conjunto de dados ou recurso que não está localizado no mesmo local que a visualização lógica falham quando consultadas.
Tabela gerenciada Tabela gerenciada Nenhuma diferença.
Visualização materializada Visualização materializada Se uma tabela referenciada não estiver na mesma região que a visualização materializada, a consulta falhará. As visualizações materializadas replicadas podem ter uma inatividade acima da inatividade máxima.
Modelo Modelo Armazenadas como tabelas gerenciadas.
Função remota Função remota As conexões são regionais. As funções remotas que fazem referência a um conjunto de dados ou recurso (conexão) que não está localizado no mesmo local que a função remota falham quando são executadas.
Rotinas Função definida pelo usuário (UDF) ou procedimento armazenado As rotinas que fazem referência a um conjunto de dados ou recurso que não está localizado no mesmo local que a rotina falham quando são executadas. Qualquer rotina que faça referência a uma conexão, como funções remotas, não funciona fora da região de origem.
Política de acesso a linhas Política de acesso a linhas Nenhuma diferença.
Índice da Pesquisa Índice da Pesquisa Não replicado.
Procedimento armazenado Procedimento armazenado Os procedimentos armazenados que se referem a um conjunto de dados ou recurso que não está localizado no mesmo local que o procedimento armazenado falham quando executados.
Clone da tabela Tabela gerenciada Faturado como cópia detalhada na réplica secundária.
Snapshot da tabela Snapshot da tabela Faturado como cópia detalhada na réplica secundária.
Função com valor de tabela (TVF) TVF Os TVFs que se referem a um conjunto de dados ou recurso que não está localizado no mesmo local que o TVF falham quando executados.
UDF UDF UDFs que fazem referência a um conjunto de dados ou recurso que não está localizado no mesmo local que a UDF falham quando são executadas.

Cenários de interrupção temporária

A replicação entre regiões não se destina ao uso como plano de recuperação de desastres durante uma interrupção total na região. No caso de uma interrupção total da região na região da réplica principal, não é possível promover a réplica secundária. Como as réplicas secundárias são somente leitura, não é possível executar jobs de gravação na réplica secundária e nem promover a região secundária até que a região da réplica principal seja restaurada. Para mais informações sobre como se preparar para a recuperação de desastres, consulte Recuperação de desastres gerenciada.

A tabela a seguir explica o impacto das interrupções do total de regiões nos dados replicados:

Região 1 Região 2 Região de interrupção temporária Impacto
Réplica primária Réplica secundária Região 2 Os jobs somente leitura em execução na região 2 na réplica secundária falham.
Réplica primária Réplica secundária Região 1 Todos os jobs em execução na região 1 falham. Jobs somente leitura continuam a ser executados na região 2 em que a réplica secundária está localizada. O conteúdo da região 2 fica desatualizado até que seja sincronizado com a região 1.

Usar replicação do conjunto de dados

Nesta seção, descrevemos como replicar um conjunto de dados, promover a réplica secundária e executar jobs de leitura do BigQuery na região secundária.

Permissões necessárias

Para receber as permissões necessárias para gerenciar réplicas, peça ao administrador para conceder a você a permissão bigquery.datasets.update.

Replicar um conjunto de dados

Para replicar um conjunto de dados, use a instrução DDL ALTER SCHEMA ADD REPLICA.

É possível adicionar uma réplica a qualquer conjunto de dados localizado em uma região ou multirregião que ainda não tenha sido replicado nessa região ou multirregião. Depois de adicionar uma réplica, a operação inicial de cópia leva algum tempo para ser concluída. Ainda é possível executar consultas que mencionem a réplica principal enquanto os dados estiverem sendo replicados, sem redução na capacidade de processamento da consulta. Não é possível replicar dados nos locais geográficos em uma multirregião.

O exemplo a seguir cria um conjunto de dados chamado my_dataset na região us-central1 e, em seguida, adiciona uma réplica na região us-east4:

-- Create the primary replica in the us-central1 region.
CREATE SCHEMA my_dataset OPTIONS(location='us-central1');

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `my_replica`
OPTIONS(location='us-east4');

Para confirmar quando a réplica secundária foi criada com êxito, consulte a coluna creation_complete na visualização INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

Promover a réplica secundária

Se a região principal estiver on-line, será possível promover a réplica secundária. A promoção muda a réplica secundária para ser a principal gravável. Essa operação será concluída em alguns segundos se a réplica secundária estiver conectada à principal. Se a réplica secundária não estiver atualizada, a promoção não poderá ser concluída até que ela seja. A réplica secundária não poderá ser promovida a principal se a região que contém a principal tiver uma interrupção.

Observações:

  • Todas as gravações em tabelas retornam erros enquanto a promoção está em andamento. A réplica primária antiga se torna não gravável imediatamente quando a promoção começa.
  • As tabelas que não são totalmente replicadas no momento em que a promoção é iniciada retornam leituras desatualizadas.

Para promover uma réplica a ser a réplica principal, use a instrução DDL ALTER SCHEMA SET OPTIONS e defina a opção primary_replica.

Lembre-se disto: é necessário definir explicitamente o local do job como a região secundária nas configurações da consulta. Consulte Locais específicos do BigQuery.

O exemplo a seguir promove a réplica us-east4 para que seja a principal:

ALTER SCHEMA my_dataset SET OPTIONS(primary_replica = 'us-east4')

Para confirmar quando a réplica secundária foi promovida, consulte a coluna replica_primary_assignment_complete na visualização INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

Remover uma réplica de conjunto de dados

Para remover uma réplica e interromper a replicação do conjunto de dados, use a instrução DDL ALTER SCHEMA DROP REPLICA.

O exemplo a seguir remove a réplica us:

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `us`;

Primeiro, você precisa descartar todas as réplicas secundárias para excluir todo o conjunto de dados. Se você excluir todo o conjunto de dados, por exemplo, usando a instrução DROP SCHEMA, sem descartar todas as réplicas secundárias, receberá um erro.

Listar réplicas do conjunto de dados

Para listar as réplicas do conjunto de dados em um projeto, consulte a visualização INFORMATION_SCHEMA.SCHEMATA_REPLICAS.

Migrar conjuntos de dados

Use a replicação de conjuntos de dados entre regiões para migrar seus conjuntos de dados de uma região para outra. O exemplo a seguir demonstra o processo de migração do conjunto de dados my_migration atual da multirregião US para a multirregião EU usando replicação entre regiões.

Replicar o conjunto de dados

Para iniciar o processo de migração, primeiro replique o conjunto de dados na região para onde você quer migrar os dados. Neste cenário, você está migrando o conjunto de dados my_migration para a multirregião EU.

-- Create a replica in the secondary region.
ALTER SCHEMA my_migration
ADD REPLICA `eu`
OPTIONS(location='eu');

Isso cria uma réplica secundária chamada eu na multirregião EU. A réplica principal é o conjunto de dados my_migration na multirregião US.

Promover a réplica secundária

Para continuar migrando o conjunto de dados para a multirregião EU, promova a réplica secundária:

ALTER SCHEMA my_migration SET OPTIONS(primary_replica = 'eu')

Depois que a promoção for concluída, eu será a réplica principal. Ela é uma réplica gravável.

Conclua a migração

Para concluir a migração da multirregião US para a multirregião EU, exclua a réplica us. Esta etapa não é necessária, mas é útil se você não precisar de uma réplica de conjunto de dados além das suas necessidades de migração.

ALTER SCHEMA my_migration
DROP REPLICA IF EXISTS us;

Seu conjunto de dados está localizado na multirregião EU e não há réplicas do conjunto de dados my_migration. Você migrou seu conjunto de dados para a multirregião EU. A lista completa de recursos migrados pode ser encontrada em Comportamento do recurso.

Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês)

As chaves do serviço de gerenciamento de chaves do Cloud gerenciadas pelo cliente não são replicadas automaticamente quando você cria uma réplica secundária. Para manter a criptografia no conjunto de dados replicado, defina o replica_kms_key para o local da réplica adicionada. É possível definir o replica_kms_key usando a instrução DDL ALTER SCHEMA ADD REPLICA.

A replicação de conjuntos de dados com CMEK se comporta conforme descrito nos seguintes cenários:

  • Se o conjunto de dados de origem tiver um default_kms_key, será necessário fornecer um replica_kms_key que foi criado na região do conjunto de dados de réplica ao usar a instrução DDL ALTER SCHEMA ADD REPLICA.

  • Se o conjunto de dados de origem não tiver um valor definido para default_kms_key, não será possível definir replica_kms_key.

  • Se você estiver usando a rotação de chaves do Cloud KMS na default_kms_key ou replica_kms_key (ou ambas), o conjunto de dados replicado ainda poderá ser consultado após a rotação de chaves.

    • A rotação de chaves na região principal atualiza a versão da chave apenas nas tabelas criadas após a rotação. As tabelas que existiam antes da rotação ainda usam a versão definida antes da rotação.
    • A rotação de chaves na região secundária atualiza todas as tabelas na réplica secundária para a nova versão da chave.
    • Alternar a réplica primária para a secundária atualiza todas as tabelas na réplica secundária (anteriormente a réplica primária) para a versão da chave nova.
    • Se a versão da chave definida nas tabelas da réplica primária antes da rotação de chaves for excluída, as tabelas que ainda usarem essa versão não poderão ser consultadas até que a versão da chave seja atualizada. Para atualizar a versão da chave, a versão antiga precisa estar ativa (não desativada ou excluída).

  • Se o conjunto de dados de origem não tiver um valor definido para default_kms_key, mas houver tabelas individuais no conjunto de origem com a CMEK aplicada, elas não poderão ser consultadas no conjunto de dados replicado. Para consultar as tabelas, faça o seguinte:

    • Adicione um valor default_kms_key para o conjunto de dados de origem.
    • Ao criar uma nova réplica usando a instrução DDL ALTER SCHEMA ADD REPLICA, defina um valor para a opção replica_kms_key. É possível consultar as tabelas CMEK na região de destino.

    Todas as tabelas CMEK na região de destino usam a mesma replica_kms_key, independentemente da chave usada na região de origem.

Criar uma réplica com CMEK

O exemplo a seguir cria uma réplica na região us-west1 com um valor replica_kms_key definido. Para a chave CMEK, conceda permissão à conta de serviço do BigQuery para criptografar e descriptografar.

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `us-west1`
OPTIONS(location='us-west1',
  replica_kms_key='my_us_west1_kms_key_name');

Limitações da CMEK

A replicação de conjuntos de dados com a CMEK aplicada está sujeita às seguintes limitações:

  • Não é possível atualizar a chave replicada do Cloud KMS após a criação da réplica.

  • Não é possível atualizar o valor default_kms_key no conjunto de dados de origem após a criação das réplicas do conjunto de dados.

  • Se o replica_kms_key fornecido não for válido na região de destino, o conjunto de dados não será replicado.

  • As tabelas criptografadas pela CMEK replicadas para a região de destino são visíveis, mas não podem ser consultadas ou gravadas porque a CMEK de origem não é reconhecida na região de destino.

A seguir