Visão geral da migração

Este documento descreve o processo de migração do seu banco de dados para o Spanner. Descrevemos as fases da migração e as ferramentas recomendadas para cada uma delas, dependendo do banco de dados de origem e de outros fatores. As ferramentas recomendadas incluem produtos Google Cloud , bem como ferramentas comerciais e de código aberto de terceiros. Juntas, essas ferramentas ajudam a acelerar as migrações e reduzir os riscos.

Qualquer migração do Spanner envolve as seguintes etapas principais:

  1. Avalie a complexidade da migração.
  2. Migrar o esquema.
  3. Carregar dados de amostra.
  4. Migrar o aplicativo.
  5. Teste e ajuste sua performance.
  6. Migrar os dados.
  7. Valide a migração.
  8. Configure mecanismos de failover e de transição.

Nesses estágios, o plano de migração pode variar muito, dependendo de fatores como a origem e o tamanho do banco de dados, os requisitos de inatividade, a complexidade do código do aplicativo, o esquema de fragmentação, as funções ou transformações personalizadas, a estratégia de failover e de replicação.

Ferramentas de migração

Recomendamos o uso das ferramentas a seguir para ajudar você em vários estágios da migração, dependendo do banco de dados de origem e de outros fatores. Algumas ferramentas só oferecem suporte a determinados bancos de dados de origem. Para algumas etapas do processo, nenhuma ferramenta está disponível, então você precisa concluir essas etapas manualmente.

Ferramentas de migração para bancos de dados de origem do MySQL

Se o banco de dados de origem for MySQL, será possível realizar algumas das etapas iniciais da migração usando arquivos de dump do MySQL. É necessário se conectar diretamente ao banco de dados MySQL de origem em execução para concluir uma migração de produção.

A tabela a seguir recomenda ferramentas de migração com base na fase de migração e se você está trabalhando com um arquivo de despejo ou conectando diretamente o banco de dados de origem:

Etapa da migração Arquivo de despeje Conexão direta ao banco de dados de origem
Avaliação Use SMT com mysqldump. Use SMT com mysqldump.
Conversão de esquema Use SMT com mysqldump. Use a SMT para configurar e converter o esquema.
Exemplo de carregamento de dados Faça uma migração em massa.
Migração de dados Não relevante Faça uma migração em massa e depois uma migração com tempo mínimo de inatividade.
Validação de dados Não relevante Use DVT.
Configuração de failover Não relevante Use o SMT para a replicação reversa.

Ferramentas de migração para bancos de dados de origem do PostgreSQL

Se o banco de dados de origem usar o PostgreSQL, será possível realizar alguns estágios de migração usando um arquivo de despejo do PostgreSQL. É necessário se conectar diretamente ao banco de dados PostgreSQL de origem em execução para concluir a migração.

A tabela a seguir recomenda ferramentas de migração com base na fase de migração e se você está trabalhando com um arquivo de despejo ou se está se conectando diretamente do banco de dados de origem:

Etapa da migração Arquivo de despeje Conexão direta ao banco de dados de origem
Avaliação Use SMT com pg_dump. Use DMA.
Conversão de esquema Use SMT com pg_dump. Use a SMT para configurar e converter o esquema.
Exemplo de carregamento de dados Faça uma migração com tempo mínimo de inatividade.
Migração de dados Não relevante Realize uma migração com tempo mínimo de inatividade.
Validação de dados Não relevante Use DVT.
Failover Não relevante Não relevante

Avaliar a complexidade da migração

Para avaliar o escopo e a complexidade da migração e planejar sua abordagem, é necessário coletar dados sobre o banco de dados de origem, incluindo:

  • Padrões de consulta
  • Quantidade de lógica de aplicativo que depende de recursos do banco de dados, como procedimentos armazenados e gatilhos
  • Requisitos de hardware
  • Custo total de propriedade (TCO)

Migrar o esquema

Antes de migrar um esquema para um esquema do Spanner, avalie a compatibilidade entre os esquemas e otimize seu esquema para o Spanner. Por exemplo, talvez você queira mudar chaves, excluir ou adicionar índices ou adicionar ou remover colunas de tabelas existentes. Para otimizar seu esquema para o Spanner, consulte Práticas recomendadas de design de esquemas e Estratégias de migração de chave primária recomendadas.

A ferramenta de migração do Spanner, uma ferramenta de código aberto e mantida pela comunidade criada por desenvolvedores do Google, cria automaticamente um esquema do Spanner com base no esquema do banco de dados de origem. É possível personalizar o esquema usando o assistente de esquema da ferramenta de migração do Spanner.

A ferramenta de migração do Spanner captura esquemas e dados de um dos seguintes locais:

  • Um arquivo de despejo de um local local ou do Cloud Storage (MySQL, PostgreSQL, CSV)
  • Diretamente do banco de dados de origem (MySQL, PostgreSQL)

A ferramenta de migração do Spanner executa as seguintes funções para avaliações, recomendações e migrações de esquemas:

  • Avaliação e recomendações de compatibilidade de tipos de dados
  • Edição e recomendações de chave primária
  • Edição e recomendações de índices secundários
  • Como intercalar a edição de tabelas e as recomendações
  • Recomendações gerais de design de esquemas do Spanner
  • Controle de versões do esquema
  • Modificação colaborativa do esquema

Para mais informações sobre migrações de esquema com a ferramenta de migração do Spanner, consulte o arquivo README.md da ferramenta de migração do Spanner.

Você também usa a ferramenta de migração do Spanner para migrar dados.

Carregar dados de amostra

Depois de criar um esquema compatível com o Spanner, você pode preparar seu banco de dados para testes usando dados de amostra. É possível usar o fluxo de trabalho de ETL reverso do BigQuery para carregar os dados de amostra. Para mais informações, consulte Carregar dados de amostra.

Migrar seu aplicativo

Uma migração de banco de dados requer diferentes drivers e bibliotecas, além de compensação por recursos que o Spanner não oferece suporte. Para otimizar as vantagens do Spanner, talvez seja necessário mudar o código, os fluxos de aplicativos e a arquitetura.

Confira algumas das mudanças necessárias para migrar seu aplicativo para o Spanner:

Talvez também seja necessário fazer mudanças no processamento de transações. Não há ferramentas disponíveis para ajudar nisso. Portanto, você precisa concluir esta etapa manualmente. Lembre-se do seguinte:

  • O limite de mutações por confirmação é de 40.000. Cada índice secundário em uma tabela é uma mutação extra por linha. Para modificar dados usando mutações, consulte Inserir, atualizar e excluir dados usando mutações. Para modificar uma grande quantidade de dados, use a DML particionada.
  • Para o nível de isolamento da transação, nenhum processamento é necessário, porque as transações do Spanner são mais isoladas.
  • Como o Spanner é linearizável, ele processa a consistência e o bloqueio por padrão.

Testar e ajustar o esquema e o desempenho do aplicativo

O ajuste de desempenho é um processo iterativo em que você avalia métricas como utilização da CPU e latência com base em um subconjunto de dados, ajusta o esquema e o aplicativo para melhorar o desempenho e testa novamente.

Por exemplo, no esquema, você pode adicionar ou alterar um índice ou uma chave primária. No seu aplicativo, você pode gravar em lote ou mesclar ou modificar as consultas.

No caso do tráfego de produção, o ajuste de desempenho é importante para evitar surpresas. O ajuste de desempenho é mais eficaz quanto mais próximo a configuração está do tráfego de produção em tempo real e dos tamanhos de dados.

Para testar e ajustar o esquema e o desempenho do aplicativo, siga estas etapas:

  1. Faça upload de um subconjunto dos seus dados para um banco de dados do Spanner. Para mais informações, consulte Migrar seus dados.
  2. Aponte o aplicativo para o Spanner.
  3. Verifique a correção procurando fluxos básicos.
  4. Verifique se o desempenho atende às suas expectativas realizando testes de carga no aplicativo. Para receber ajuda na identificação e otimização das consultas mais custosas, consulte Detectar problemas de desempenho da consulta com insights de consulta. Em particular, os seguintes fatores podem contribuir para a performance de consulta subótima:
    1. Consultas ineficientes: para informações sobre como escrever consultas eficientes, consulte Práticas recomendadas de SQL.
    2. Alta utilização da CPU: para mais informações, consulte Investigar a alta utilização da CPU.
    3. Bloqueio: para reduzir os gargalos causados pelo bloqueio de transações, consulte Identificar transações que podem causar altas latências.
    4. Design ineficiente do esquema: se o esquema não for bem projetado, a otimização de consulta não será muito útil.
    5. Pontos de acesso: os pontos de acesso no Spanner limitam a taxa de transferência de gravação, especialmente para aplicativos de QPS alto. Para identificar pontos críticos ou antipadrões, verifique as estatísticas do Key Visualizer no console do Google Cloud. Para mais informações sobre como evitar pontos de acesso, consulte Escolher uma chave primária para evitar pontos de acesso.
  5. Se você modificar o esquema ou os índices, repita os testes de correção e desempenho até conseguir resultados satisfatórios.

Para mais informações sobre como ajustar o desempenho do banco de dados, entre em contato com o suporte do Spanner.

Migrar seus dados

Depois de otimizar o esquema do Spanner e migrar o aplicativo, mova os dados para um banco de dados do Spanner vazio de tamanho de produção e mude para o banco de dados do Spanner.

Dependendo do banco de dados de origem, talvez seja possível migrar o banco de dados com um tempo de inatividade mínimo ou talvez seja necessário um tempo de inatividade prolongado.

Para migrações com tempo de inatividade mínimo e migrações com tempo de inatividade prolongado, recomendamos usar o Dataflow e a ferramenta de migração do Spanner.

A tabela a seguir mostra as diferenças entre migrações com tempo mínimo de inatividade e migrações com mais tempo de inatividade, incluindo origens, formatos, tamanho e taxa de transferência compatíveis.

Migração com tempo mínimo de inatividade Migração com inatividade
Origens compatíveis MySQL, PostgreSQL Qualquer banco de dados que possa ser exportado para CSV ou Avro.
Formatos de dados compatíveis Conecte-se diretamente. Consulte Como se conectar diretamente a um banco de dados MySQL. MySQL, PostgreSQL, CSV, Avro
Tamanhos de banco de dados compatíveis Sem limite Sem limite
Capacidade máxima 45 GB por hora 200 GB por hora

Migração com tempo mínimo de inatividade

O Spanner oferece suporte a migrações com tempo de inatividade mínimo do MySQL, PostgreSQL e Oracle Database. Uma migração com tempo de inatividade mínimo consiste em dois componentes:

  • Um snapshot consistente de todos os dados no banco de dados
  • O fluxo de alterações (inserções e atualizações) desde esse snapshot, chamado de captura de dados alterados (CDC).

Embora as migrações com tempo de inatividade mínimo ajudem a proteger seus dados, o processo envolve desafios, incluindo os seguintes:

  • Armazenar dados de CDC enquanto o snapshot é migrado.
  • Gravação dos dados do CDC no Spanner enquanto captura o fluxo de CDC de entrada.
  • Garantir que a migração de dados do CDC para o Spanner seja mais rápida do que o fluxo de CDC recebido.

Para gerenciar uma migração com tempo mínimo de inatividade, a ferramenta de migração do Spanner orquestra os seguintes processos:

  1. Configura um bucket do Cloud Storage para armazenar eventos de CDC no banco de dados de origem enquanto a migração de snapshots progride.
  2. Configura um job do Datastream que move a carga em massa de dados de CDC e transmite continuamente dados incrementais de CDC para o bucket do Cloud Storage. Configure o perfil de conexão de origem na ferramenta de migração do Spanner.
  3. Configura o job do Dataflow para migrar os eventos de CDC para o Spanner.

Quando o Dataflow copia a maioria dos dados, ele para de gravar no banco de dados de origem e aguarda a conclusão da migração. Isso resulta em um tempo de inatividade curto enquanto o Spanner alcança o banco de dados de origem. Depois, o aplicativo pode ser transferido para o Spanner.

O diagrama a seguir mostra esse processo:

O diagrama mostra o processo de uma migração com tempo de inatividade mínimo.

Migração com tempo de inatividade

Para bancos de dados que não são MySQL, PostgreSQL ou Oracle Database, se o banco de dados poder exportar para CSV ou Avro, é possível migrar para o Spanner com tempo de inatividade. Recomendamos o uso do Dataflow ou da ferramenta de migração do Spanner.

As migrações com inatividade são recomendadas apenas para ambientes de teste ou aplicativos que podem lidar com algumas horas de inatividade. Em um banco de dados ativo, uma migração com inatividade pode resultar na perda de dados.

Para realizar uma migração com inatividade, siga estas etapas gerais:

  1. Gere um arquivo de despejo dos dados do banco de dados de origem.
  2. Faça o upload do arquivo de dump para o Cloud Storage em um formato de dump MySQL, PostgreSQL, Avro ou CSV.
  3. Carregue o arquivo de despejo no Spanner usando o Dataflow ou a ferramenta de migração do Spanner.

A geração de vários arquivos de despejo pequenos torna a gravação no Spanner mais rápida, já que ele pode ler vários arquivos de despejo em paralelo.

Ao gerar um arquivo de despejo do banco de dados de origem, para gerar um instantâneo consistente dos dados, considere o seguinte:

  • Para evitar que os dados mudem durante a geração do arquivo de despejo, aplique um bloqueio de leitura no banco de dados de origem antes de realizar o despejo.
  • Gere o arquivo de despejo usando uma réplica de leitura do banco de dados de origem com a replicação desativada.

O Avro é o formato preferido para uma migração em massa para o Spanner. Se você estiver usando o Avro, considere o seguinte:

Se você estiver usando CSV, considere o seguinte:

  • Para gerar um despejo CSV dos dados, use a geração de CSV aceita pela fonte. Se os dados contiverem novas linhas, use um separador de linhas personalizado.
  • Para importar dados CSV, use um job de importação do Dataflow. Você pode criar seu próprio modelo de importação do Dataflow ou usar um Google Cloud modelo de importação. Para mais informações, consulte Modelos de pipeline de dados do Dataflow.

Se você estiver usando o MySQL ou o PostgreSQL, use a ferramenta de migração do Spanner.

Para saber como usar scripts personalizados para carregar dados no Spanner, consulte Diretrizes de desempenho para carregamento em massa.

Validar a migração de dados

A validação de dados é o processo de comparação dos dados das tabelas de origem e de destino para garantir que eles correspondam.

A Ferramenta de validação de dados (DVT, na sigla em inglês) é uma ferramenta de código aberto que pode se conectar a repositórios de dados e realizar verificações entre a origem e o Spanner. Recomendamos o uso dele para realizar validações básicas como parte da migração, como as seguintes:

  • Verifique se todas as tabelas foram criadas e se todos os mapeamentos de esquema estão corretos .
  • Corresponder ao número de linhas de cada tabela.
  • Extraia linhas aleatórias para verificar a correção.
  • Valide as colunas (count, sum, avg, min, max, group by).
  • Compare todas as verificações de redundância cíclica ou funções de hash no nível da linha.

Para realizar validações mais específicas, crie verificações personalizadas durante a migração.

Configurar mecanismos de failover e de transição

As migrações costumam ser demoradas e complexas. Crie substitutos para evitar impactos significativos em caso de erro durante a migração, permitindo que você volte ao banco de dados de origem com o mínimo de tempo de inatividade.

A recomendação atual é consumir fluxos de alterações para realizar a replicação reversa e gravar novamente no banco de dados de origem usando um fluxo como Pub/Sub ou Cloud Storage.

Diagrama mostra o processo de transição.

A replicação reversa precisa fazer o seguinte:

  • Processar mudanças nos tipos de dados ou no conteúdo.
  • reverter todas as transformações realizadas durante a migração.
  • Envie os dados para o destino apropriado, considerando os esquemas de fragmentação na origem.

A seguir