Visão geral
Antes de migrar seus bancos de dados para o Cloud SQL, considere as limitações conhecidas desse cenário de migração.
Limitações conhecidas para o uso de um banco de dados MySQL como fonte:
Não é possível migrar para o MySQL 5.6 ou 8.4 com um arquivo de backup físico do Percona XtraBackup.
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 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 e as notas da versão principal de destino para determinar as incompatibilidades que você precisa resolver.
Não faça mudanças na linguagem de definição de dados (DDL), como modificar definições de tabelas, durante a fase de despejo completo de dados. As mudanças de DDL realizadas antes que o job de migração passe para a fase de CDC podem causar falha no job de migração. Para mais informações, consulte 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 conceda privilégios de SUPERUSER, serão necessárias etapas adicionais 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 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 não é possível recuperar arquivos de registro binário 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 Database Migration Service. Todas as tabelas de todos os bancos de dados e esquemas são migradas, 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 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 neles, e se 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 eles 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 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 do registro binário como
ROW. Configurar o 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ínua 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 compatível com o Cloud SQL. A migração com o MyISAM pode causar inconsistência nos dados e exige 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
Com o paralelismo de despejo de dados, é possível migrar de bancos de dados MySQL usando um mecanismo de despejo de alta performance, o que melhora significativamente a velocidade da migração. Ao usar o paralelismo de despejo de dados, considere o seguinte:
No momento, 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 aproximado de bloqueio 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 precisa estar vazia ou conter apenas dados de configuração do sistema. Não é possível migrar para instâncias de destino que já existem e 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 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 autônomas do Cloud SQL. Não é possível migrar para réplicas de servidores externos.
- Não é possível migrar dados para uma instância do Cloud SQL que tenha o Private Service Connect ativado.
- Para migrar para uma instância do Cloud SQL que tenha uma réplica de leitura, é necessário que a instância de origem tenha a geração de registros de ID global de transação (GTID) ativada.
- Para usuários do Terraform: o Database Migration Service modifica as configurações de backup e recuperação da sua 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 podem ser excluídos.