Migrar uma tabela de CDC para outra região

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

Antes de começar

Antes de migrar seus dados para outra região, considere as seguintes:

  • A migração leva tempo, e você deve pausar temporariamente o stream durante a operação Para manter a integridade dos dados, o banco de dados de origem deve manter as os registros de alteração quando o stream é pausado. Para estimar por quanto tempo pausar a transmissão, combinam o valor de max_staleness no conjunto de dados e o operação de mesclagem:
    • Para informações sobre quanto tempo pode levar para que as operações de mesclagem sejam concluídas, consulte Valor max_staleness recomendado para a tabela.
    • Para encontrar o max_staleness máximo no conjunto de dados, consulte Determinar o valor atual de max_staleness de uma tabela e ajuste a consulta às suas necessidades específicas.
    • Se a pausa estimada for muito longa para ser aceita pelo seu banco de dados de origem, considere reduzir temporariamente o valor de max_staleness para as tabelas no conjunto de dados.
  • Verifique se o usuário que está executando a migração tem dados suficientes do BigQuery recursos na região de destino (consultar reserva 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 executar essa operação, como os controles de Identity and Access Management (IAM) ou VPC Service Controls.

Etapas da migração

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

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

    Acessar o BigQuery Studio

  2. 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.

  3. Monitore o progresso da migração e aguarde até que a marca d'água de cópia na réplica esteja a poucos minutos da primária. É possível executar esta consulta no BigQuery INFORMATION_SCHEMA 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 desatuação 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.

  4. Pause o fluxo do Datastream. Para mais informações, consulte Pause o stream.

  5. Aguarde o fluxo ser drenado e anote o momento em que ele entrou no estado PAUSED.

  6. Confirme se as últimas mudanças de CDC foram aplicadas à tabela do BigQuery verificando o upsert_stream_apply_watermark da tabela. Execute a consulta a seguir e verifique se o carimbo de data/hora da marca d'água está 10 minutos depois do momento em que a transmissão foi pausada:

    SELECT table_name, upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES

    Para executar a consulta apenas em 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 upsert_stream_apply_watermark:

  7. Use a consulta da etapa 3 para verificar se a nova marca-d'água de cópia da região é depois do upsert_stream_apply_watermark capturado na etapa 6.

  8. Como opção, compare manualmente diversas tabelas do conjunto de dados principal na região original com a réplica na nova região para verificar se todos os dados for copiado corretamente.

  9. Promova a réplica do conjunto de dados do BigQuery executando o seguinte comando no BigQuery Studio:

    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.

  10. Opcionalmente, se você não precisar mais do conjunto de dados original (agora a réplica), e sem custos adicionais, acesse o BigQuery Studio e remova 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.

  11. Crie uma nova transmissão com a mesma configuração, mas com um novo local de destino do BigQuery.

  12. Inicie a nova transmissão.

    Para evitar a duplicação de eventos, inicie o fluxo de uma posição específica:

    • Para origens do MySQL e Oracle: é possível identificar a posição do registro analisando os registros do fluxo original e encontrando a última posição em que o fluxo foi lido. Para informações sobre como iniciar o stream de uma posição específica, consulte Gerenciar transmissões.
    • Para origens do PostgreSQL: o novo fluxo começa a ler as mudanças do primeiro número de sequência de registro (LSN, na sigla em inglês) no slot de replicação. Como o fluxo original já pode ter processado algumas dessas mudanças, mude manualmente o ponteiro do slot de replicação para o último LSN lido pelo Datastream. Esse LSN está nos registros do consumidor do Datastream.

  13. Se quiser, exclua o stream original.