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:
- Avalie a complexidade da migração.
- Migrar o esquema.
- Carregar dados de amostra.
- Migrar o aplicativo.
- Teste e ajuste sua performance.
- Migrar os dados.
- Valide a migração.
- 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.
A ferramenta de migração do Spanner (SMT, na sigla em inglês) é uma ferramenta de código aberto que pode realizar avaliações básicas, conversão de esquemas e migrações de dados.
A avaliação de migração de banco de dados (DMA, na sigla em inglês) oferece uma avaliação básica para migrar o PostgreSQL para o Spanner.
O Datastream é um serviço Google Cloud que permite ler eventos de captura de dados de alteração (CDC) e dados em massa de um banco de dados de origem e gravar em um destino especificado.
O Dataflow é um Google Cloud serviço que ajuda você a gravar uma grande quantidade de dados no Spanner de maneira mais eficiente usando modelos.
A migração de dados em massa é um modelo do Dataflow que permite migrar grandes conjuntos de dados do MySQL diretamente para o Spanner.
A migração com tempo mínimo de inatividade usa o Datastream e o Dataflow para migrar:
- Dados existentes no seu banco de dados de origem.
- Fluxo de mudanças feitas no banco de dados de origem durante a migração.
A Ferramenta de validação de dados (DVT, na sigla em inglês) é um método de validação de dados padronizado criado pelo Google e aceito pela comunidade de código aberto. É possível integrar o DVT a produtos Google Cloud existentes.
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:
- O Spanner não oferece suporte à execução de código do usuário no nível do banco de dados. Portanto, é necessário mover todos os procedimentos e gatilhos armazenados no nível do banco de dados para o aplicativo.
- Use as bibliotecas de cliente do Spanner e os mapeadores relacionais de objetos (ORMs, na sigla em inglês). Para mais informações, consulte Visão geral de APIs, bibliotecas de cliente e drivers ORM.
- Se você precisar traduzir consultas, faça isso manualmente ou use outras ferramentas de terceiros.
- Confira a DML particionada, transações somente leitura, carimbos de data/hora de confirmação e leia sobre eles e como eles podem otimizar o desempenho do aplicativo.
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:
- Faça upload de um subconjunto dos seus dados para um banco de dados do Spanner. Para mais informações, consulte Migrar seus dados.
- Aponte o aplicativo para o Spanner.
- Verifique a correção procurando fluxos básicos.
- 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:
- Consultas ineficientes: para informações sobre como escrever consultas eficientes, consulte Práticas recomendadas de SQL.
- Alta utilização da CPU: para mais informações, consulte Investigar a alta utilização da CPU.
- Bloqueio: para reduzir os gargalos causados pelo bloqueio de transações, consulte Identificar transações que podem causar altas latências.
- Design ineficiente do esquema: se o esquema não for bem projetado, a otimização de consulta não será muito útil.
- 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.
- 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:
- Configura um bucket do Cloud Storage para armazenar eventos de CDC no banco de dados de origem enquanto a migração de snapshots progride.
- 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.
- 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:
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:
- Gere um arquivo de despejo dos dados do banco de dados de origem.
- Faça o upload do arquivo de dump para o Cloud Storage em um formato de dump MySQL, PostgreSQL, Avro ou CSV.
- 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.
Formatos recomendados para migração em massa
O Avro é o formato preferido para uma migração em massa para o Spanner. Se você estiver usando o Avro, considere o seguinte:
- Para gerar um despejo do Avro dos dados, use uma ferramenta como o DBeam. Para mais informações sobre como exportar para o Avro, consulte Exportar dados de um banco de dados que não seja do Spanner para arquivos Avro.
- Para importar dados do Avro, use um job de importação do Dataflow. Para mais informações, consulte Importar arquivos Avro de bancos de dados que não são do Spanner para o Spanner.
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.
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.