Configure a sua origem

Vista geral

O Database Migration Service suporta migrações únicas e contínuas de bases de dados de origem para bases de dados de destino do Cloud SQL.

As bases de dados de origem suportadas para o MySQL incluem:

• Amazon RDS 5.6, 5.7 e 8.0
• MySQL autogerido (nas instalações ou em qualquer VM na nuvem que controle totalmente) 5.5, 5.6, 5.7, 8.0
• Cloud SQL para MySQL 5.6, 5.7, 8.0 e 8.4
• Amazon Aurora 5.6, 5.7 e 8.0
• Microsoft Azure Database para MySQL 5.7 e 8.0

Para origens MySQL 8.0, o Database Migration Service também suporta as 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, 8.0.41 e 8.0.42.

Para configurar uma base de dados de origem, conclua os seguintes passos:

1. Para origens do Cloud SQL: se estiver a migrar de uma instância do Cloud SQL que usa uma ligação de IP privada para uma instância do Cloud SQL que usa um intervalo de IP de endereços não RFC 1918, adicione o intervalo não RFC 1918 à configuração de rede da sua instância do Cloud SQL de origem. Consulte o artigo Configure redes autorizadas na documentação do Cloud SQL.
2. Antes de migrar dados da base de dados de origem para a base de dados de destino, certifique-se de que interrompe todas as operações de escrita da linguagem de definição de dados (LDD) durante a fase de descarga completa. Pode usar um script para verificar se as operações de LDD foram interrompidas. Depois de a migração estar na fase de CDC, pode retomar as operações de DDL.
3. Certifique-se de que a base de dados de origem não contém metadados definidos por utilizadores com a cláusula DEFINER. Consulte Crie e execute uma tarefa de migração do MySQL que contenha metadados com uma cláusula DEFINER.
4. Se a sua base de dados de origem contiver objetos que referenciam tabelas nos esquemas do sistema mysql, performance_schema, information_schema, ndbinfo ou sys, certifique-se de que as bases de dados de réplica também contêm estas tabelas de esquemas do sistema.

   Se as bases de dados de réplica não tiverem estas tabelas, a tarefa de migração pode falhar com o erro Unknown table in system schema .

5. Tem de definir a opção server-id para um valor igual ou superior a 1. Para mais informações, consulte o artigo Opções e variáveis de replicação e registo binário.
6. Configure o registo do ID da transação global (GTID) definindo o GTID_MODE como ON ou OFF. O valor GTID_MODE de ON_PERMISSIVE não é suportado.

   O valor que deve usar depende dos requisitos de migração:

   • Se migrar para uma instância de destino existente que tenha réplicas de leitura ativadas, defina GTID_MODE como ON.
   • Se estiver a usar uma transferência manual para migrar os seus dados, defina GTID_MODE como ON.
   Para mais informações sobre GTID_MODE, consulte Variável do sistema do ID da transação global.

7. Tem de configurar a conta de utilizador usada para estabelecer ligação à base de dados de origem de modo a aceitar ligações de qualquer lugar (anfitrião = %). O acesso pode ser restrito a este utilizador num passo posterior.

   Para limitar a possibilidade de comprometer outros aspetos da base de dados, recomendamos que crie uma conta separada para este fim.

   Existem quatro tipos de combinações de migrações e despejos:

   • Tipo 1: migração contínua e descarga gerida
   • Tipo 2: migração contínua e descarga manual
   • Tipo 3: migração única e descarga gerida
   • Tipo 4: migração única e descarga manual

   Os privilégios para cada tipo de migração e combinação de despejo estão listados nos separadores abaixo.

   Tipo 1

   A conta de utilizador que configurar tem de ter os seguintes privilégios:

   • REPLICATION SLAVE
   • EXECUTE
   • SELECT
   • SHOW VIEW
   • REPLICATION CLIENT
   • RELOAD
   • TRIGGER
   • (Apenas para migrar do Amazon RDS e do Amazon Aurora) LOCK TABLES

   MySQL versão 8.0 ou posterior: para um desempenho ideal, certifique-se de que não concede o privilégio BACKUP_ADMIN a esta conta.

   Tipo 2

   A conta de utilizador que configurar tem de ter os seguintes privilégios:

   • REPLICATION SLAVE
   • EXECUTE

   Tipo 3

   A conta de utilizador que configurar tem de ter os seguintes privilégios:

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • (Apenas para migrar do Amazon RDS e do Amazon Aurora) LOCK TABLES
   • (Para migrar de origens apenas com a definição GTID_MODE = ON)RELOAD

   MySQL versão 8.0 ou posterior: para um desempenho ideal, certifique-se de que não concede o privilégio BACKUP_ADMIN a esta conta.

   Tipo 4

   Não são necessários privilégios.

8. Antes de configurar os registos binários, certifique-se de que:
   • Ative os registos binários na base de dados de origem.
   • Use o registo binário baseado em linhas.
   • Mantenha os registos binários durante um período suficientemente longo para suportar a migração da base de dados. Geralmente, uma semana é suficiente.

   Para configurar registos binários, expanda a secção da sua origem:

   MySQL autoalojado

   Consoante a versão do MySQL, especifique um período com tempo suficiente para a replicação ocorrer:

   • MySQL 5.5 – 5.7: expire_logs_days
   • MySQL 8.0: expire_logs_days, binlog_expire_logs_seconds

   Microsoft Azure Database for MySQL

   O registo binário está ativado por predefinição na base de dados do Microsoft Azure para MySQL. Não precisa de a ativar. Para mais informações, consulte a documentação da Microsoft.

   Configure os seguintes parâmetros obrigatórios:

   1. Defina binlog_expire_logs_seconds para um período suficientemente longo para suportar a migração da base de dados.

      Para mais informações, consulte os artigos Configure os parâmetros do servidor na base de dados Azure para PostgreSQL e o parâmetro binlog_expire_logs_seconds na documentação da Microsoft.

   2. Reinicie o servidor para que as alterações feitas possam entrar em vigor.

   Amazon RDS

   Para o Amazon RDS, define a configuração baseada em linhas no grupo de parâmetros configurando o parâmetro binlog retention hours. Este parâmetro é usado para especificar durante quantas horas o Amazon RDS deve reter ficheiros de registo binários.

   Para definir o período de retenção dos registos binários no Amazon RDS, use o procedimento armazenado mysql.rds_set_configuration e especifique um período com tempo suficiente para a replicação ocorrer. Por exemplo:

   call mysql.rds_set_configuration('binlog retention hours',168);

   Amazon Aurora

   Para o Amazon Aurora, siga estes passos:

   1. Ative o registo binário para a sua base de dados MySQL.
   2. Defina o período de retenção do registo binário:

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

   3. Reinicie o servidor para que as alterações feitas possam entrar em vigor.
9. Todas as tabelas (exceto as tabelas em bases de dados do sistema) usam o motor de armazenamento InnoDB.
10. A palavra-passe da conta de utilizador usada para estabelecer ligação à base de dados de origem não pode ter mais de 32 carateres. Este é um problema específico da replicação do MySQL.

11. Apenas para origens da base de dados do Microsoft Azure para MySQL: verifique o valor da definição require_secure_transport.

    Por predefinição, as bases de dados do Microsoft Azure requerem encriptação SSL/TLS para todas as ligações recebidas. Consoante o valor de require_secure_transport, use uma das seguintes definições de encriptação quando criar o perfil de ligação de origem:

    • Se require_secure_transport estiver definido como on, selecione Básico, TLS ou mTLS.
    • Se require_secure_transport estiver definido como off, selecione Nenhum.