Realizar a transição do MySQL

Este guia descreve como realizar a transição de uma migração de banco de dados ativa de uma instância de origem do MySQL para um banco de dados do Spanner usando o Datastream e o Dataflow.

Antes de começar

Antes de realizar a transição, verifique se você concluiu as seguintes tarefas como parte da migração de dados ativos:

  1. Migração de esquema: implante seu esquema no Spanner. Para mais informações, consulte Migrar um esquema do MySQL.
  2. Migração de backfill: conclua a migração de dados inicial usando o job do Dataflow de migração de backfill. Para mais informações, consulte Realizar a migração de backfill.
  3. Replicação ativa de CDC: verifique se a replicação contínua de captura de dados alterados (CDC) está ativa e íntegra:
    • O stream do Datastream está lendo ativamente eventos de mudança do banco de dados MySQL de origem e gravando-os no bucket do Cloud Storage.
    • As notificações do bucket do Cloud Storage estão publicando eventos de criação de objetos no tópico do Pub/Sub.
    • O job do Dataflow de streaming (Cloud_Datastream_to_Spanner) está consumindo a assinatura do Pub/Sub e gravando mudanças no Spanner com um atraso de replicação de menos de um segundo ou insignificante. Para mais informações, consulte Migrar seus dados do MySQL.
  4. Validação de dados inicial: execute verificações de validação de dados para verificar a consistência dos dados entre a instância de origem do MySQL e o destino do Spanner. Para mais informações, consulte Validar a migração de dados.
  5. Limpar o estado da fila de mensagens inativas (DLQ): verifique se o diretório de DLQ grave de replicação direta no Cloud Storage (por exemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) está completamente vazio. Se houver erros graves, resolva os problemas subjacentes e reproduza todos os eventos de mudança com falha usando um job em lote retryDLQ antes de iniciar a transição. Para mais informações, consulte Monitorar e resolver erros de DLQ de CDC.
  6. Configuração de replicação inversa (preparação de failback): se você precisar de um caminho de failback de contingência, configure um pipeline de replicação inversa ativo do Spanner de volta para o banco de dados MySQL de origem. Para mais informações, consulte Configurar o failback para o MySQL.

Funções exigidas

Realizar a transição

As seções a seguir descrevem como drenar o pipeline de gravação e verificar se todas as mudanças de origem são replicadas para o Spanner antes de mudar as gravações do aplicativo.

Verificar a integridade do pipeline e o estado da DLQ

Antes de pausar o tráfego de gravação do aplicativo ou iniciar o tempo de inatividade, verifique se o pipeline de replicação direta não tem eventos de mudança encalhados na DLQ:

  1. No Google Cloud console, acesse a página Detalhes do job do pipeline do Dataflow de streaming.
  2. Na guia Métricas personalizadas, inspecione o contador personalizado Total permanent errors.

  3. Se esse contador for maior que 0, verifique o diretório de DLQ grave do Cloud Storage (por exemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) e verifique se o diretório está vazio.

Pausar gravações de aplicativos

  1. Pause todo o tráfego de gravação do banco de dados no aplicativo.
  2. Permita que as transações ativas nas instâncias principais do MySQL de origem sejam totalmente confirmadas e esgotadas.

Acompanhar e pausar o Datastream

  1. No Google Cloud console, acesse a página Detalhes do stream para seu stream.
  2. Na guia Monitoramento, inspecione o gráfico Atualização de dados (tipo de métrica do Cloud Monitoring: datastream.googleapis.com/stream/freshness). Aguarde até que o valor da métrica diminua para 0. Isso indica que o Datastream capturou e processou todas as mudanças do banco de dados de origem até o momento em que as gravações foram pausadas. Para mais informações, consulte Monitorar um stream.

  3. Verifique se nenhum evento de replicação passa pelo stream. Na guia Monitoramento, inspecione o gráfico Taxa de transferência (tipo de métrica do Monitoring: datastream.googleapis.com/stream/event_count) e verifique se a taxa de eventos é 0.

    Como alternativa, para verificar programaticamente usando o Metrics Explorer, consulte a contagem de eventos usando a linguagem de consulta do Monitoring (MQL): 

    fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
     Substitua STREAM_ID pelo ID do stream.

    Verifique se essa métrica informa 0 por pelo menos dois períodos de agregação consecutivos.

  4. Pause o stream do Datastream usando o Google Cloud console ou a API e aguarde até que o status do stream mude para PAUSED.

Aguardar a drenagem dos dados de mudança em trânsito

  1. No Google Cloud console, acesse a página Detalhes do stream para seu stream.
  2. Na guia Monitoramento, inspecione o gráfico Latência do sistema (tipo de métrica do Monitoring: datastream.googleapis.com/stream/system_latencies).
  3. Anote o valor de latência do 99º percentil (P99) e aguarde pelo menos duas vezes a latência do sistema P99 mais 30 segundos após pausar o stream. Esse período de espera ajuda a garantir que todos os arquivos de dados de mudança gerados antes da pausa sejam gravados com segurança no Cloud Storage e que os eventos de criação de objetos sejam publicados no Pub/Sub.
  4. Verifique se o job do Dataflow de streaming consumiu todos os eventos de mudança pendentes. No Google Cloud console, acesse a página Assinaturas do Pub/Sub e selecione a assinatura criada durante a configuração da migração de CDC.
  5. Na guia Monitoramento, inspecione o gráfico Contagem de mensagens não reconhecidas (tipo de métrica do Monitoring: pubsub.googleapis.com/subscription/num_undelivered_messages) e verifique se a contagem é 0.

Verificar se a replicação foi concluída

  1. Verifique se o pipeline do Dataflow de streaming terminou de gravar todas as mudanças replicadas. Na página Detalhes do job do job de streaming, selecione a guia Métricas personalizadas e inspecione o contador de usuários Replication lag total latency_MAX. Aguarde até que o valor do contador chegue a 0.

    Como alternativa, no Metrics Explorer, consulte o contador de usuários usando a MQL: 

    fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'Replication lag total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
     Substitua JOB_ID pelo ID do job do Dataflow.

  2. Verifique se a atividade de gravação foi interrompida no banco de dados de destino do Spanner. Na página Detalhes do banco de dados do banco de dados de destino, selecione a guia Monitoramento e inspecione o gráfico Taxa de transferência de gravação (tipo de métrica do Monitoring: spanner.googleapis.com/transaction_stat/total/bytes_written_count). Verifique se a taxa de transferência de gravação é 0 por pelo menos dois períodos de agregação consecutivos de 1 minuto.

  3. Faça uma verificação final da DLQ de replicação direta. Inspecione os diretórios de DLQ grave e de repetição no Cloud Storage (por exemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ e gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/) para verificar se eles permanecem vazios.

  4. Drene o job do Dataflow de streaming:

    1. No Google Cloud console, acesse a página Detalhes do job do seu job de streaming.
    2. Clique em Parar job, selecione Drenar e clique em Parar job.
    3. Aguarde até que o status do job mude para Drained. Para mais informações, consulte Interromper um pipeline em execução.

  5. Realize a verificação de DLQ pós-drenagem: depois que o status do job mudar para Drained, inspecione os diretórios de DLQ grave e de repetição no Cloud Storage pela última vez. Verifique se nenhum novo arquivo de erro apareceu enquanto os dados em trânsito eram drenados. Se houver arquivos, resolva e reproduza-os. Para mais informações, consulte Monitorar e resolver erros de DLQ de CDC.

Realizar a transição do aplicativo

Mude as conexões do banco de dados do aplicativo para o Spanner e retome o tráfego de leitura e gravação ativos:

  1. Atualize a configuração do aplicativo ou as strings de conexão do banco de dados para segmentar o banco de dados do Spanner.
  2. Inicie os serviços de aplicativos e verifique se o tráfego de leitura e gravação ativos é executado com sucesso no Spanner.
  3. Monitore o pipeline de replicação inversa em busca de erros. Se uma gravação do Spanner não for replicada de volta para o MySQL, o Dataflow vai salvar o registro com falha em um diretório de DLQ no Cloud Storage (por exemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/). Verifique esse caminho regularmente para confirmar que ele permanece vazio. Se registros com falha aparecerem, consulte Monitorar e resolver erros de replicação inversa.

A seguir