Migrar uma tabela de CDC para outra região

É possível mover um conjunto de dados de destino do Datastream para outra região ou multirregião do BigQuery usando a replicação de conjuntos de dados entre regiões. Esse fluxo de trabalho atualiza o local de um conjunto de dados de captura de dados alterados (CDC) ativo, minimizando o tempo de inatividade do stream e evitando um backfill histórico completo do banco de dados de origem.

Durante a migração, a consulta da região secundária pode retornar resultados incompletos ou imprecisos. Para mais informações sobre as limitações da migração, consulte Replicação de conjuntos de dados entre regiões.

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 é necessário pausar temporariamente o stream durante a operação. Para manter a integridade de dados, o banco de dados de origem precisa reter os registros de alterações quando o stream é pausado. Para estimar quanto tempo o stream precisa ser pausado, 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 recomendado de tabela max_staleness valor.
    • Para encontrar o max_staleness máximo no conjunto de dados, consulte Determinar o valor max_staleness atual de uma tabela e ajustar 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á 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 do Identity and Access Management (IAM) ou do VPC Service Controls.

Etapas da migração

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

  1. No Google Cloud console do, 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 alguns minutos da principal. É 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 Google Cloud projeto.
    • DATASET_NAME: o nome do conjunto de dados.
    • DATASET_REPLICA_STALENESS: a configuração de obsolescência 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. Para mais informações, consulte Pausar o stream.

  5. Aguarde até que o stream seja esgotado e anote o horário em que ele entrou no estado PAUSED.

  6. Confirme se as mudanças mais recentes do 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 de quando 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 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 à upsert_stream_apply_watermark capturada na etapa 6.

  8. Opcional: 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 comando a seguir 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. Opcional: 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 descarte 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 stream com a mesma configuração, mas com um novo local de destino do BigQuery.

  12. 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: é possível identificar a posição do registro examinando os registros do stream original e encontrando a última posição em que o stream foi lido com sucesso. Para informações sobre como iniciar o stream de uma posição específica, consulte Gerenciar streams.
    • Para origens PostgreSQL: o novo stream 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 stream original já pode ter processado algumas dessas mudanças, altere manualmente o ponteiro do slot de replicação para o último LSN em que o Datastream foi lido. É possível encontrar esse LSN nos registros de consumidor do Datastream.
  13. Opcional: exclua o stream original.