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:
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:
- Storage. Os bytes de armazenamento na região secundária são faturados como uma cópia separada na região secundária. Consulte Preços de armazenamento do BigQuery.
- Replicação de dados. Para mais informações sobre como você é cobrado pela replicação de dados, consulte Preços de replicação de dados.
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:
- 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.
- A largura de banda de replicação para a operação de cópia inicial é limitada a 1 GB/segundo por projeto por par de continentes. A replicação com essa velocidade não é garantida.
- 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 é 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
multirregionalus-west1
-us
multirregionaleu-west1
-eu
multirregionaleu-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 umreplica_kms_key
que foi criado na região do conjunto de dados de réplica ao usar a instrução DDLALTER 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 definirreplica_kms_key
.Se você estiver usando a rotação de chaves do Cloud KMS na
default_kms_key
oureplica_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çãoreplica_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.- Adicione um valor
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
- Saiba como trabalhar com conexões do BigQuery.
- Saiba mais sobre os recursos de confiabilidade do BigQuery.