Migrar do MySQL para o Spanner

Esta página oferece uma visão geral de como migrar seu banco de dados de processamento de transações on-line (OLTP, na sigla em inglês) do MySQL para o Spanner. O processo de migração para o Spanner pode variar dependendo de fatores como tamanho dos dados, requisitos de tempo de inatividade, complexidade do código do aplicativo, esquema de fragmentação, funções personalizadas e estratégias de failover e replicação.

A migração do Spanner é dividida nas seguintes etapas:

  1. Avaliar a migração.
  2. Migrar o esquema e traduzir todas as consultas SQL.
  3. Migrar o aplicativo para usar o Spanner além do MySQL.
  4. Carregar dados de amostra e otimizar a performance.
  5. Migrar os dados.
  6. Validar a migração.

Avaliar a migração

A avaliação de uma migração do banco de dados MySQL de origem para o Spanner exige a avaliação das necessidades comerciais, técnicas, operacionais e financeiras. Para mais informações, consulte Avaliar a migração.

Migrar o esquema

Converta seu esquema atual para um esquema do Spanner schema usando a ferramenta de migração do Spanner.

Para mais informações, consulte Migrar um esquema do MySQL.

Migrar o aplicativo para usar o Spanner

O Spanner oferece um conjunto de bibliotecas de cliente para várias linguagens e a capacidade de ler e gravar dados usando chamadas de API específicas do Spanner, consultas SQL e instruções da linguagem de manipulação de dados (DML, na sigla em inglês). O uso de chamadas de API pode ser mais rápido para algumas consultas, como leituras diretas de linhas por chave, porque a instrução SQL não precisa ser traduzida.

O Spanner oferece um driver JDBC para aplicativos Java.

Como parte do processo de migração, os recursos não disponíveis no Spanner, conforme mencionado anteriormente, precisam ser implementados no aplicativo. Por exemplo, um acionador para verificar valores de dados e atualizar uma tabela relacionada precisaria ser implementado no aplicativo usando uma transação de leitura ou gravação para ler a linha atual, verificar a restrição e gravar as linhas atualizadas nas duas tabelas.

O nível de isolamento padrão das transações no Spanner é o isolamento serializável, que garante a consistência externa dos dados. O Spanner também oferece isolamento de leitura repetível. Recomendamos que você defina o nível de isolamento como leitura repetível e o controle de simultaneidade como simultaneidade pessimista como parte do processo de migração do aplicativo para que a semântica de transação do Spanner corresponda à semântica de transação padrão do MySQL. Para instruções sobre como definir o nível de isolamento e o controle de simultaneidade no aplicativo, consulte Usar o nível de isolamento de leitura repetível e Configurar o controle de simultaneidade.

O Spanner oferece transações de leitura ou gravação e somente leitura. Além disso, as transações de leitura podem ter limites de carimbo de data/hora aplicados, em que você está lendo uma versão consistente dos dados:

  • em um momento exato no passado (até 1 hora atrás);
  • no futuro (em que a leitura será bloqueada até que chegue a hora);
  • com uma quantidade aceitável de inatividade definida, que retornará uma visualização consistente com até algum tempo no passado, sem precisar verificar se os dados posteriores estão disponíveis em outra réplica. Isso pode aumentar o desempenho, mas pode retornar dados obsoletos.

Carregar dados de amostra no Spanner

É possível carregar dados de amostra no Spanner antes de realizar uma migração completa de dados para testar esquemas, consultas e seu aplicativo.

Você pode usar o fluxo de trabalho de ETL reverso do BigQuery e a Google Cloud CLI para carregar uma pequena quantidade de dados no formato do arquivo CSV no Spanner.

Para mais informações, consulte Carregar dados de amostra.

Para transferir dados do MySQL para o Spanner, também é possível exportar o banco de dados MySQL para um formato de arquivo portátil, por exemplo, XML, e importar esses dados para o Spanner usando o Dataflow.

Migrar dados para o Spanner

Depois de otimizar o esquema do Spanner e carregar dados de amostra, você pode mover os dados para um banco de dados do Spanner vazio de tamanho de produção.

Para mais informações, consulte Migrar dados do MySQL.

Validar a migração de dados

À medida que os dados são transmitidos para o banco de dados do Spanner, é possível executar periodicamente uma comparação entre os dados do Spanner e os dados do MySQL para garantir que os dados sejam consistentes. Valide a consistência consultando as duas fontes de dados e comparando os resultados.

É possível usar o Dataflow para realizar uma comparação detalhada em grandes conjuntos de dados usando a transformação de junção. Essa transformação usa dois conjuntos de dados com chaves e corresponde os valores pelas chaves. Os valores correspondentes podem ser comparados por igualdade. É possível executar essa verificação regularmente, até que o nível de consistência corresponda aos requisitos do seu negócio.

Para mais informações, consulte Validar a migração de dados.

Configurar fallback e cutover

É possível configurar o fallback e o cutover para o MySQL usando a replicação inversa. A configuração do fallback ajuda a garantir que você tenha um plano de contingência para reverter para o banco de dados MySQL de origem se surgirem problemas após o cutover para o Spanner.

A replicação inversa é útil quando você encontra problemas inesperados com o Spanner e precisa fazer fallback para o banco de dados MySQL original com interrupção mínima do serviço. A replicação inversa permite o fallback replicando os dados gravados no Spanner de volta para o banco de dados MySQL de origem.

O fluxo de replicação inversa envolve as seguintes etapas, realizadas pelo spanner-to-sourcedb modelo do Dataflow:

  1. Ler mudanças do Spanner usando fluxo de alterações do Spanner.

  2. Filtrar mudanças migradas para frente.

  3. Transformar dados do Spanner para serem compatíveis com o esquema do banco de dados de origem.

  4. Verificar se o banco de dados de origem já contém dados mais recentes para a chave primária especificada.

  5. Gravar dados no banco de dados de origem.

A seguir