Neste documento, descrevemos o processo de migração do seu banco de dados para o Spanner. Descrevemos as etapas de migração e as ferramentas que recomendamos para cada uma delas, dependendo do banco de dados de origem e de outros fatores. As ferramentas recomendadas incluem produtos do Google Cloud e ferramentas comerciais e de código aberto de terceiros. Juntas, essas ferramentas ajudam você a acelerar migrações e reduzir riscos.
Qualquer migração do Spanner envolve as seguintes etapas principais:
- Avalie a complexidade da migração.
- Migre o esquema.
- Migre seu aplicativo.
- Teste e ajuste seu desempenho.
- Migrar os dados.
- Valide a migração.
- Configurar mecanismos de transição e failover.
O diagrama a seguir mostra esse processo:
Nesses estágios, o plano de migração pode variar muito, dependendo de fatores como origem e tamanho do banco de dados, requisitos de inatividade, complexidade do código do aplicativo, esquema de fragmentação, funções ou transformações personalizadas e estratégia de failover e replicação.
Fornecemos guias de migração para Amazon DynamoDB, MySQL, Oracle Database e PostgreSQL. Se você estiver migrando de um desses bancos de dados, siga também o guia relevante:
- Migrar do MySQL
- Migrar do PostgreSQL para o Spanner (dialeto GoogleSQL)
- Migrar do PostgreSQL para o Spanner (dialeto do PostgreSQL)
- Migrar do Oracle Database
- Migrar do DynamoDB
Se você estiver migrando de outro banco de dados, talvez precise de personalizações e ferramentas adicionais que este guia não aborda.
Ferramentas de migração
Recomendamos o uso das ferramentas a seguir para ajudar nas várias etapas da migração, dependendo do banco de dados de origem e de outros fatores. Algumas ferramentas oferecem suporte apenas a determinados bancos de dados de origem. Para algumas etapas do processo, nenhuma ferramenta está disponível, então você conclui essas etapas manualmente.
- A ferramenta de migração Spanner é uma ferramenta de código aberto que realiza avaliações básicas, bem como migrações de esquema e dados.
- 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 a DVT a produtos existentes do Google Cloud.
- O Datastream é um serviço do Google Cloud que permite ler eventos de captura de dados alterados (CDC) e dados em massa de um banco de dados de origem.
- O Dataflow é um serviço do Google Cloud que ajuda você a gravar grandes quantidades de dados no Spanner com mais eficiência usando modelos. Esses modelos não geram um arquivo dump. O arquivo dump precisa ser gerado pelas ferramentas de banco de dados de origem ou de terceiros.
Na tabela a seguir, resumimos as principais ferramentas que recomendamos para cada estágio da migração para alguns bancos de dados de origem comuns. É possível migrar de outros bancos de dados com personalizações.
| Banco de dados de origem | Avaliar o escopo | Migrar seu esquema | Migrar seu app | Migrar seus dados | Validar a migração de dados | Configurar transição e failover |
|---|---|---|---|---|---|---|
| MySQL | Manual | Ferramenta de migração do Spanner | Manual | Ferramenta de migração do Spanner | DVT | Manual |
| PostgreSQL | Manual | Ferramenta de migração do Spanner | Manual | Ferramenta de migração do Spanner | DVT | Manual |
| Outros bancos de dados | Manual | Ferramenta de migração do Spanner | Manual | Manual | DVT | Manual |
Avaliar a complexidade da migração
Para avaliar o escopo e a complexidade da migração e planejar a abordagem, reúna dados sobre o banco de dados de origem, incluindo o seguinte:
- Padrões de consulta
- Quantidade de lógica do aplicativo que depende de recursos do banco de dados, como procedimentos e gatilhos armazenados.
- 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 alterar chaves, remover ou adicionar índices ou adicionar ou remover colunas de tabelas atuais. Para otimizar o esquema para o Spanner, consulte Práticas recomendadas de design de esquema e Estratégias recomendadas de migração de chave primária.
A ferramenta de migração do Spanner, uma ferramenta de código aberto mantida pela comunidade e criada por desenvolvedores do Google, cria automaticamente um esquema do Spanner a partir do 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 ingere esquemas e dados de um dos seguintes locais:
- Um arquivo dump 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 de esquema, recomendações e migrações:
- Recomendações e avaliação de compatibilidade do tipo de dados
- Recomendações e edição da chave primária
- Recomendações e edição de índice secundário
- Edição e recomendações de tabelas intercaladas
- Recomendações gerais de design de esquemas do Spanner
- Controle de versão do esquema
- Modificação colaborativa de esquemas
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 a migração de dados.
Migrar seu aplicativo
Uma migração de banco de dados requer diferentes drivers e bibliotecas, bem como compensação por recursos não compatíveis com o Spanner. Para alcançar uma funcionalidade semelhante e otimizar de acordo com os pontos fortes do Spanner, talvez seja necessário alterar o código, os fluxos de aplicativos e a arquitetura.
Veja algumas das alterações necessárias para migrar seu aplicativo para o Spanner:
- O Spanner não é compatível com a execução de código de 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 bibliotecas de cliente do Spanner e mapeadores objeto-relacional (ORMs). 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.
- Observe a DML particionada, as transações somente leitura, os carimbos de data/hora de confirmação e os carimbos de data/hora de leitura e como eles podem otimizar o desempenho do aplicativo.
Talvez também seja necessário fazer mudanças no processamento das transações. Não há ferramentas disponíveis para ajudar com isso, então é necessário 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 adicional 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 DML particionada.
- Para o nível de isolamento da transação, não é necessário processamento porque as transações do Spanner são mais isoladas.
- Como o Spanner é linearizável, ele lida com 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 uso de CPU e latência com base em um subconjunto de dados, ajusta seu esquema e aplicativo para melhorar o desempenho e testa novamente.
Por exemplo, no esquema, é possível adicionar ou alterar um índice ou alterar uma chave primária. No seu aplicativo, você pode fazer gravações em lote ou mesclar ou modificar as consultas.
Especificamente para o tráfego de produção, o ajuste de desempenho é importante para evitar surpresas. O ajuste de desempenho é mais eficaz quanto mais próxima a configuração estiver da capacidade de processamento do tráfego de produção em tempo real e dos tamanhos dos dados.
Para testar e ajustar o esquema e o desempenho do aplicativo, siga estas etapas:
- Fazer upload de um subconjunto dos seus dados em um banco de dados do Spanner. Para mais informações, consulte Migrar seus dados.
- Aponte o aplicativo para o Spanner.
- Verifique a exatidão analisando fluxos básicos.
- Verifique se o desempenho atende às suas expectativas realizando testes de carga
no aplicativo. Se precisar de ajuda para identificar e otimizar as consultas mais caras, consulte Detectar problemas de desempenho da consulta com o Query Insights.
Os fatores a seguir podem contribuir para um desempenho de consulta abaixo do
ideal:
- Consultas ineficientes: para saber 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 da transação, consulte Identificar transações que possam causar altas latências.
- Design de esquema ineficiente: se o esquema não for bem projetado, a otimização de consultas não será muito útil.
- Ponto de acesso: os pontos de acesso no Spanner limitam a capacidade de gravação, especialmente para aplicativos com QPS alto. Para identificar pontos de acesso 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 exatidã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, você move os dados para um banco de dados do Spanner de tamanho de produção vazio e, em seguida, muda para o banco de dados do Spanner.
Dependendo do banco de dados de origem, é possível migrá-lo com tempo de inatividade mínimo ou exigir um tempo de inatividade prolongado.
Para migrações de tempo de inatividade mínimo e migrações com tempo de inatividade prolongado, recomendamos o uso do Dataflow e da ferramenta de migração do Spanner.
A tabela a seguir mostra as diferenças entre migrações de tempo de inatividade e migrações com mais inatividade, incluindo origens, formatos, tamanho e capacidade compatíveis.
| Migração com inatividade mínima | Migração com inatividade | |
|---|---|---|
| Fontes 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 Conexão direta a um banco de dados MySQL. | MySQL, PostgreSQL, CSV e 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 de inatividade mínimo
O Spanner dá suporte a migrações de inatividade mínima do MySQL, do PostgreSQL e do Oracle Database. Uma migração de inatividade mínima 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 o snapshot, chamado de captura de dados alterados (CDC, na sigla em inglês).
Embora as migrações de tempo mínimo de inatividade ajudem a proteger seus dados, o processo envolve desafios, incluindo o seguinte:
- Armazenar dados de CDC enquanto o snapshot é migrado.
- Gravar os dados do CDC no Spanner durante a captura do stream do CDC de entrada.
- Garantir que a migração dos dados do CDC para o Spanner seja mais rápida do que o fluxo de CDC de entrada.
Para gerenciar uma migração de inatividade mínima, a ferramenta de migração do Spanner orquestra os seguintes processos para você:
- Configura um bucket do Cloud Storage para armazenar eventos de CDC no banco de dados de origem enquanto a migração do snapshot avança.
- Configura um job do Datastream que move a carga em massa de dados de CDC e faz o streaming contínuo de 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 espera que a migração dos dados seja concluída. Isso resulta em um curto período de inatividade enquanto o Spanner busca 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 inatividade
Para bancos de dados que não sejam MySQL, PostgreSQL ou Oracle Database, se o banco de dados puder exportar para CSV ou Avro, será possível migrar para o Spanner com 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 tempo de inatividade pode resultar em perda de dados.
Para realizar uma migração de inatividade, siga estas etapas gerais:
- Gere um arquivo dump dos dados do banco de dados de origem.
- Faça upload do arquivo dump para o Cloud Storage em um formato de despejo MySQL, PostgreSQL, Avro ou CSV.
- Carregue o arquivo dump no Spanner usando o Dataflow ou a ferramenta de migração do Spanner.
A geração de vários arquivos dump pequenos facilita a gravação no Spanner, já que ele pode ler vários arquivos de despejo em paralelo.
Ao gerar um arquivo dump do banco de dados de origem, para gerar um snapshot consistente dos dados, lembre-se do seguinte:
- Para evitar que os dados sejam alterados durante a geração do arquivo dump, antes de executar o despejo, aplique um bloqueio de leitura no banco de dados de origem.
- Gere o arquivo dump 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 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 o Spanner para arquivos Avro.
- Para importar dados 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 compatível com a origem. Se os dados tiverem novas linhas, use um separador de linha personalizado.
- Para importar dados CSV, use um job de importação do Dataflow. É possível criar seu próprio modelo de importação do Dataflow ou usar um modelo de importação do Google Cloud. Para mais informações, consulte Modelos de pipeline de dados do Dataflow.
Se você estiver usando o MySQL ou o PostgreSQL, poderá utilizar a ferramenta de migração do Spanner.
Para informações sobre como usar scripts personalizados para carregar dados no Spanner, consulte Diretrizes de desempenho para carregamento em massa.
Validar sua migração de dados
A validação de dados é o processo de comparar os dados das tabelas de origem e de destino para garantir que sejam correspondentes.
A Ferramenta de validação de dados (DVT, na sigla em inglês) é uma ferramenta de código aberto que pode se conectar a armazenamentos de dados e realizar verificações entre a fonte e o Spanner. Recomendamos o uso dele para executar 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 .
- Corresponda o número de linhas em cada tabela.
- Extraia linhas aleatórias para verificar a exatidão.
- Valide as colunas (
count,sum,avg,min,max,group by). - Compare todas as verificações cíclicas de redundância ou funções hash no nível da linha.
Para realizar validações mais específicas, crie verificações personalizadas durante a migração.
Configurar mecanismos de transição e failover
As migrações costumam ser demoradas e complexas. Crie substitutos para evitar um impacto significativo em caso de erro durante a migração, permitindo voltar ao banco de dados de origem com um tempo de inatividade mínimo.
A recomendação atual é consumir fluxos de alterações para executar a replicação reversa e gravar de volta no banco de dados de origem por um stream como Pub/Sub ou Cloud Storage.
A replicação reversa precisa fazer o seguinte:
- Processar mudanças em tipos de dados ou conteúdo.
- Reverta todas as transformações realizadas durante a migração.
- Envie os dados para o destino apropriado, considerando os esquemas de fragmentação na origem.