Migrar uma tabela CDC para outra região

Nesta página, descrevemos as práticas recomendadas para um caso de uso em que você configurou a replicação do Datastream para o BigQuery, mas configurou o conjunto de dados de destino em uma região incorreta. Em seguida, mova o conjunto de dados para outra região (ou multirregião) sem precisar sincronizar novamente todos os dados do banco de dados de origem para o BigQuery.

Antes de começar

Antes de começar a migrar seus dados para outra região, considere o seguinte:

A migração leva algum tempo, e você precisa pausar o stream temporariamente durante a operação. Para manter a integridade dos dados, o banco de dados de origem precisa reter os registros de alterações quando o stream é pausado. Para estimar por quanto tempo pausar o stream, combine o valor de max_staleness no conjunto de dados com a operação de mesclagem mais longa:
- Para informações sobre quanto tempo pode levar para a conclusão das operações de mesclagem, consulte Valor max_staleness recomendado da tabela.
- Para encontrar o max_staleness máximo no conjunto de dados, consulte Determinar o valor atual do max_staleness de uma tabela e ajuste a consulta de acordo com suas necessidades específicas.
- Se a pausa estimada for muito longa para o banco de dados de origem, recomendamos reduzir temporariamente o valor de max_staleness para as tabelas no conjunto de dados.
Verifique se o usuário que executa a migração tem recursos suficientes do BigQuery na região de destino (reserva de consulta e reserva em segundo plano). Para mais informações sobre reservas, consulte Atribuições de reserva.
Verifique se o usuário que está executando a migração tem permissões suficientes para realizar a operação, como os controles de Identity and Access Management (IAM) ou VPC Service Controls.

Etapas da migração

Para iniciar a migração do conjunto de dados, use a replicação de dados do BigQuery:

No console do Google Cloud, acesse a página BigQuery Studio.

Acessar o BigQuery Studio
Crie uma réplica do conjunto de dados do BigQuery na nova região:
```
ALTER SCHEMA DATASET_NAME
ADD REPLICA 'NEW_REGION'
OPTIONS(location='NEW_REGION');
```
Substitua:
- DATASET_NAME: o nome do conjunto de dados que você quer criar.
- NEW_REGION: o nome da região em que você quer criar o conjunto de dados. Por exemplo, region-us.
Monitore o progresso da migração e aguarde até que a marca-d'água da cópia na réplica esteja dentro de alguns minutos da principal. É possível executar esta consulta no BigQuery INFORMATION_ trace para verificar o progresso da migração:
```
SELECT
catalog_name as project_id,
schema_name as dataset_name,
replication_time as dataset_replica_staleness
FROM
'NEW_REGION'.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
catalog_name = PROJECT_ID
AND schema_name = DATASET_NAME
AND location = NEW_REGION;
```
Substitua:
- PROJECT_ID: o ID do seu projeto do Google Cloud.
- DATASET_NAME: o nome do conjunto de dados.
- DATASET_REPLICA_STALENESS: a configuração de inatividade das tabelas na réplica do conjunto de dados que você criou.
- NEW_REGION: a região em que você criou o conjunto de dados.
Pause o fluxo do Datastream atual. Para mais informações, consulte Pausar o stream.
Aguarde o fluxo ser drenado e anote o horário em que ele entrou no estado PAUSED.
Para confirmar se as alterações mais recentes do CDC foram aplicadas à tabela do BigQuery, verifique o upsert_stream_apply_watermark da tabela. Execute a consulta a seguir e verifique se o carimbo de data/hora da marca d'água foi 10 minutos depois do momento em que o stream foi pausado:
```
SELECT table_name, upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES
```
Para executar a consulta apenas para uma tabela específica, adicione a seguinte cláusula WHERE:
```
WHERE table_name = 'TABLE_NAME'
```
Substitua:
- DATASET_NAME: o nome do conjunto de dados.
- TABLE_NAME: opcional. A tabela em que você quer verificar o upsert_stream_apply_watermark.
Use a consulta da etapa 3 para verificar se a nova marca-d'água de cópia da região é posterior ao upsert_stream_apply_watermark capturado na etapa 6.
Outra opção é comparar manualmente várias tabelas no conjunto de dados principal na região original com a réplica na nova região para verificar se todos os dados foram copiados corretamente.
Execute o comando a seguir no BigQuery Studio para promover a réplica do conjunto de dados do BigQuery:
```
ALTER SCHEMA DATASET_NAME
SET OPTIONS(primary_replica = 'NEW_REGION');
```
Substitua:
- DATASET_NAME: o nome do conjunto de dados.
- NEW_REGION: a região em que você criou o conjunto de dados.
Opcionalmente, se você não precisar mais do conjunto de dados original (agora a réplica) e não quiser gerar cobranças adicionais, acesse o BigQuery Studio e solte o conjunto de dados original do BigQuery:
```
ALTER SCHEMA DATASET_NAME DROP REPLICA IF EXISTS ORIGINAL_REGION;
```
Substitua:
- DATASET_NAME: o nome do conjunto de dados original.
- ORIGINAL_REGION: a região do conjunto de dados original.
Crie um novo stream com exatamente a mesma configuração, mas com o novo local de destino do BigQuery.
Inicie o novo stream.

Para evitar a replicação de eventos duplicados, inicie o stream de uma posição específica:
- Para origens MySQL e Oracle: você pode identificar a posição do registro examinando os registros do stream original e encontrando a última posição da qual o stream foi lido. Para informações sobre como iniciar o stream em uma posição específica, consulte Gerenciar streams.
- Para origens do PostgreSQL: o novo stream começa a ler as alterações do primeiro número de sequência de registro (LSN, na sigla em inglês) no slot de replicação. Como o stream original pode já ter processado algumas dessas alterações, altere manualmente o ponteiro do slot de replicação para o último LSN lido pelo Datastream. Esse LSN está disponível nos registros do consumidor do Datastream.
Se quiser, exclua o stream original.