Migrar uma tabela de 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 no BigQuery, mas configurou o 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 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 tempo, e é preciso pausar temporariamente o stream durante a operação. Para manter a integridade dos dados, o banco de dados de origem precisa reter os registros de mudanças quando o stream é pausado. Para estimar por quanto tempo pausar o stream, combine o valor de max_staleness no conjunto de dados e a operação de mesclagem mais longa:
    • Para informações sobre quanto tempo as operações de mesclagem podem levar para serem 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 max_staleness atual de uma tabela e ajuste a consulta às suas necessidades específicas.
    • Se a pausa estimada for muito longa para o 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á fazendo 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á realizando a migração tem permissões suficientes para executar essa operação, como controles do Identity and Access Management (IAM) ou do 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 essa consulta no INFORMATION_SCHEMA do BigQuery 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 defasagem 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 stream do Datastream atual. Para mais informações, consulte Pausar o stream.

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

  6. Confirme se as mudanças mais recentes 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 é 10 minutos depois da pausa do stream:

    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 para a qual você quer verificar o 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 é posterior ao upsert_stream_apply_watermark capturado na etapa 6.

  8. Como opção, compare 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.

  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 não quiser incorrer em cobranças extras, 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.

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

  12. Inicie a nova transmissão.

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

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

  13. Opcionalmente, exclua o stream original.