Este documento descreve o processo de migração do seu banco de dados para no 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 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.
- Carregar dados de amostra.
- Migre seu aplicativo.
- Teste e ajuste seu desempenho.
- Migrar os dados.
- Valide a migração.
- Configure mecanismos de failover e de transição.
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.
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. Em algumas etapas do processo, nenhuma ferramenta é portanto, você conclui 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.
Avaliação de migração de banco de dados (DMA) oferece uma avaliação básica para migrar o PostgreSQL para o Spanner.
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 e gravar em um destino especificado.
O Dataflow é um serviço do Google Cloud que ajuda a gravar uma grande quantidade de dados no Spanner de maneira mais eficiente usando modelos.
Migração de dados em massa é um modelo do Dataflow que permite migrar grandes volumes de dados conjuntos de dados diretamente no 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 os DVTs produtos do Google Cloud.
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 no estágio de migração e seja usando um arquivo dump ou conectando diretamente sua origem banco de dados:
| Estágio da migração | Despejar arquivo | 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 (link em inglês) para configurar e converter o esquema. |
| Amostra 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 o DVT. |
| Configuração de failover | Não relevante | Use SMT para 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 algumas das as etapas de migração usando um arquivo dump do PostgreSQL. Você precisa 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 | Despejar arquivo | 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. |
| Amostra de carregamento de dados |
|
Faça uma migração com tempo mínimo de inatividade. |
| Migração de dados | Não relevante | Execute uma migração com tempo de inatividade mínimo. |
| 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 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 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 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 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 de compatibilidade e recomendações de tipos de dados
- Edições e recomendações da 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ã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.
Carregar dados de amostra
Depois de criar um esquema compatível com o Spanner, prepare os para ser testado 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 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 do Spanner e os mapeadores relacionais de objetos (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.
- 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 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 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 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.
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.
Para o tráfego de produção em particular, o ajuste de desempenho é importante para evitar surpresas. Quanto mais próximo a configuração estiver de perto, o ajuste de desempenho será mais eficaz 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:
- Faça upload de um subconjunto dos seus dados para 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 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 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 Key Visualizer estatísticas no console do Google Cloud. Para mais informações sobre como evitar pontos de acesso, consulte Como escolher 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 banco de dados, entre em contato com o suporte do Spanner.
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, 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.
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, 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:
- Armazenamento de dados da CDC enquanto o snapshot é migrado.
- gravar os dados de CDC no Spanner e capturar os dados de entrada 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 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 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. 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 que podem lidar com algumas horas de inatividade. Em um banco de dados ativo, uma migração com inatividade pode resultar em 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 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 realizar o despejo, aplique um bloqueio de leitura no banco de dados de origem.
- 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 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 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 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 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. Você pode 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, 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 sua 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 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 estão corretos.
- 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 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 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 nos tipos de dados ou conteúdo.
- reverter todas as transformações realizadas durante a migração.
- Envie os dados para o destino apropriado, considerando de fragmentação na origem.