Tutorial: Migrar o Banco de Dados do Azure para MySQL – Servidor Único para Servidor Flexível online usando DMS por meio do portal do Azure

Observação

Este artigo contém referências ao termo servidor subordinado, um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Você pode migrar uma instância do Banco de Dados do Azure para MySQL – Servidor Único para o Banco de Dados do Azure para MySQL – Servidor Flexível usando o DMS (Serviço de Migração de Banco de Dados) do Azure, um serviço totalmente gerenciado projetado para habilitar migrações contínuas de várias fontes de banco de dados para plataformas de dados do Azure. Neste tutorial, executaremos uma migração online de um banco de dados de exemplo de um servidor de Banco de Dados do Azure para MySQL único para um servidor flexível do MySQL (ambos executando a versão 5.7) usando uma atividade de migração do DMS.

Observação

A migração online do DMS já está em disponibilidade geral. O DMS suporta a migração para as versões 5.7 e 8.0 do MySQL e também suporta a migração de servidores MySQL de versões inferiores (v5.6 e superiores) para servidores de versões superiores. Além disso, o DMS dá suporte a migrações entre regiões, entre grupos de recursos e entre assinaturas, para que você possa selecionar uma região, um grupo de recursos e uma assinatura para o servidor de destino que seja diferente do que é especificado para o servidor de origem.

Neste tutorial, você aprenderá a:

• Implemente as melhores práticas para criar um servidor flexível para carregamentos de dados mais rápidos usando o DMS.
• Criar e configurar um servidor flexível de destino.
• Crie uma instância do DMS.
• Crie um projeto de migração do MySQL no DMS.
• Migre um esquema do MySQL usando DMS.
• Executar a migração.
• Monitorar a migração.
• Execute as etapas pós-migração.
• Implemente as melhores práticas para executar uma migração.

Pré-requisitos

Para concluir este tutorial, você precisará:

• Crie ou use uma instância existente do Banco de Dados do Azure para MySQL – Servidor Único (o servidor de origem).
• Para concluir a migração online com êxito, certifique-se de que os seguintes pré-requisitos estejam em vigor:
  • Use a ferramenta de linha de comando do MySQL de sua escolha para verificar se o log_bin está habilitado no servidor de origem executando o comando: MOSTRAR VARIÁVEIS COMO "log_bin". Se log_bin não estiver habilitado, habilite antes de iniciar a migração.
  • Verifique se o usuário tem as permissões "REPLICATION CLIENT" e "REPLICATION SLAVE" no servidor de origem para ler e aplicar o log de compartimentos.
  • Se você estiver segmentando uma migração online, configure o parâmetro binlog_expire_logs_seconds no servidor de origem para garantir que os arquivos binlog não sejam eliminados antes que a réplica confirme as alterações. Recomendamos pelo menos dois dias para começar. Após a substituição bem-sucedida, você pode redefinir o valor.
• Para concluir uma migração de esquema com êxito, no servidor de origem, o usuário que executa a migração exige os seguintes privilégios:
  • Privilégio "SELECT" no nível do servidor na origem.
  • Se estiver migrando exibições, o usuário precisará ter o privilégio "SHOW VIEW" no servidor de origem e o privilégio "CREATE VIEW" no servidor de destino.
  • Se estiver migrando gatilhos de eventos, o usuário precisará ter o privilégio "TRIGGER" no servidor de origem e de destino.
  • Se estiver migrando rotinas (procedimentos e/ou funções), o usuário precisará ter os privilégios "CREATE ROUTINE" e "ALTER ROUTINE" concedidos no nível do servidor no destino.
  • Se estiver migrando eventos, o usuário precisará ter o privilégio "EVENT" no servidor de origem e de destino.
  • Se estiver migrando usuários/logons, o usuário precisará ter o privilégio "CREATE USER" no servidor de destino.
  • Privilégio "DROP" no nível do servidor no destino, a fim de remover tabelas que já podem existir. Por exemplo, ao tentar novamente fazer uma migração.
  • Privilégio "REFERENCES" no nível do servidor no destino, a fim de criar tabelas com chaves estrangeiras.
  • Se estiver migrando para o MySQL 8.0, o usuário precisará ter o privilégio "SESSION_VARIABLES_ADMIN" no servidor de destino.
  • Privilégio "CREATE" no nível do servidor no destino.
  • Privilégio "INSERT" no nível do servidor no destino.
  • Privilégio "UPDATE" no nível do servidor no destino.
  • Privilégio "DELETE" no nível do servidor no destino.

Limitações

Enquanto você se prepara para a migração, considere as limitações a seguir.

• Ao migrar objetos que não são de tabela, o DMS não dá suporte à renomeação de bancos de dados.
• Ao migrar para um servidor de destino com bin_log habilitado, habilite log_bin_trust_function_creators para permitir a criação de rotinas e gatilhos.
• Atualmente, o DMS não dá suporte à migração da cláusula DEFINER para objetos. Todos os tipos de objeto com definidores na origem são descartados e, após a migração, o definidor padrão para todos os objetos que suportam uma cláusula definidora e que são criados durante a migração do esquema será definido para o logon usado para executar a migração.
• Atualmente, o DMS dá suporte apenas à migração de um esquema como parte da movimentação de dados. Se nada for selecionado para movimentação de dados, a migração do esquema não ocorrerá. Observe que selecionar uma tabela para migração de esquema também a seleciona para movimentação de dados.
• O suporte à migração online é limitado ao formato de binlog ROW.
• A migração online agora dá suporte à replicação de instrução DDL ao migrar para um servidor de destino do servidor flexível do Banco de Dados do Azure para MySQL v8.0 ou v5.7.
  • A replicação de instrução tem suporte para bancos de dados, tabelas e objetos de esquema (exibições, rotinas, gatilhos) selecionados para migração de esquema ao configurar uma atividade de migração do DMS do Azure. As instruções de definição e administração de dados para bancos de dados, tabelas e objetos de esquema que não estão selecionados não serão replicadas. Selecionar um servidor inteiro para migração replicará instruções para tabelas, bancos de dados e objetos de esquema criados no servidor de origem após a conclusão da carga inicial.
  • A replicação de instrução DMS do Azure dá suporte a todas as instruções de Definição de Dados listadas aqui, com exceção dos seguintes comandos: • instruções LOGFILE GROUP • Instruções SERVER • instruções SPATIAL REFERENCE SYSTEM • instruções TABLESPACE
  • A replicação de instrução do DMS do Azure dá suporte a todas as instruções de Administração de Dados – Gerenciamento de Contas listadas aqui, com exceção dos seguintes comandos:
    • SET DEFAULT ROLE
    • SET PASSWORD
  • A replicação de instrução do DMS do Azure dá suporte a todas as instruções de Administração de Dados – Manutenção de Tabela listadas aqui, com exceção dos seguintes comandos:
    • REPAIR TABLE
    • ANALYZE TABLE
    • CHECKSUM TABLE

Melhores práticas para criar um servidor flexível para carregamentos de dados mais rápidos usando o DMS

O DMS dá suporte a migrações entre regiões, entre grupos de recursos e entre assinaturas, portanto, você é livre para selecionar a região, o grupo de recursos e a assinatura apropriados para o seu servidor flexível de destino. Antes de criar o seu servidor flexível de destino, considere as diretrizes de configuração a seguir para ajudar a garantir carregamentos de dados mais rápidos usando o DMS.

• Selecione o tamanho da computação e a camada de computação para o servidor flexível de destino com base no tipo de preço e nos VCores do servidor único de origem com base nos detalhes da tabela a seguir.

  Tipo de preço do servidor único	VCores do servidor único	Tamanho da computação do servidor flexível	Camada de computação do servidor flexível
  Básico*	1	Uso Geral	Standard_D16ds_v4
  Básico*	2	Uso Geral	Standard_D16ds_v4
  Uso geral*	4	Uso Geral	Standard_D16ds_v4
  Uso geral*	8	Uso Geral	Standard_D16ds_v4
  Uso Geral	16	Uso Geral	Standard_D16ds_v4
  Uso Geral	32	Uso Geral	Standard_D32ds_v4
  Uso Geral	64	Uso Geral	Standard_D64ds_v4
  Otimizado para memória	4	Comercialmente Crítico	Standard_E4ds_v4
  Otimizado para memória	8	Comercialmente Crítico	Standard_E8ds_v4
  Otimizado para memória	16	Comercialmente Crítico	Standard_E16ds_v4
  Otimizado para memória	32	Comercialmente Crítico	Standard_E32ds_v4

* Para a migração, selecione computação de Uso Geral de 16 vCores para o servidor flexível de destino para migrações mais rápidas. Volte para o tamanho de computação desejado para o servidor de destino após a conclusão da migração seguindo a recomendação de tamanho de computação na seção Executar atividades de pós-migração posteriormente neste artigo.

• A versão do MySQL para o servidor flexível de destino deve ser maior ou igual à do servidor único de origem.
• A menos que você precise implantar o servidor flexível de destino em uma zona específica, defina o valor do parâmetro Zona de Disponibilidade como ‘Sem preferência’.
• Para conectividade de rede, na guia Rede, se o servidor único de origem tiver pontos de extremidade privados ou links privados configurados, selecione Acesso Privado; caso contrário, selecione Acesso Público.
• Copie todas as regras de firewall do servidor único de origem para o servidor flexível de destino.
• Copie todas as marcas de nome/valor do servidor único para o flexível durante a própria criação.

Criar e configurar o servidor flexível de destino

Com essas melhores práticas em mente, crie o seu servidor flexível de destino e configure-o.

• Crie o servidor flexível de destino. Para obter etapas guiadas, consulte o guia de início rápido Criar um servidor flexível do Banco de Dados do Azure para MySQL.
• Configurar o novo servidor flexível de destino da seguinte maneira:
  • O usuário que executa a migração exige as seguintes permissões:
    • Verifique se o usuário tem a permissão "REPLICATION_APPLIER" ou "BINLOG_ADMIN" no servidor de destino para aplicar o log de compartimentos.
    • Verifique se o usuário tem a permissão "REPLICATION SLAVE" no servidor de destino.
    • Verifique se o usuário tem as permissões "REPLICATION CLIENT" e "REPLICATION SLAVE" no servidor de origem para ler e aplicar o log de compartimentos.
    • Para criar tabelas no destino, o usuário deve ter o privilégio "CREATE".
    • Se estiver migrando uma tabela com opções de partição "DATA DIRECTORY" ou "INDEX DIRECTORY", o usuário deverá ter o privilégio "FILE".
    • Se estiver migrando para uma tabela com uma opção "UNION", o usuário deverá ter os privilégios "SELECT", "UPDATE" e "DELETE" para as tabelas mapeadas para uma tabela MERGE.
    • Se estiver migrando exibições, você deverá ter o privilégio "CREATE VIEW". Tenha em mente que alguns privilégios podem ser necessários dependendo do conteúdo das exibições. Consulte os documentos do MySQL específicos da sua versão em "INSTRUÇÃO CREATE VIEW." para obter detalhes.
    • Se estiver migrando eventos, o usuário deverá ter o privilégio "EVENT".
    • Se estiver migrando gatilhos, o usuário deverá ter o privilégio "TRIGGER".
    • Se estiver migrando rotinas, o usuário deverá ter o privilégio "CREATE ROUTINE".
  • Configure os parâmetros do servidor no servidor flexível de destino da seguinte maneira:
    • Defina a versão do TLS e o parâmetro do servidor require_secure_transport para corresponder aos valores no servidor de origem.
    • Defina o parâmetro do servidor sql_mode para corresponder aos valores no servidor de origem.
    • Configure parâmetros de servidor no servidor de destino para corresponder a quaisquer valores não padrão usados no servidor de origem.
    • Para garantir carregamentos de dados mais rápidos ao usar o DMS, configure os parâmetros de servidor a seguir conforme descrito.
      • max_allowed_packet – defina como 1073741824 (ou seja, 1 GB) para evitar problemas de conexão devido a linhas longas.
      • slow_query_log – defina como OFF para desativar o log de consultas lentas. Isso eliminará a sobrecarga causada pelo log de consulta lento durante cargas de dados.
      • innodb_buffer_pool_size – só pode ser aumentado escalando verticalmente a computação para o servidor do Banco de Dados do Azure para MySQL. Escale verticalmente o servidor para SKU de 64 vCores para Uso Geral do tipo de preço do portal durante a migração para aumentar o tamanho do innodb_buffer_pool_size.
      • innodb_io_capacity & innodb_io_capacity_max – altere para 9.000 dos Parâmetros do servidor no portal do Azure a fim de melhorar a utilização de E/S para otimizar a velocidade de migração.
      • innodb_write_io_threads – Altere para 4 nos Parâmetros do servidor no portal do Azure para aprimorar a velocidade da migração.
  • Configure as réplicas no servidor de destino para corresponder às do servidor de origem.
  • Replique as seguintes funcionalidades de gerenciamento de servidor do servidor único de origem para o servidor flexível de destino:
    • Atribuições de função, Funções, Atribuições de negação, administradores clássicos, Controle de Acesso (IAM)
    • Bloqueios (somente leitura e exclusão)
    • Alertas
    • Tarefas
    • Alertas de Resource Health

Configurar o DMS

Com o servidor flexível de destino implantado e configurado, você precisará configurar o DMS para migrar o seu servidor único para um servidor flexível.

Registre o provedor de recursos

Para registrar o provedor de recursos Microsoft.DataMigration, execute as etapas a seguir.

1. Antes de criar sua primeira instância de DMS, entre no portal do Azure e, em seguida, pesquise e selecione Assinaturas.

2. Selecione a assinatura que deseja usar para criar a instância do DMS e então selecione Provedores de recursos.

3. Pesquise o termo "migração" e, em seguida, para Microsoft.DataMigration, selecione Registrar.

Criar uma instância do DMS (Serviço de Migração de Banco de Dados)

1. No portal do Azure, selecione + Criar um recurso, pesquise o termo "Serviço de Migração de Banco de Dados do Azure" e, em seguida, selecione Serviço de Migração de Banco de Dados do Azure na lista suspensa.

2. Na tela Serviço de Migração de Banco de Dados do Azure, selecione Criar.

3. Na página Selecionar cenário de migração e Serviço de Migração de Banco de Dados, em Cenário de Migração, selecione Banco de Dados do Azure para MySQL – Servidor Único como o tipo de servidor de origem e selecione Banco de Dados do Azure para MySQL como tipo de servidor de destino e selecione Selecionar.

4. Na página Criar Serviço de Migração, na guia Básico, em detalhes do Projeto, selecione a assinatura apropriada e selecione um grupo de recursos existente ou crie um novo.

5. Em Detalhes da Instância, especifique um nome para o serviço, selecione uma região e verifique se o Azure está selecionado como o modo de serviço.

6. À direita do Tipo de preço, selecione Configurar camada.

7. Na página Configurar, selecione o tipo de preço Premium com quatro vCores para a instância do DMS e clique em Aplicar. O DMS Premium de quatro vCores é gratuito por seis meses (183 dias) a partir da data de criação do serviço DMS antes de incorrer em encargos. Para obter mais informações sobre os custos e tipos de preços do DMS, confira a página de preços.

   Em seguida, precisamos especificar a VNet que fornecerá à instância do DMS acesso ao servidor único de origem e ao servidor flexível de destino.

8. Na página Criar Serviço de Migração, selecione Avançar: Rede >>.

9. Na guia Rede, selecione uma VNet existente na lista ou forneça o nome da nova VNet a ser criada e selecione Examinar + Criar. Para obter mais informações, confira o artigo Criar uma rede virtual usando o portal do Azure.

   Importante

   Sua VNet deve ser configurada com acesso ao servidor único de origem e ao servidor flexível de destino, portanto, não se esqueça de:

   • Crie uma regra de firewall no nível de servidor ou configure pontos de extremidade de serviço da VNET para os servidores de origem e de destino do Banco de Dados do Azure para MySQL para permitir que a VNet do Serviço de Migração de Banco de Dados do Azure tenha acesso aos bancos de dados de origem e de destino.
   • Verifique se as regras do NSG (grupo de segurança de rede) da sua VNet não bloqueiam a porta de saída 443 de ServiceTag para ServiceBus, Storage e Azure Monitor. Para obter mais informações sobre a filtragem de tráfego do NSG da VNet, confira Filtrar o tráfego de rede com os grupos de segurança de rede.

   Observação

   Para adicionar marcas ao serviço, avance para a guia Marcas selecionando Avançar: marcas. Adicionar marcas ao serviço é opcional.

10. Navegue até a guia Examinar + criar, examine as configurações, exiba os termos e selecione Criar.

    A implantação da sua instância do DMS começa agora. A mensagem A implantação está em andamento aparece por alguns minutos e, em seguida, a mensagem muda para Sua implantação foi concluída.

11. Selecione Ir para o recurso.

12. Identifique o endereço IP da instância do DMS na página de visão geral do recurso e crie uma regra de firewall para o servidor único de origem e o servidor flexível de destino, colocando o endereço IP da instância do DMS na lista de permissões.

Criar um projeto de migração

Para criar um projeto de migração, execute as etapas a seguir.

1. Faça logon no portal do Azure, selecione + criar um recurso, procure o serviço de migração de banco de dados do Azure e, em seguida, selecione serviço de migração de banco de dados do Azure na lista suspensa.

   

2. Nos resultados da pesquisa, selecione a instância do DMS que você criou e escolha + Novo Projeto de Migração.

   

3. Na página Novo projeto de migração, especifique um nome para o projeto, na caixa de seleção Tipo de servidor de origem, selecione Banco de dados do Azure para MySQL – Servidor Único , na caixa de seleção Tipo de servidor de destino, selecione Banco de dados do Azure para MySQL - Servidor Flexível , na caixa de seleção Tipo de atividade de migração, selecione Migração de dados online e selecione Criar e executar atividade.

   Observação

   Selecionar Apenas criar projeto como o tipo de atividade de migração só criará o projeto de migração; você pode executar o projeto de migração posteriormente.

   

Configurar o projeto de migração

Para configurar o projeto de migração do DMS, execute as etapas a seguir.

1. Na tela Selecionar origem, localize o servidor com base na assinatura, localização e grupo de recursos. O nome de usuário é preenchido automaticamente e, em seguida, forneça a senha do servidor de origem.

2. Selecione Avançar : Selecionar destino>> e, na tela Selecionar destino, localize o servidor com base na assinatura, localização e grupo de recursos. O nome do usuário é preenchido automaticamente e, em seguida, forneça a senha para o servidor flexível de destino.

3. Selecione Avançar : Selecionar bancos de dados>> e, na guia Selecionar bancos de dados, em Opções de migração do servidor, selecione Migrar todos os bancos de dados aplicáveis ou em Selecionar bancos de dados selecione os objetos do servidor que você deseja migrar.

   Observação

   Agora existe uma opção Migrar todos os bancos de dados aplicáveis quando selecionada, essa opção migrará todos os bancos de dados e tabelas criados pelo usuário. Observe que, como o Banco de Dados do Azure para MySQL - Servidor Flexível não tem suporte para bancos de dados de casos mistos, os bancos de dados de casos mistos na origem não serão incluídos para uma migração online.

4. Na seção Selecionar bancos de dados, em Banco de Dados de Origem, selecione os bancos de dados a serem migrados.

   Os objetos que não são de tabela nos bancos de dados especificados serão migrados, enquanto os itens que você não selecionou serão ignorados. Você só pode selecionar os bancos de dados de origem e de destino cujos nomes correspondem aos do servidor de origem e de destino. Se você selecionar um banco de dados no servidor de origem que não existe no servidor de destino, ele será criado no servidor de destino.

5. Selecione Avançar: selecione tabelas>> para navegar para a guia Selecionar tabelas.

   Antes que a guia seja preenchida, o DMS busca as tabelas dos bancos de dados selecionados na origem e no destino e, em seguida, determina se a tabela existe e contém dados.

6. Selecione as tabelas que deseja migrar.

   Se a tabela de origem selecionada não existir no servidor de destino, o processo de migração online garantirá que o esquema de tabela e os dados sejam migrados para o servidor de destino.

   O DMS valida as suas entradas e, se a validação for aprovada, você poderá iniciar a migração.

7. Depois de configurar a migração de esquema, selecione Examinar e iniciar a migração.

   Observação

   Você só precisa navegar até a guia Definir configurações de migração se estiver tentando solucionar problemas de migração com falha.

8. Na guia Resumo, na caixa de texto Nome da atividade, especifique um nome para a atividade de migração e examine o resumo para ter certeza de que os detalhes de origem e de destino correspondem ao que foi especificado anteriormente.

9. Selecione Iniciar migração.

   A janela de atividade de migração aparece e o Status da atividade está Inicializando. O Status é alterado para Em execução quando as migrações de tabela são iniciadas.

Monitorar a migração

1. Depois que a atividade de Carregamento Inicial for concluída, navegue até a guia Carregamento Inicial para exibir o status de conclusão e o número de tabelas concluídas.

   Depois que a atividade de Carregamento Inicial for concluída, você será direcionado automaticamente para a guia Replicar Alterações de Dados. Você pode monitorar o progresso da migração à medida que a tela é atualizada automaticamente a cada 30 segundos.

2. Selecione Atualizar para atualizar a exibição e exibir os segundos de atraso para a origem como e quando necessário.

   

3. Monitore os Segundos de atraso da origem e, assim que o valor ficar próximo de 0, prossiga para iniciar a substituição navegando até a guia do menu Iniciar Substituição na parte superior da tela de atividade de migração.

4. Siga as etapas na janela de substituição, antes de estar pronto para executar uma substituição.

5. Depois de concluir todas as etapas, selecione Confirmar e escolha Aplicar.

Executar as atividades pós-migração

Quando a migração for concluída, conclua as atividades pós-migração a seguir.

• Executar testes de integridade do aplicativo no banco de dados de destino para certificar a migração.

• Atualize a cadeia de conexão a fim de apontar para o novo servidor flexível.

• Exclua o servidor único de origem depois de garantir a continuidade do aplicativo.

• Se você escalou verticalmente o servidor flexível de destino para uma migração mais rápida, escale-o novamente selecionando o tamanho da computação e a camada de computação para o servidor flexível com base no tipo de preço e nos VCores do servidor único de origem, com base nos detalhes da tabela a seguir.

  Tipo de preço do servidor único	VCores do servidor único	Tamanho da computação do servidor flexível	Camada de computação do servidor flexível
  Basic	1	Com capacidade de intermitência	Standard_B1s
  Basic	2	Com capacidade de intermitência	Standard_B2s
  Uso Geral	4	Uso Geral	Standard_D4ds_v4
  Uso Geral	8	Uso Geral	Standard_D8ds_v4

• Para limpar os recursos do DMS, execute as seguintes etapas:

  1. Faça logon no portal do Azure, selecione + criar um recurso, procure o serviço de migração de banco de dados do Azure e, em seguida, selecione serviço de migração de banco de dados do Azure na lista suspensa.
  2. Selecione a instância de serviço de migração nos resultados da pesquisa e escolha Excluir serviço.
  3. Na caixa de diálogo de confirmação, na caixa de texto DIGITAR NOME DO SERVIÇO DE MIGRAÇÃO DE BANCO DE DADOS, especifique o nome da instância e escolha Excluir.

Práticas recomendadas de migração

Ao executar uma migração, não deixe de considerar as melhores práticas a seguir.

• Como parte da descoberta e avaliação, use a SKU do servidor, o uso da CPU, o armazenamento, os tamanhos de banco de dados e o uso de extensões como alguns dos dados críticos para ajudar nas migrações.
• Execute migrações de teste antes de migrar para produção:
  • As migrações de teste são importantes para garantir que você abranja todos os aspectos da migração de banco de dados, incluindo testes de aplicativo. A melhor prática é começar executando uma migração inteiramente para fins de teste. Depois que uma migração recém-iniciada entrar na fase de Replicação de Alterações de Dados com atraso mínimo, use apenas o destino do Servidor Flexível para executar cargas de trabalho de teste. Use esse destino para testar o aplicativo a fim de garantir o desempenho e os resultados esperados. Se você estiver migrando para uma versão superior do MySQL, teste a compatibilidade do aplicativo.
  • Depois que o teste for concluído, você poderá migrar os bancos de dados de produção. Neste ponto, você precisa finalizar o dia e a hora da migração de produção. O ideal é que haja baixo uso do aplicativo no momento. Todos os stakeholders que precisam estar envolvidos devem estar disponíveis e prontos. A migração de produção exige um monitoramento próximo. Para uma migração online, a replicação precisa ser concluída antes de você executar a substituição, a fim de evitar a perda de dados.
• Redirecione todos os aplicativos dependentes para acessar o novo banco de dados principal e tornar o servidor de origem somente leitura. Em seguida, abra os aplicativos para uso em produção.
• Depois que o aplicativo começar a ser executado no servidor flexível de destino, monitore com atenção o desempenho do banco de dados para ver se o ajuste de desempenho é necessário.

Próximas etapas

• Para obter informações sobre Banco de Dados do Azure para MySQL – Servidor Flexível, confira Visão geral – Banco de Dados do Azure para MySQL Servidor Flexível.
• Para obter informações sobre o Serviço de Migração de Banco de Dados do Azure, confira O que é o Serviço de Migração de Banco de Dados do Azure?.
• Para obter informações sobre problemas e limitações conhecidos ao migrar para o Banco de Dados do Azure para MySQL - Servidor Flexível usando DMS, confira Problemas Conhecidos com Migrações para o Banco de Dados do Azure para MySQL - Servidor Flexível.
• Para obter informações sobre limitações e problemas conhecidos ao executar migrações usando o DMS, confira Problemas conhecidos – Serviço de Migração de Banco de Dados do Azure.
• Para solucionar problemas de conectividade de banco de dados de origem ao usar o DMS, confira o artigo Problemas ao se conectar com os bancos de dados de origem.