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, 8.0 e 8.4
• MySQL 5.5, 5.6, 5.7, 8.0 e 8.4 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, 8.0 e 8.4
• Microsoft Azure Database para MySQL 5.7, 8.0 e 8.4

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, 8.0.42 e 8.0.43.

Para configurar um banco de dados de origem, siga estas etapas:

1. Para fontes 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 endereços IP não RFC 1918, adicione o intervalo não RFC 1918 à configuração de rede da 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, interrompa todas as operações de gravação da linguagem de definição de dados (DDL) durante a fase de despejo completo. Você pode usar um script para verificar se as operações de DDL foram interrompidas. Depois que a migração estiver na fase de CDC, você poderá retomar as operações de 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 contêm essas tabelas de esquema do sistema.

   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 igual ou maior que 1. Para mais informações, consulte Opções e variáveis de replicação e geração de registros binários.
6. Configure o registro do ID de transação global (GTID) definindo o GTID_MODE como ON ou OFF. O valor GTID_MODE de ON_PERMISSIVE não é compatível.

   O valor que você precisa usar depende dos requisitos da migração:

   • Se você migrar para uma instância de destino atual 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 de ID global da transação.

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 otimizar o 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 da 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 da 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 otimizar o 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 da 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 da conta de usuário do MySQL.

8. Antes de configurar os registros binários, verifique se você:
   • Ative os registros binários no banco de dados de origem.
   • Use a geração de registros binários baseados em linha.
   • Retenha registros binários por um período suficiente para oferecer suporte à migração do banco de dados. Geralmente, uma semana é suficiente.

   Para configurar registros binários, expanda 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 Azure para MySQL

   A geração de registros binários é ativada por padrão no Microsoft Azure Database 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 como um período longo o suficiente para oferecer suporte à migração do banco de dados.

      Para mais informações, consulte Configurar parâmetros de 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 servidor para que as mudanças feitas entrem em vigor.

   Amazon RDS

   Para o Amazon RDS, defina a configuração baseada em linhas 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 arquivos de registro binário.

   Para definir o período de armazenamento dos 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 para 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 mudanças 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 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 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 o bug nº 43439 do MySQL.

11. Somente para fontes 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.