Este documento descreve o processo de migração do seu banco de dados para no Spanner. Descrevemos os estágios da migração e as ferramentas que para cada estágio, dependendo do banco de dados de origem e de outros fatores. As ferramentas recomendadas incluem produtos do Google Cloud e serviços ferramentas comerciais e de código aberto. Juntas, essas ferramentas ajudam você a acelerar as migrações e reduzir os riscos.
Qualquer migração do Spanner envolve os seguintes estágios principais:
- Avalie a complexidade da migração.
- Migre seu 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:
Nessas fases, o plano de migração pode variar muito, dependendo dos fatores. como origem e tamanho do banco de dados, requisitos de inatividade, código do aplicativo a complexidade, o esquema de fragmentação, as transformações ou funções personalizadas e replicação de produtos.
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 as guia relevante:
- Migrar do MySQL
- Migrar do PostgreSQL para o Spanner (dialeto GoogleSQL)
- Migrar do PostgreSQL para o Spanner (dialeto PostgreSQL)
- Migrar do Oracle Database
- Migrar do DynamoDB
Se você estiver migrando de outro banco de dados, pode ser necessário personalizações e ferramentas que não são abordadas neste guia.
Ferramentas de migração
Recomendamos usar as ferramentas a seguir para ajudar nas várias etapas da sua a migração, dependendo do banco de dados de origem e de outros fatores. Apenas algumas ferramentas dão suporte a determinados bancos de dados de origem. Em algumas etapas do processo, nenhuma ferramenta é portanto, você conclui essas etapas manualmente.
- Ferramenta de migração do Spanner é uma ferramenta de código aberto que realiza avaliações básicas, bem como migrações de dados.
- Ferramenta de validação de dados (DVT) é um método de validação de dados padronizado criado pelo Google e aceito pela comunidade de código aberto. É possível integrar os DVTs produtos 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 no banco de dados de origem.
- O Dataflow é um serviço do Google Cloud ajuda a gravar grandes quantidades de dados no Spanner de forma eficiente usando modelos. Esses modelos não geram um arquivo dump. o arquivo dump precisar ser gerado pelas ferramentas do banco de dados de origem ou ferramentas de terceiros.
A tabela a seguir resume as principais ferramentas que recomendamos para cada de alguns bancos de dados de origem comuns. É possível migrar e 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 a transição e o 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 sua abordagem, precisa coletar 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 gatilhos e procedimentos armazenados
- Requisitos de hardware
- Custo total de propriedade (TCO)
Migrar o esquema
Antes de migrar um esquema para um do Spanner, avalie a compatibilidade entre os esquemas e otimize para no Spanner. Por exemplo, talvez você queira mudar as chaves, soltar ou adicionar índices, adicionar ou remover colunas de tabelas existentes. Para otimizar seu esquema para o Spanner, consulte Práticas recomendadas de criação de esquema e Recomendado estratégias de migração de chaves primárias.
A ferramenta de migração Spanner, uma de código aberto, mantida pela comunidade e criada por desenvolvedores do Google, cria automaticamente um esquema do Spanner com base no banco de dados de origem esquema. É 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
- Edições e recomendações da chave primária
- Recomendações e edição do índice secundário
- Recomendações e edição de tabelas intercaladas
- Recomendações gerais de design de esquemas do Spanner
- Controle de versão do esquema
- Modificação de esquema colaborativo
Para mais informações sobre migrações de esquema com a ferramenta de migração do Spanner, consulte
Arquivo README.md da ferramenta de migração do Spanner.
A ferramenta de migração do Spanner também é usada para a migração de dados.
Migrar seu aplicativo
Uma migração de banco de dados requer drivers e bibliotecas diferentes, bem como ou remuneração por recursos incompatíveis com o Spanner. Para alcançar uma funcionalidade semelhante e otimizar os pontos fortes do Spanner, talvez seja necessário alterar o código, os fluxos de aplicativos e a arquitetura.
Estas são algumas das mudanças necessárias para migrar seu aplicativo para Spanner:
- O Spanner não dá suporte à execução de código do usuário no nível do banco de dados. Portanto, é preciso mover todos os procedimentos e gatilhos armazenados no nível do banco de dados no aplicativo.
- Use as bibliotecas de cliente e os mapeadores objeto-relacional do Spanner (ORMs). Para mais informações, consulte Visão geral de APIs, bibliotecas de cliente e drivers ORM.
- Se você precisar traduzir consultas, traduza-as manualmente ou use outro ferramentas de terceiros.
- Anote a DML particionada, transações somente leitura, carimbos de data/hora de commit e ler carimbos de data/hora e e como otimizar o desempenho dos aplicativos.
Talvez também seja necessário fazer alterações no processamento de transações. Não há ferramentas para ajudar nisso. É preciso concluir essa etapa manualmente. Manter considere o 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, nenhum tratamento é necessário porque As transações do Spanner são mais isoladas.
- Como o Spanner é linearizável, ele lida com consistência com bloqueio padrão.
Teste e ajuste o esquema e o desempenho do aplicativo
O ajuste de desempenho é um processo iterativo em que você avalia métricas como Utilização e latência da CPU com base em um subconjunto dos seus dados. Ajuste seu esquema e o aplicativo para melhorar o desempenho e faça novos testes.
Por exemplo, em seu esquema, é possível adicionar ou alterar um índice ou alterar um chave primária. No seu aplicativo, é possível gravar em lote, mesclar ou modificar suas consultas.
No tráfego de produção em particular, o ajuste de desempenho é importante para ajudar evitar surpresas. Quanto mais próximo a configuração estiver do que o esperado, mais eficaz será o ajuste de desempenho com capacidade de processamento de tráfego e tamanhos de dados em tempo real.
Para testar e ajustar o esquema e o desempenho do aplicativo, siga estas etapas:
- Fazer upload de um subconjunto de dados em um banco de dados do Spanner. Para Saiba mais em Migrar seus dados.
- Apontar o aplicativo para o Spanner.
- Verifique a exatidão conferindo os fluxos básicos.
- Verifique se o desempenho atende às suas expectativas realizando testes de carga
no seu aplicativo. Para ajudar a identificar e otimizar seus
consultas caras, consulte
Detectar problemas de desempenho da consulta com o Query Insights.
Os fatores a seguir podem contribuir para consultas abaixo do ideal
desempenho:
- Consultas ineficientes: para obter informações sobre como escrever consultas eficientes, consulte Práticas recomendadas do SQL.
- Alta utilização da CPU: para mais informações, consulte Investigue a alta utilização da CPU.
- Bloqueio: para reduzir os gargalos causados pelo bloqueio de transações, ver Identifique transações que podem causar altas latências.
- Design de esquema ineficiente: se o esquema não for bem projetado, consultar a otimização não é muito útil.
- Hotspotting: os pontos de acesso no Spanner limitam a capacidade de gravação. especialmente para aplicativos com alto volume de QPS. Para identificar pontos de acesso ou antipadrões, marque a caixa Chave Visualizer estatísticas no console do Google Cloud. Para mais informações sobre evitando pontos de acesso, veja Escolha uma chave primária para evitar pontos de acesso.
- Se você modificar o esquema ou os índices, repita a correção e o desempenho até obter resultados satisfatórios.
Para mais informações sobre como ajustar o desempenho do seu banco de dados, entre em contato com Suporte ao Spanner (em inglês).
Migrar seus dados
Depois de otimizar seu esquema do Spanner e migrar você pode mover os dados para um espaço de produção vazio no banco de dados do Spanner e, em seguida, no banco de dados do Spanner.
Dependendo do banco de dados de origem, é possível migrá-lo. com tempo de inatividade mínimo ou um tempo de inatividade prolongado.
Tanto em migrações com tempo de inatividade mínimo quanto em migrações com tempo de inatividade prolongado, recomendamos usar o Dataflow e a ferramenta de migração do Spanner (em inglês).
A tabela a seguir mostra as diferenças entre migrações com tempo de inatividade mínimo e migrações com mais tempo de inatividade, incluindo origens, formatos, tamanho, e capacidade de processamento.
| Migração com tempo mínimo de inatividade | Migração com inatividade | |
|---|---|---|
| Fontes compatíveis | MySQL, PostgreSQL | Qualquer banco de dados que possa exportar para CSV ou Avro |
| Formatos de dados compatíveis | Conecte-se diretamente. Consulte Diretamente conectar-se 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, PostgreSQL e Oracle Database. Uma migração com inatividade mínima consiste em duas componentes:
- Um snapshot consistente de todos os dados do banco de dados
- O fluxo de alterações (inserções e atualizações) desde o snapshot chamada de captura de dados alterados (CDC)
As migrações com inatividade mínima ajudam a proteger seus dados, mas o processo envolve desafios, incluindo os seguintes:
- Armazenamento de dados da CDC enquanto o snapshot é migrado.
- gravar os dados de CDC no Spanner enquanto captura os fluxo de CDC.
- Garantir que a migração de dados de CDC para o Spanner seja mais rápida do que o fluxo de CDC de entrada.
Para gerenciar uma migração com tempo de inatividade mínimo, a ferramenta de migração do Spanner orquestra o seguinte: 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 o volume de dados de CDC e transmite continuamente dados de CDC incrementais para o do bucket do Cloud Storage. Você configurou o perfil de conexão de origem na ferramenta de migração do Spanner.
- Configura o job do Dataflow para migrar o CDC no Spanner.
Quando o Dataflow copia a maioria dos dados, ele para de gravar no no banco de dados de origem e aguarda a conclusão da migração dos dados. Isso resulta em um curto período de inatividade, enquanto o Spanner alcança a fonte no seu banco de dados. 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 exportar para CSV ou Avro, depois migrar para o Spanner tempo de inatividade. Recomendamos usar o Dataflow ou Ferramenta de migração do Spanner.
As migrações com inatividade são recomendadas apenas para ambientes de teste ou que podem lidar com algumas horas de inatividade. Em um banco de dados em tempo real, a migração com inatividade pode resultar em perda de dados.
Para executar uma migração de inatividade, siga estas etapas:
- Gere um arquivo dump dos dados do banco de dados de origem.
- Faça upload do arquivo dump para o Cloud Storage em um arquivo MySQL, PostgreSQL, Avro formato CSV.
- Carregar 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 agiliza a gravação em Spanner, que pode ler vários arquivos dump em paralelo.
Ao gerar um arquivo dump do banco de dados de origem, para gerar um arquivo instantâneo dos dados, lembre-se do seguinte:
- Para evitar que os dados sejam alterados durante a geração do arquivo dump, antes de fazer 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 replicação desativada.
Formatos recomendados para migração em massa
O Avro é o formato preferencial para migração em massa para o Spanner. Se estiver usando o Avro, considere o seguinte:
- Para gerar um despejo Avro dos dados, use uma ferramenta como DBeam: Para obter mais informações sobre como exportar para Avro, consulte Exportar dados de um banco de dados que não seja do Spanner para arquivos Avro
- Para importar dados Avro, use um job de importação do Dataflow. Para mais informações, consulte Importe arquivos Avro de bancos de dados que não sejam do Spanner para no 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 fonte. 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 use uma modelo de importação. Para mais informações, consulte Modelos de pipeline de dados do Dataflow.
Se estiver usando o MySQL ou o PostgreSQL, você vai poder usar 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 comparação de dados da fonte e do tabelas de destino para garantir a correspondência.
Ferramenta de validação de dados (DVT) é uma ferramenta de código aberto que se conecta a repositórios de dados e faz verificações entre a origem e o Spanner. Recomendamos usá-lo 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 foram correto .
- Corresponda o número de linhas de cada tabela.
- Extraia linhas aleatórias para verificar a exatidão.
- Valide suas colunas (
count,sum,avg,min,max,group by). - Compare qualquer verificação cíclica de redundância 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 transição e failover
Muitas vezes, as migrações são demoradas e complexas. Use substitutos para evitar impacto significativo em caso de erro durante a migração, permitindo alternar de volta ao banco de dados de origem com tempo de inatividade mínimo.
A recomendação atual é consumir fluxos de alteração para realizar a replicação reversa, e gravam 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 de fragmentação na origem.