Visão geral
O Database Migration Service oferece suporte a migrações únicas e contínuas de bancos de dados de origem para bancos de dados de destino do Cloud SQL.
Os bancos de dados de origem compatíveis com o MySQL incluem:
- Amazon RDS 5.6, 5.7, 8.0
- MySQL autogerenciado (no local ou em qualquer VM de nuvem totalmente controlada por você) 5.5, 5.6, 5.7, 8.0
- Cloud SQL para MySQL 5.6, 5.7, 8.0, 8.4
- Amazon Aurora 5.6, 5.7 e 8.0
- Banco de Dados do Microsoft Azure para MySQL 5.7, 8.0
Para origens do MySQL 8.0, o serviço de migração de banco de dados também oferece suporte às seguintes versões secundárias: 8.0.18, 8.0.26, 8.0.27, 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40.
Para configurar um banco de dados de origem, siga estas etapas:
- Para origens do Cloud SQL:se você estiver migrando de uma instância do Cloud SQL que usa uma conexão de IP particular para uma instância do Cloud SQL que usa um intervalo de IP não RFC 1918, adicione o intervalo não RFC 1918 à configuração de rede da sua instância de origem do Cloud SQL. Consulte Configurar redes autorizadas na documentação do Cloud SQL.
- Antes de migrar dados do banco de dados de origem para o de destino, pare todas as operações de gravação de linguagem de definição de dados (DDL) durante a fase de despejo completo. Use um script para verificar se as operações de DDL foram interrompidas. Depois que a migração estiver na fase de CDC, será possível retomar as operações DDL.
- Verifique se o banco de dados de origem não contém metadados definidos por usuários com a cláusula DEFINER. Consulte Criar e executar um job de migração do MySQL que contém metadados com uma cláusula DEFINER.
- Se o banco de dados de origem tiver objetos que referenciam tabelas nos esquemas de sistema
mysql
,performance_schema
,information_schema
,ndbinfo
ousys
, verifique se os bancos de dados de réplica também têm essas tabelas.Se os bancos de dados de réplica não tiverem essas tabelas, o job de migração poderá falhar com o erro
Unknown table in system schema
. - Defina a opção server-id como um valor de 1 ou maior. Para mais informações, consulte Opções e variáveis de geração de registros binários e replicação.
- Configure o registro de ID de transação global (GTID) definindo o
GTID_MODE
comoON
ouOFF
. O valorGTID_MODE
deON_PERMISSIVE
não é aceito.O valor a ser usado depende dos requisitos de migração:
- Se você
migrar para uma instância de destino existente que tenha
réplicas de leitura
ativadas, defina
GTID_MODE
comoON
. - Se você estiver usando um despejo manual para migrar seus dados, defina
GTID_MODE
comoON
.
GTID_MODE
, consulte Variável do sistema do ID da transação global. - Se você
migrar para uma instância de destino existente que tenha
réplicas de leitura
ativadas, defina
-
Configure a conta de usuário usada para se conectar ao banco de dados de origem para aceitar conexões de qualquer lugar (host =
%
). O acesso pode ser restrito a esse usuário em uma etapa posterior.Para limitar a possibilidade de comprometer outros aspectos do banco de dados, recomendamos que você crie uma conta separada para isso.
Há quatro tipos de combinações de migrações e despejos:
- Tipo 1: migração contínua e despejo gerenciado
- Tipo 2: migração contínua e despejo manual
- Tipo 3: migração única e despejo gerenciado
- Tipo 4: migração única e despejo manual
Os privilégios para cada tipo de combinação de migração e despejo estão listados nas guias abaixo.
A conta de usuário configurada deve ter os seguintes privilégios:
REPLICATION SLAVE
EXECUTE
SELECT
SHOW VIEW
REPLICATION CLIENT
RELOAD
TRIGGER
- (Somente para migração do Amazon RDS e do Amazon Aurora)
LOCK TABLES
MySQL versão 8.0 ou mais recente:para ter o melhor desempenho, não conceda o privilégio
BACKUP_ADMIN
a essa conta.A conta de usuário configurada deve ter os seguintes privilégios:
REPLICATION SLAVE
EXECUTE
A conta de usuário configurada deve ter os seguintes privilégios:
SELECT
SHOW VIEW
TRIGGER
- (Somente para migração do Amazon RDS e do Amazon Aurora)
LOCK TABLES
- (Somente para migração de origens com a configuração
GTID_MODE = ON
)RELOAD
MySQL versão 8.0 ou mais recente:para ter o melhor desempenho, não conceda o privilégio
BACKUP_ADMIN
a essa conta.Nenhum privilégio necessário.
- Antes de configurar os registros binários, verifique se:
- Ative os registros binários no banco de dados de origem.
- Use a geração de registros binários baseada em linha.
- Mantenha os registros binários por um período suficiente para suportar a migração do banco de dados. Geralmente, uma semana é suficiente.
Para configurar registros binários, abra a seção da sua origem:
MySQL auto-hospedado
Dependendo da versão do MySQL, especifique um período com tempo suficiente para que a replicação ocorra:
- MySQL 5.5 - 5.7:
expire_logs_days
- MySQL 8.0:
expire_logs_days
,binlog_expire_logs_seconds
Banco de Dados do Microsoft Azure para MySQL
A geração de registros binários é ativada por padrão no Banco de Dados do Microsoft Azure para MySQL. Não é necessário ativar esse recurso. Para mais informações, consulte a documentação da Microsoft.
Configure os seguintes parâmetros obrigatórios:
Defina
binlog_expire_logs_seconds
para um período longo o suficiente para suportar a migração do banco de dados.Para mais informações, consulte Configurar parâmetros do servidor no Azure Database for PostgreSQL e o parâmetro
binlog_expire_logs_seconds
na documentação da Microsoft.- Reinicie o servidor para que as alterações feitas entrem em vigor.
Amazon RDS
No Amazon RDS, você define a configuração baseada em linha no grupo de parâmetros configurando o parâmetro
binlog retention hours
. Esse parâmetro é usado para especificar por quantas horas o Amazon RDS deve reter os arquivos de registro binário.Para definir o período de retenção de registros binários no Amazon RDS, use o procedimento armazenado
mysql.rds_set_configuration
e especifique um período com tempo suficiente para que a replicação ocorra. Exemplo:call mysql.rds_set_configuration('binlog retention hours',168);
Amazon Aurora
Para o Amazon Aurora, siga estas etapas:
- Ative a geração de registros binários no seu banco de dados MySQL.
- Defina o período de armazenamento de registros binários:
mysql> call mysql.rds_set_configuration('binlog retention hours', 168);
- Reinicie o servidor para que as alterações feitas entrem em vigor.
- Todas as tabelas (exceto tabelas em bancos de dados do sistema) usam o mecanismo de armazenamento InnoDB.
- A senha da conta de usuário usada para se conectar ao banco de dados de origem não pode ter mais de 32 caracteres. Esse é um problema específico da replicação do MySQL.
Somente para origens do Microsoft Azure Database para MySQL: verifique o valor da configuração
require_secure_transport
.Por padrão, os bancos de dados do Microsoft Azure exigem criptografia SSL/TLS para todas as conexões de entrada. Dependendo do valor de
require_secure_transport
, use uma das seguintes configurações de criptografia ao criar o perfil de conexão de origem:- Se
require_secure_transport
estiver definido comoon
, selecione Básico, TLS ou mTLS. - Se
require_secure_transport
estiver definido comooff
, selecione Nenhum.
- Se