Limitações conhecidas

Antes de migrar seus bancos de dados para o Cloud SQL, considere as limitações conhecidas para esse cenário de migração.

Observação: você também pode usar o Google Cloud Migration Center para descobrir lacunas no suporte a recursos. Consulte Descobrir e importar bancos de dados na documentação do Migration Center documentation.

As limitações conhecidas para usar um banco de dados MySQL como origem incluem:

• Para migrar bancos de dados criptografados, é necessário fornecer as chaves de criptografia ao Database Migration Service. O Database Migration Service oferece suporte à migração de dados de bancos de dados criptografados do Amazon Aurora ou do Amazon RDS porque esses bancos de dados processam a descriptografia de maneira transparente nos serviços deles. Para mais informações, consulte Criptografar recursos do Amazon Aurora, Criptografar recursos do Amazon RDS e Configurar chaves de criptografia gerenciadas pelo cliente (CMEK).

• Não é possível migrar para o MySQL 5.6, MySQL 8.4 ou MySQL 9.7 com um arquivo de backup físico do Percona XtraBackup.

• Para migrações do MySQL 8.0 para o MySQL 8.4 e do MySQL 8.4 para o MySQL 9.7:

  • O banco de dados de destino precisa ter a flag local_infile definida como ON.
  • A conta de migração dedicada na instância de origem não pode ter o BACKUP_ADMIN privilégio.

  Essas considerações também são abordadas nas seções relevantes, como a página Configurar banco de dados de origem.

• Ao migrar entre versões principais do MySQL (por exemplo, do MySQL 8.0 para o MySQL 8.4), é necessário resolver possíveis incompatibilidades para garantir uma migração tranquila sem problemas de consistência de dados.

  Ao se preparar para uma migração entre versões, revise os recursos com suporte do Cloud SQL para MySQL , bem como as notas de lançamento da versão principal de destino para determinar quais incompatibilidades você precisa resolver.

  • MySQL 9.7
  • MySQL 8.4
  • MySQL 8.0
  • MySQL 5.7

• Durante a fase de despejo de dados completo, não é possível realizar operações de linguagem de definição de dados (DDL, na sigla em inglês), como ALTER TABLE, DROP TABLE, TRUNCATE TABLE, no banco de dados de origem. A execução dessas operações durante a fase de despejo completo pode levar a um deadlock de metadados, fazendo com que o processo de migração falhe (com o Table definition has changed erro) ou pare de responder (e relate erros de tempo limite, como ERROR: While 'Loading data': Dump timeout ou MySQL Error 2013 (HY000): Lost connection to MySQL server during query). É possível realizar mudanças de DDL no banco de dados de origem durante a fase de CDC. Para mais informações, consulte as seguintes entradas na seção de solução de problemas:

  • Table definition has changed
  • While 'Loading data': dump timeout
  • MySQL Error 2013: Lost connection to MySQL server during query
  • Timeout waiting for no write traffic on the source: context deadline exceeded

• Se a origem for o Amazon RDS MySQL, o Amazon Aurora MySQL ou uma origem que não concede privilégios de SUPERUSUÁRIO, etapas adicionais serão necessárias para uma migração bem-sucedida, incluindo um breve tempo de inatividade de gravação na origem. Para mais informações, consulte as seções Configurar banco de dados de origem para Amazon RDS e Amazon Aurora.

• O Database Migration Service não pode migrar dados de uma instância de réplica de leitura do Amazon Aurora ou de uma instância de réplica de leitura do MySQL do Oracle Cloud Infrastructure (OCI) porque não é possível recuperar arquivos de registro binário da instância. Para mais informações sobre o Amazon Aurora, consulte a seção específica do Amazon Aurora.

• Ao migrar de uma réplica de leitura do MySQL autogerenciada, o GTID não é compatível. É necessário usar a replicação baseada em arquivo de registro binário e posição. Para mais informações, consulte Tipos e fases de migração.

• O banco de dados do sistema MySQL não é migrado como parte da migração do servidor. Portanto, as informações sobre contas de usuário, logins e papéis não são incluídas.

• Embora seja possível selecionar bancos de dados específicos para migrar, não é possível filtrar ou selecionar objetos de banco de dados individuais em um banco de dados (como tabelas, visualizações ou procedimentos armazenados específicos) ao migrar usando o Database Migration Service. Todas as tabelas e objetos do InnoDB de cada banco de dados selecionado são migrados, exceto os seguintes esquemas do sistema: mysql, performance_schema, information_schema e sys. Antes de iniciar a migração, verifique se o banco de dados de origem não contém objetos que referenciam tabelas nesses esquemas. Caso contrário, sua migração poderá falhar com a ERROR 1109 (42S02): Unknown table in <schema name here> mensagem. Consulte Configurar o banco de dados de origem e Diagnosticar problemas.

• Durante a migração, o banco de dados de destino do Cloud SQL fica no modo somente leitura para evitar a modificação do banco de dados, o que pode interromper o processo de migração ou a integridade de dados. Depois que o destino é promovido, ele se torna gravável.

• O Database Migration Service não é compatível com o MariaDB.

• Você deve definir o formato do registro binário como ROW. A configuração do registro binário para qualquer outro formato, como STATEMENT ou MIXED, pode causar falha na replicação. Por exemplo, usando a instrução LOAD DATA IN FILE.

  Saiba mais sobre essa limitação para os STATEMENT ou MIXED formatos.

• Se você criar um job de migração contínua usando seu próprio arquivo dump, não use o utilitário mysqldump da versão 5.7.36 do MySQL. Para mais informações, consulte o bug nº 105761 na documentação do MySQL.

• O InnoDB é o único mecanismo de armazenamento com suporte para o Cloud SQL. A migração com o MyISAM pode causar inconsistência nos dados e exigir validação de dados. Se precisar de ajuda para converter tabelas do MyISAM para o InnoDB, consulte a documentação do MySQL.

• O método de conectividade de interfaces do Private Service Connect só é compatível com a migração para instâncias de destino atuais. Se você quiser usar a conexão por IP particular e migrar para uma nova instância de destino, use o peering de VPC.

Considerações sobre o paralelismo de despejo de dados

O paralelismo de despejo de dados permite migrar de bancos de dados MySQL usando um mecanismo de despejo de alta performance, melhorando significativamente a velocidade da migração. Ao usar o paralelismo de despejo de dados, considere o seguinte:

• O paralelismo de despejo de dados só está disponível ao migrar para as versões 5.7, 8.0, 8.4 ou 9.7 do MySQL.

• No início do despejo de dados, o Database Migration Service bloqueia brevemente o banco de dados de origem, tornando-o temporariamente indisponível para gravações. A duração do bloqueio depende do número de tabelas no banco de dados de origem:

  Número de tabelas	Tempo de bloqueio aproximado
  100	1 segundo
  10 mil	9 segundos
  50 mil	49 segundos

Observação: para cenários em que não é possível bloquear o banco de dados de origem, use uma réplica de leitura como banco de dados de origem. Para informações sobre como migrar de réplicas de leitura no Amazon RDS, consulte Migrar do RDS MySQL.

Limitações para migrações para instâncias de destino atuais

• A instância de destino atual só pode conter bancos de dados do sistema padrão que são configurados automaticamente quando você cria a instância de destino. Não é possível migrar para instâncias de destino atuais que contenham dados do usuário (como tabelas em esquemas do sistema ou bancos de dados) não é compatível.

  Se você encontrar problemas devido a dados extras na instância de destino atual instância, limpe os bancos de dados na instância de destino e tente novamente o job de migração. Consulte Limpar dados extras da instância de destino atual.

• É possível configurar apenas um job de migração por instância de destino.
• Só é possível migrar para instâncias independentes do Cloud SQL. Não é possível migrar para réplicas de servidores externos.
• A migração para uma instância do Cloud SQL que tenha uma réplica de leitura exige que a instância de origem tenha o registro de ID de transação global (GTID) ativado.
• Não é possível usar réplicas de leitura do Cloud SQL para MySQL como a instância de destino da migração instância.
• Para usuários do Terraform: o Database Migration Service modifica as configurações de backup e recuperação da instância de destino. Isso pode fazer com que as configurações da instância de destino sejam diferentes da configuração do Terraform usada para provisionamento. Se você tiver esse problema, siga as orientações em Diagnosticar problemas.

Cotas

• É possível ter a qualquer momento até 2.000 perfis de conexão e 1.000 jobs de migração. Para criar espaço para mais, os jobs de migração (incluindo os concluídos) e os perfis de conexão podem ser excluídos.