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 o MySQL 8.4 com um arquivo de backup físico do Percona XtraBackup.
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 com suporte do Cloud SQL para MySQL e as notas da versão da sua 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), como modificar definições de tabela, durante a fase de despejo completo de dados. As mudanças de DDL realizadas antes de o job de migração passar para a fase de CDC podem causar a falha do job de migração. Para mais informações, consulte Como diagnosticar problemas: erro
Table definition has changed
.Se a origem for o Amazon RDS MySQL, o Amazon Aurora MySQL ou uma origem que não concede privilégios de SUPERUSER, outras etapas serão necessárias para concluir a migração, incluindo um breve período de inatividade de gravação na origem. Para mais informações, consulte as seções Específicas do Amazon RDS e Específicas 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 as funções do usuário não são incluídas.
Não é possível selecionar objetos de banco de dados específicos (como bancos de dados, tabelas ou esquemas) ao migrar usando o serviço de migração de banco de dados. Todas as tabelas de todos os bancos de dados e esquemas são migradas, excluindo os seguintes esquemas de sistema:
mysql
,performance_schema
,information_schema
esys
. 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 pode falhar com a mensagemERROR 1109 (42S02): Unknown table in <schema name here>
. 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 e o serviço de migração de banco de dados 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 eles processam a descriptografia de forma transparente nos serviços. Para mais informações, consulte Como criptografar recursos do Amazon Aurora e Como criptografar recursos do Amazon RDS.
Durante a migração, o banco de dados do Cloud SQL de destino fica no modo somente leitura para evitar modificações que possam interromper o processo de migração ou a integridade dos dados. Depois que o destino é promovido, ele se torna gravável.
No momento, o Database Migration Service não é compatível com o MariaDB.
Defina o formato de registro binário como
ROW
. Configurar o registro binário para qualquer outro formato, comoSTATEMENT
ouMIXED
, pode causar a falha da replicação. Por exemplo, usando a instruçãoLOAD DATA IN FILE
.Saiba mais sobre essa limitação para os formatos
STATEMENT
ouMIXED
.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 compatível com 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.
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, melhorando significativamente a velocidade da migração. Ao usar o paralelismo de despejo de dados, considere o seguinte:
No momento, o paralelismo de dump 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 da trava 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
- A instância de destino precisa estar vazia ou conter apenas
dados de configuração do sistema. Não é possível migrar para instâncias de destino existentes
que contêm dados do usuário (como tabelas).
Se você encontrar problemas devido a dados extras na instância de destino atual, limpe os bancos de dados na instância de destino e tente novamente o job de migração. Consulte Limpar dados extras da sua 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 autônomas do Cloud SQL. Não é possível migrar para réplicas de servidor externo.
- Não é possível migrar dados para uma instância do Cloud SQL que tenha o Private Service Connect ativado.
- A migração para uma instância do Cloud SQL com 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.
- 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 Como 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 podem ser excluídos.