Configure sua fonte

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 suportados para MySQL incluem:

• Amazon RDS 5.6, 5.7, 8.0
• MySQL autogerenciado (no local ou em qualquer VM na nuvem que você controle totalmente) 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, 8.0
• Banco de dados Microsoft Azure para MySQL 5.7, 8.0

Para fontes 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.

Para configurar um banco de dados de origem, conclua as etapas a seguir:

1. Para origens do Cloud SQL: se você estiver migrando de uma instância do Cloud SQL que usa uma conexão IP privada para uma instância do Cloud SQL que usa um intervalo de endereços 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.
2. Antes de migrar dados do banco de dados de origem para o banco de dados de destino, certifique-se de interromper todas as operações de gravação de linguagem de definição de dados (DDL) durante a fase de dump completo. Você pode usar um script para verificar se as operações DDL foram interrompidas. Depois que a migração estiver na fase CDC, será possível retomar as operações DDL.
3. Certifique-se de que seu banco de dados de origem não contenha metadados definidos por usuários com a cláusula DEFINER. Consulte Criar e executar um trabalho de migração MySQL contendo metadados com uma cláusula DEFINER .
4. Se seu banco de dados de origem contiver objetos que fazem referência a tabelas nos esquemas de sistema mysql , performance_schema , information_schema , ndbinfo ou sys , certifique-se de que os bancos de dados de réplica também contenham essas tabelas de esquema de sistema.

   Se os bancos de dados de réplica não tiverem essas tabelas, seu trabalho de migração poderá falhar com o erro Unknown table in system schema .

5. Você deve configurar a opção server-id como um valor 1 ou maior. Para obter mais informações, consulte Opções e variáveis ​​de replicação e registro binário .
6. Configure o log de ID de transação global (GTID) definindo GTID_MODE como ON ou OFF . O valor GTID_MODE de ON_PERMISSIVE não é compatível.

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

   • Se você migrar para uma instância de destino existente que tenha réplicas de leitura habilitadas, defina GTID_MODE como ON .
   • Se você estiver usando um despejo manual para migrar seus dados, defina GTID_MODE como ON .
   Para obter mais informações sobre GTID_MODE , consulte Variável de sistema de ID de transação global .

7. Você deve configurar a conta de usuário usada para conectar-se ao banco de dados de origem para aceitar conexões de qualquer lugar (host = % ). O acesso pode ser restrito a este usuário em uma etapa posterior.

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

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

   • Tipo 1: migração contínua e dump gerenciado
   • Tipo 2: migração contínua e despejo manual
   • Tipo 3: migração única e dump gerenciado
   • Tipo 4: migração única e despejo manual

   Os privilégios para cada tipo de combinação de migração e dump estão listados nas guias abaixo.

   Tipo 1

   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 Amazon Aurora) LOCK TABLES

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

   Tipo 2

   A conta de usuário configurada deve ter os seguintes privilégios:

   • REPLICATION SLAVE
   • EXECUTE

   Tipo 3

   A conta de usuário configurada deve ter os seguintes privilégios:

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • (Somente para migração do Amazon RDS e Amazon Aurora) LOCK TABLES
   • (Somente para migração de fontes com a configuração GTID_MODE = ON ) RELOAD

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

   Tipo 4

   Nenhum privilégio é necessário.

8. Antes de configurar logs binários, certifique-se de:
   • Habilite logs binários em seu banco de dados de origem.
   • Use o registro binário baseado em linha .
   • Retenha os logs binários por um período longo o suficiente para suportar a migração do banco de dados. Geralmente, uma semana é suficiente.

   Para configurar logs binários, expanda a seção de sua origem:

   MySQL auto-hospedado

   Dependendo da sua 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 Microsoft Azure para MySQL

   O log binário é habilitado por padrão no Banco de Dados do Microsoft Azure para MySQL. Você não precisa habilitá-lo. Para obter mais informações, consulte a documentação da Microsoft .

   Configure os seguintes parâmetros necessários:

   1. Configure binlog_expire_logs_seconds para um período longo o suficiente para suportar a migração do banco de dados.

      Para obter mais informações, consulte Configurar parâmetros do servidor no Banco de Dados do Azure para PostgreSQL e o parâmetro binlog_expire_logs_seconds na documentação da Microsoft.

   2. Reinicie o seu servidor para que as alterações feitas tenham efeito.

   Amazon RDS

   Para o Amazon RDS, você 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 quantas horas o Amazon RDS deve reter arquivos de log binários.

   Para definir o período de retenção para logs 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. Por exemplo:

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

   Amazônia Aurora

   Para Amazon Aurora, siga estas etapas:

   1. Habilite o log binário para seu banco de dados MySQL .
   2. Defina o período de retenção do log binário:

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

   3. Reinicie o seu servidor para que as alterações feitas tenham efeito.
9. Todas as tabelas (exceto tabelas em bancos de dados do sistema) usam o mecanismo de armazenamento InnoDB.
10. A senha da conta de usuário usada para conectar-se ao banco de dados de origem não deve exceder 32 caracteres. Este é um problema específico da replicação do MySQL.

11. Somente para fontes do Banco de Dados do Microsoft Azure para MySQL : verifique o valor da sua 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 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 on , selecione Basic , TLS ou mTLS .
    • Se require_secure_transport estiver off , selecione Nenhum .