Configurar o banco de dados MySQL de origem para migrações contínuas

Nesta página, descrevemos como configurar as seguintes instâncias de banco de dados de origem para migrações homogêneas contínuas do MySQL:

Configurar uma origem do Cloud SQL para MySQL

Para configurar uma instância de origem do Cloud SQL para MySQL no processo de migração, faça o seguinte:

  1. Verifique se o banco de dados de origem contém metadados definidos por usuários com a cláusula DEFINER. Consulte Verificar metadados com uma cláusula DEFINER.

    O Database Migration Service para migrações homogêneas do MySQL não migra contas de usuário e logins. As origens que contêm metadados definidos por contas de usuário com a cláusula DEFINER podem bloquear sua migração.

  2. 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 Unknown table in system schema .

  3. Ative e configure os registros binários no banco de dados de origem.

    No Cloud SQL para MySQL, a geração de registros binários é ativada automaticamente quando você usa a recuperação pontual (PITR). É possível configurar o formato do registro e o período de armazenamento com as flags de sistema disponíveis no Cloud SQL. Faça o seguinte:

    1. Ative a PITR na instância. Esse recurso ativa automaticamente a geração de registros binários. Não é possível ativar a geração de registros binários sem a PITR no Cloud SQL. Consulte Recuperação pontual (PITR) na documentação do Cloud SQL.
    2. Use flags do Cloud SQL para ajustar a configuração de geração de registros. Para mais detalhes, consulte Configurar flags de banco de dados na documentação do Cloud SQL.
      1. O Database Migration Service requer que binlog_format seja definido como ROW. Não é necessário ajustar essa configuração, o Cloud SQL para MySQL define automaticamente a flag binlog_format como ROW.
      2. Defina o período de armazenamento de registros como um período longo o suficiente para dar suporte à migração do banco de dados. Geralmente, uma semana é suficiente. Use uma das seguintes flags:
        • MySQL 5.6 - 5.7: expire_logs_days
        • MySQL 8.0 e mais recentes: expire_logs_days, binlog_expire_logs_seconds

  4. Crie uma conta de usuário de migração dedicada na instância. Consulte Criar um usuário na documentação do Cloud SQL. Verifique se as seguintes condições foram atendidas:

    • Você permite que a conta de usuário dedicada se conecte de qualquer host (host=%).
    • A senha da conta não pode ter mais de 32 caracteres. Para mais informações sobre as limitações de tamanho da senha do usuário do MySQL, consulte o bug do MySQL nº 43439.

  5. Atribua os privilégios necessários à conta de usuário de migração dedicada. Para migrações contínuas, a lista completa de privilégios necessários depende de você fornecer seus próprios arquivos dump ou usar o recurso de dump gerenciado do Database Migration Service:

    Dump gerenciado

    Se você quiser que o Database Migration Service faça automaticamente o despejo completo do seu banco de dados de origem, atribua os seguintes privilégios à conta de usuário:

    Despejo manual

    Se você fornecer seus próprios arquivos dump criados com mysqldump, será necessário fornecer os privilégios necessários para a fase do CDC:

Configurar uma origem do MySQL auto-hospedada

Para configurar uma instância de origem do MySQL autohospedada para o processo de migração, faça o seguinte:

  1. Verifique se todas as tabelas (exceto as tabelas em bancos de dados do sistema) usam o mecanismo de armazenamento InnoDB. Se você usar um mecanismo de armazenamento diferente, talvez seja necessário converter as tabelas. Para mais informações, consulte Como converter tabelas do MyISAM para o InnoDB.
  2. Verifique se o banco de dados de origem contém metadados definidos por usuários com a cláusula DEFINER. Consulte Verificar metadados com uma cláusula DEFINER.

    O Database Migration Service para migrações homogêneas do MySQL não migra contas de usuário e logins. Fontes que contêm metadados definidos por contas de usuário com a cláusula DEFINER podem bloquear sua migração.

  3. 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 Unknown table in system schema .

  4. Configure a definição server-id com um valor de 1 ou maior. Para mais informações, consulte Opções e variáveis de replicação e geração de registros binários.

  5. Verifique se GTID_MODE está definido como ON ou OFF. Nenhum outro valor é aceito.

    O Database Migration Service exige que GTID_MODE seja definido como ON nos seguintes cenários:

    Para mais informações sobre GTID_MODE, consulte Variável de sistema de ID da transação global.

  6. Ative e configure os registros binários no banco de dados de origem. Faça o seguinte:

  7. Crie uma conta de usuário de migração dedicada na instância. Consulte Declarações de gerenciamento de contas. Verifique se as seguintes condições foram atendidas:

    • Você permite que a conta de usuário dedicada se conecte de qualquer host (host=%).
    • A senha da conta não tem mais de 32 caracteres. Para mais informações sobre as limitações de comprimento de senha de usuário do MySQL, consulte Bug do MySQL nº 43439.

  8. Atribua os privilégios necessários à conta de usuário de migração dedicada. Para migrações contínuas, a lista completa de privilégios necessários depende de você fornecer seus próprios arquivos dump ou usar o recurso de dump gerenciado do Database Migration Service:

    Dump gerenciado

    Se você quiser que o Database Migration Service faça automaticamente o despejo completo do banco de dados de origem, atribua os seguintes privilégios à conta de usuário:

    Despejo manual

    Se você fornecer seus próprios arquivos dump criados com mysqldump, será necessário fornecer os privilégios exigidos para a fase de CDC:

Configurar uma origem do Amazon RDS para MySQL

Para configurar uma instância de origem do Amazon RDS para MySQL no processo de migração, faça o seguinte:

  1. O Amazon RDS para MySQL usa o mecanismo de armazenamento InnoDB por padrão, mas permite o uso de outros mecanismos de armazenamento. Verifique se todas as suas tabelas (exceto as tabelas em bancos de dados do sistema) usam o mecanismo de armazenamento InnoDB. Se você usa um mecanismo de armazenamento diferente, talvez seja necessário converter as tabelas. Para mais informações, consulte Como converter tabelas do MyISAM para o InnoDB.
  2. Verifique se o banco de dados de origem contém metadados definidos por usuários com a cláusula DEFINER. Consulte Verificar metadados com uma cláusula DEFINER.

    O Database Migration Service para migrações homogêneas do MySQL não migra contas de usuário e logins. As origens que contêm metadados definidos por contas de usuário com a cláusula DEFINER podem bloquear sua migração.

  3. 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 Unknown table in system schema .

  4. Verifique se GTID_MODE está definido como ON ou OFF. Nenhum outro valor é aceito. O Amazon RDS para MySQL usa GTID_MODE = OFF por padrão.

    O Database Migration Service exige que GTID_MODE seja definido como ON nos seguintes cenários:

    Para mais informações sobre GTID_MODE, consulte Variável de sistema de ID da transação global.

  5. Verifique e configure os registros binários no banco de dados de origem. Faça o seguinte:

    1. Verifique se a instância usa backups automatizados. O Amazon RDS gera registros binários somente quando os backups automatizados estão ativados. Para mais informações, consulte Como ativar backups automatizados na documentação do Amazon RDS.

    2. Defina o período de armazenamento de registros como um período longo o suficiente para dar suporte à migração do banco de dados. Geralmente, uma semana é suficiente. Consulte Definir e mostrar a configuração do registro binário na documentação do Amazon RDS.

    3. Reinicie o servidor para que as mudanças feitas entrem em vigor.

  6. Crie uma conta de usuário de migração dedicada na instância. Consulte Extratos de gerenciamento da conta. Verifique se as seguintes condições foram atendidas:

    • Você permite que a conta de usuário dedicada se conecte de qualquer host (host=%).
    • A senha da conta não tem mais de 32 caracteres. Para mais informações sobre as limitações de comprimento de senha de usuário do MySQL, consulte Bug do MySQL nº 43439.

  7. Atribua os privilégios necessários à conta de usuário de migração dedicada. Para migrações contínuas, a lista completa de privilégios necessários depende de você fornecer seus próprios arquivos dump ou usar o recurso de despejo gerenciado do Database Migration Service:

    Dump gerenciado

    Se você quiser que o Database Migration Service faça automaticamente o despejo completo do banco de dados de origem, atribua os seguintes privilégios à conta de usuário:

    Despejo manual

    Se você fornecer seus próprios arquivos dump criados com mysqldump, será necessário fornecer os privilégios exigidos para a fase de CDC:

Configurar uma origem do Amazon Aurora para MySQL

Para configurar uma instância de origem do Amazon Aurora para MySQL no processo de migração, faça o seguinte:

  1. Verifique se o banco de dados de origem contém metadados definidos por usuários com a cláusula DEFINER. Consulte Verificar metadados com uma cláusula DEFINER.

    O Database Migration Service para migrações homogêneas do MySQL não migra contas de usuário e logins. As origens que contêm metadados definidos por contas de usuário com a cláusula DEFINER podem bloquear sua migração.

  2. Se o banco de dados de origem tiver objetos que referenciam tabelas nos esquemas do sistema mysql, performance_schema, information_schema, ndbinfo ou sys, verifique se os bancos de dados de réplica também tê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 Unknown table in system schema .

  3. Verifique se GTID_MODE está definido como ON ou OFF. Nenhum outro valor é aceito. O Amazon Aurora para MySQL usa GTID_MODE = OFF por padrão.

    O Database Migration Service exige que GTID_MODE seja definido como ON nos seguintes cenários:

    Para mais informações sobre GTID_MODE, consulte Variável de sistema de ID da transação global.

  4. Ative e configure os registros binários no banco de dados de origem. Faça o seguinte:

    1. Ative a geração de registros binários para seu banco de dados MySQL.

    2. Defina o período de armazenamento de registros como um período longo o suficiente para dar suporte à migração do banco de dados. Geralmente, uma semana é suficiente. Consulte Como definir e mostrar a configuração do registro binário.

    3. Reinicie o servidor para que as mudanças feitas entrem em vigor.

  5. Crie uma conta de usuário de migração dedicada na instância. Consulte Extratos de gerenciamento da conta. Verifique se as seguintes condições foram atendidas:

    • Você permite que a conta de usuário dedicada se conecte de qualquer host (host=%).
    • A senha da conta não tem mais de 32 caracteres. Para mais informações sobre as limitações de comprimento de senha de usuário do MySQL, consulte Bug do MySQL nº 43439.

  6. Atribua os privilégios necessários à conta de usuário de migração dedicada. Para migrações contínuas, a lista completa de privilégios necessários depende de você fornecer seus próprios arquivos dump ou usar o recurso de despejo gerenciado do Database Migration Service:

    Dump gerenciado

    Se você quiser que o Database Migration Service faça automaticamente o despejo completo do banco de dados de origem, atribua os seguintes privilégios à conta de usuário:

    Dump manual

    Se você fornecer seus próprios arquivos dump criados com mysqldump, será necessário fornecer os privilégios necessários para a fase do CDC:

Configurar uma fonte do Microsoft Azure Database para MySQL

Para configurar uma instância de origem do Microsoft Azure Database para MySQL no processo de migração, faça o seguinte:

  1. Verifique se o banco de dados de origem contém metadados definidos por usuários com a cláusula DEFINER. Consulte Verificar metadados com uma cláusula DEFINER.

    O Database Migration Service para migrações homogêneas do MySQL não migra contas de usuário e logins. As origens que contêm metadados definidos por contas de usuário com a cláusula DEFINER podem bloquear sua migração.

  2. 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 Unknown table in system schema .

  3. Verifique se GTID_MODE está definido como ON ou OFF. Nenhum outro valor é aceito. O Microsoft Azure Database para MySQL usa GTID_MODE = OFF por padrão.

    O Database Migration Service exige que GTID_MODE seja definido como ON nos seguintes cenários:

    Para mais informações sobre GTID_MODE, consulte Variável de sistema de ID da transação global.

  4. Verifique e configure as configurações de geração de registros binários no banco de dados de origem. Faça o seguinte:

    1. A geração de registros binários é ativada por padrão no Microsoft Azure Database para MySQL. Não é necessário ativá-lo, mas confirme se o recurso está ativado. Para mais informações, consulte a documentação da Microsoft.

    2. Defina binlog_expire_logs_seconds como um período longo o suficiente para dar suporte à migração do banco de dados. Em geral, uma semana é suficiente.

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

    3. Reinicie o servidor para que as alterações feitas entrem em vigor.

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

  6. Crie uma conta de usuário de migração dedicada na instância. Consulte Declarações de gerenciamento de contas. Verifique se as seguintes condições foram atendidas:

    • Você permite que a conta de usuário dedicada se conecte de qualquer host (host=%).
    • A senha da conta não tem mais de 32 caracteres. Para mais informações sobre as limitações de tamanho da senha do usuário do MySQL, consulte o bug do MySQL nº 43439.

  7. Atribua os privilégios necessários à conta de usuário de migração dedicada. Para migrações contínuas, a lista completa de privilégios necessários depende de você fornecer seus próprios arquivos dump ou usar o recurso de despejo gerenciado do Database Migration Service:

    Dump gerenciado

    Se você quiser que o Database Migration Service faça automaticamente o despejo completo do seu banco de dados de origem, atribua os seguintes privilégios à conta de usuário:

    Despejo manual

    Se você fornecer seus próprios arquivos dump criados com mysqldump, será necessário fornecer os privilégios exigidos para a fase de CDC:

A seguir

Para um tutorial completo e detalhado sobre migrações homogêneas do Cloud SQL para MySQL, consulte Primeiros passos com as migrações do Cloud SQL para MySQL.