Configurar sua fonte

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

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 e 8.0
• MySQL 5.5, 5.6, 5.7 e 8.0 autogerenciado (no local ou em qualquer VM de nuvem totalmente controlada por você)
• 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 do MySQL 8.0, o Database Migration Service também aceita 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 um banco de dados de origem, siga estas etapas:

1. 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.
2. 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.
3. 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.
4. Se o banco de dados de origem tiver objetos que referenciam tabelas nos esquemas de sistema mysql, performance_schema, information_schema, ndbinfo ou sys, 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 .

5. 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.
6. Configure o registro de ID de transação global (GTID) definindo o GTID_MODE como ON ou OFF. O valor GTID_MODE de ON_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 como ON.
   • Se você estiver usando um despejo manual para migrar 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. 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.

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

   Para mais informações sobre privilégios, consulte Privilégios fornecidos pelo MySQL. Para mais informações sobre contas de usuário, consulte Formato de conta de usuário do MySQL.

   Tipo 2

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

   • REPLICATION SLAVE
   • EXECUTE

   Para mais informações sobre privilégios, consulte Privilégios fornecidos pelo MySQL. Para mais informações sobre contas de usuário, consulte Formato de conta de usuário do MySQL.

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

   Para mais informações sobre privilégios, consulte Privilégios fornecidos pelo MySQL. Para mais informações sobre contas de usuário, consulte Formato de conta de usuário do MySQL.

   Tipo 4

   Nenhum privilégio necessário.

   Para mais informações sobre privilégios, consulte Privilégios fornecidos pelo MySQL. Para mais informações sobre contas de usuário, consulte Formato de conta de usuário do MySQL.

8. 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:

   1. 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.

   2. 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 armazenamento 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);

   O valor máximo que pode ser definido para esse parâmetro é de 168 horas (ou 7 dias).

   Amazon Aurora

   Para o Amazon Aurora, siga estas etapas:

   1. Ative a geração de registros binários no seu banco de dados MySQL.
   2. Defina o período de armazenamento de registros binários:

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

      Você está inserindo esse comando porque quer garantir uma replicação adequada, configurando seu sistema para reter registros binários por pelo menos sete dias (ou 168 horas).
   3. Reinicie o servidor para que as alterações feitas entrem em vigor.
9. Todas as tabelas (exceto tabelas em bancos de dados do sistema) usam o mecanismo de armazenamento InnoDB.

   Para mais informações sobre o InnoDB, consulte O mecanismo de armazenamento InnoDB. Para mais informações sobre a conversão para o InnoDB, consulte Como converter tabelas do MyISAM para o InnoDB.

10. 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.

    Para mais informações sobre a limitação do comprimento da senha do usuário do MySQL, consulte Bug do MySQL #43439.

11. 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 como on, selecione Básico, TLS ou mTLS.
    • Se require_secure_transport estiver definido como off, selecione Nenhum.