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: também é possível 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.

As limitações conhecidas do uso de 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 é compatível com a migração de dados de bancos de dados criptografados do Amazon Aurora ou do Amazon RDS porque eles processam a descriptografia de maneira transparente nos serviços. Para mais informações, consulte Como criptografar recursos do Amazon Aurora, Como 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 privilégio BACKUP_ADMIN.

  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 as principais versões 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 compatíveis com o Cloud SQL para MySQL, bem como as notas da versão 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 erro Table definition has changed) 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 conceda privilégios de SUPERUSUÁRIO, serão necessárias outras etapas para uma migração bem-sucedida, incluindo um breve período de inatividade de gravação na origem. Para mais informações, consulte as seções Configurar o banco de dados de origem para o Amazon RDS e Específico do 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 da Oracle Cloud Infrastructure (OCI) porque os arquivos de registro binário não podem ser recuperados 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 autogerenciada do MySQL, o GTID não é compatível. É necessário usar o arquivo de registro binário e a replicação baseada em 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 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, a migração poderá falhar com a mensagem ERROR 1109 (42S02): Unknown table in <schema name here>. 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 modificações que possam interromper o processo de migração ou afetar a integridade dos dados. Depois que o destino é promovido, ele se torna gravável.

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

• Defina o formato do registro binário como ROW. Se você configurar o registro binário para qualquer outro formato, como STATEMENT ou MIXED, a replicação pode falhar. Por exemplo, usando a instrução LOAD DATA IN FILE.

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

• 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 #105761 na documentação do MySQL.

• O InnoDB é o único mecanismo de armazenamento compatível com 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 alto desempenho, o que melhora significativamente a velocidade da migração. Ao usar o paralelismo de despejo de dados, considere o seguinte:

• O paralelismo de despejo de dados está disponível apenas 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 aproximado de bloqueio
  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 o banco de dados de origem. Para informações sobre como migrar de réplicas de leitura no Amazon RDS, consulte Como 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 de 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 que contêm dados do usuário (como tabelas em esquemas do sistema ou bancos de dados).

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

• Só é possível configurar 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 servidor externo.
• 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 a geração de registros de ID de transação global (GTID, na sigla em inglês) ativada.
• Não é possível usar réplicas de leitura do Cloud SQL para MySQL como a instância de destino da migração.
• 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 o 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 liberar espaço, é possível excluir jobs de migração (incluindo os concluídos) e perfis de conexão.