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 a replicação do Datastream para o 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 todos os dados do banco de dados de origem com 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 você precisa pausar temporariamente o stream durante a operação. Para manter a integridade dos dados, o banco de dados de origem precisa reter os logs de alterações quando o stream é pausado. Para estimar o tempo de pausa do fluxo, combine o valor de max_staleness no conjunto de dados e a operação de mesclagem mais longa:
  • Verifique se o usuário que está realizando 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 realizar essa operação, como controles de gerenciamento de identidade e acesso (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 projeto 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 Pausar 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 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 para a qual você quer verificar o upsert_stream_apply_watermark.
  7. Use a consulta da etapa 3 para verificar se a marca d'água da nova cópia da região é posterior à upsert_stream_apply_watermark capturada 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. Se você não precisar mais do conjunto de dados original (agora a réplica) e não quiser gerar cobranças extras, acesse o BigQuery Studio e exclua 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 uma nova transmissão com a mesma configuração, mas com um novo local de destino do BigQuery.

  12. Inicie o novo stream.

    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. Você pode encontrar esse LSN nos registros do consumidor do Datastream.
  13. Se quiser, exclua o stream original.