Fazer fallback para o MySQL

Este guia descreve como realizar o fallback e a reversão da recuperação de desastres do Spanner para as instâncias de origem do MySQL.

Se você encontrar uma degradação inesperada de desempenho, erros de aplicativo irrecuperáveis ou bloqueadores funcionais críticos após a migração para o Spanner, use os procedimentos nas seções a seguir para reverter para as instâncias principais do MySQL:

Antes de começar

Antes de iniciar os procedimentos de fallback, verifique os seguintes pré-requisitos:

  1. Replicação reversa ativa: verifique se o pipeline do Dataflow de replicação reversa (Spanner_to_SourceDb) está em execução e consumindo ativamente os fluxo de alterações do Spanner no modo de filtragem forward_migration. Para mais informações, consulte Configurar o fallback para o MySQL.
  2. Disponibilidade do MySQL de origem: verifique se o banco de dados MySQL de origem está on-line, acessível pelo Dataflow e capaz de aceitar conexões de gravação.
  3. Janela de manutenção: alerte as partes interessadas de que uma janela de inatividade planejada é necessária enquanto as gravações do Spanner estão pausadas e a replicação reversa é esgotada.

Funções exigidas

Pausar gravações do Spanner

  1. Pause todo o tráfego de gravação do banco de dados para o Spanner no aplicativo.
  2. Permita que as transações ativas no Spanner sejam totalmente confirmadas e esgotadas.

Permitir que a replicação reversa seja esgotada

As seções a seguir descrevem como verificar se todas as alterações gravadas no Spanner após a migração são replicadas de volta para o MySQL antes de mudar as gravações do aplicativo.

Monitorar atraso de replicação

Acompanhe o atraso de replicação para verificar se todas as alterações em andamento são gravadas no MySQL:

  1. No Google Cloud console, acesse a página Detalhes do job do job do Dataflow de replicação reversa.
  2. Na guia Métricas personalizadas, inspecione o contador de usuários replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX. Para mais informações, consulte Configurar o fallback para o MySQL.
  3. Aguarde até que o valor do contador chegue a 0.

Como alternativa, no Metrics Explorer, consulte o contador de usuários usando a linguagem de consulta do Monitoring (MQL): 

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
Substitua: * JOB_ID: o ID do job do Dataflow de replicação reversa. * LOGICAL_SHARD_NAME: o nome do fragmento lógico configurado para o banco de dados de origem.

Verificar a atividade de gravação do MySQL

Verifique se as operações de gravação de replicação reversa foram concluídas no banco de dados de origem:

  1. No banco de dados principal do MySQL de origem, inspecione as consultas ativas e as métricas de conexão do banco de dados.
  2. Verifique se o tráfego de gravação do pipeline de replicação reversa foi interrompido.

Verificar o estado limpo da DLQ

Inspecione as filas de mensagens não entregues (DLQ) para verificar se não ocorreram erros não tratados durante a replicação reversa:

  1. No Google Cloud console, acesse a página Detalhes do job do job do Dataflow de replicação reversa. Na guia Métricas personalizadas , inspecione o contador de usuários severe_error_count.

  2. Inspecione os diretórios de DLQ de replicação reversa grave e de repetição no Cloud Storage (por exemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ e gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/).

    É possível listar o conteúdo do diretório de DLQ grave usando a CLI gcloud:

    gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/

    Substitua:

    • MIGRATION_BUCKET: o nome do bucket do Cloud Storage.
    • ENV: o nome do ambiente de implantação (por exemplo, prod).
    • SERVICE: o nome do aplicativo ou serviço.
    • DB_SCHEMA: o nome do esquema do banco de dados.

  3. Verifique se os diretórios de DLQ permanecem completamente vazios.

  4. Se houver arquivos de erro, resolva os problemas subjacentes e reproduza os registros com falha antes de continuar. Para mais informações, consulte Monitorar e resolver erros de replicação reversa.

Retomar o streaming de CDC direto

Se você planeja retomar a migração direta para o Spanner no futuro, retome o stream direto do Datastream:

  1. No Google Cloud console, acesse a página Detalhes do stream para seu stream.
  2. Clique em Retomar e aguarde até que o status do stream mude para RUNNING. Para mais informações, consulte Migrar dados do MySQL.

Como alternativa, para retomar o stream usando a CLI gcloud, execute o comando gcloud datastream streams resume:

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

Substitua:

  • STREAM_ID: o ID do stream do Datastream.
  • LOCATION: a Google Cloud região em que o seu stream está localizado.

Redirecionar gravações para o MySQL

  1. Atualize a configuração do aplicativo e as strings de conexão do banco de dados para direcionar as instâncias principais do banco de dados MySQL de origem.
  2. Inicie os serviços de aplicativos e retome o tráfego de leitura e gravação em tempo real no MySQL.
  3. Verifique se as operações de leitura e gravação do aplicativo são executadas com sucesso no banco de dados MySQL.

A seguir