Visão geral
Antes de migrar seus bancos de dados para o Cloud SQL, considere as limitações conhecidas para esse cenário de migração.
Limitações conhecidas para o uso de um banco de dados MySQL como fonte incluem:
Não é possível migrar para o MySQL 5.6 ou MySQL 8.4 com um arquivo de backup físico do Percona XtraBackup.
Para migrações do MySQL 8.0 para o MySQL 8.4: outras considerações para migrações do 8.0 para o 8.4 incluem:
- O banco de dados de destino precisa ter a flag
local_infiledefinida comoON. - A conta de migração dedicada na instância de origem não pode ter o
BACKUP_ADMINprivilégio.
Essas considerações também são abordadas nas seções relevantes, como a página Configurar o banco de dados de origem.
- O banco de dados de destino precisa ter a flag
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.
Não faça alterações na linguagem de definição de dados (DDL, na sigla em inglês), como modificar definições de tabelas, durante a fase de despejo de dados completo. As alterações de DDL feitas antes que o job de migração passe para a fase de CDC podem fazer com que o job de migração falhe. Para mais informações, consulte Diagnosticar problemas:
Table definition has changederro.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 específicas do Amazon RDS e do Amazon Aurora.
O Database Migration Service não pode migrar dados de uma instância de réplica de leitura do Amazon Aurora de um cluster de banco de dados MySQL porque os arquivos de registro binário não podem ser recuperados da instância. Para mais informações, consulte a seção específica do Amazon Aurora.
O banco de dados do sistema MySQL não é migrado como parte da migração do servidor, o que significa que as informações sobre os papéis do usuário não estão incluídas.
É possível selecionar bancos de dados específicos ao migrar usando o Database Migration Service. Todas as tabelas e esquemas dos bancos de dados selecionados são migrados, exceto os seguintes esquemas do sistema:
mysql,performance_schema,information_schemaesys. 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 aERROR 1109 (42S02): Unknown table in <schema name here>mensagem. Consulte Configurar o banco de dados de origem e Diagnosticar problemas.Se os bancos de dados criptografados exigirem chaves de criptografia gerenciadas pelo cliente para descriptografar as informações nos bancos de dados e se o Database Migration Service não tiver acesso às chaves, os bancos de dados não poderão ser migrados.
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. Para mais informações, consulte Criptografar recursos do Amazon Aurora e Criptografar recursos do Amazon RDS.
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.
No momento, 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, comoSTATEMENTouMIXED, pode causar falha na replicação. Por exemplo, usando a instruçãoLOAD DATA IN FILE.Saiba mais sobre essa limitação para os formatos
STATEMENTouMIXED.Se você criar um job de migração contínuo usando seu próprio arquivo dump, não use o utilitário
mysqldumpda 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. Para ajuda com a conversão de 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 conectividade de 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 de 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 ou 8 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
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 tem uma réplica de leitura exige que a instância de origem tenha o registro de ID de transação global (GTID, na sigla em inglês) 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. Se você quiser criar mais espaço para esses itens, os jobs de migração (incluindo os concluídos) e os perfis de conexão poderão ser excluídos.