Migrar o Amazon RDS for MySQL para o Banco de Dados do Azure para MySQL usando replicação de entrada de dados

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 usar métodos como backup e restauração do MySQL, Exportação e Importação do MySQL Workbench ou o Serviço de Migração de Banco de Dados do Azure para migrar seus bancos de dados MySQL para o Banco de Dados do Azure para MySQL – Servidor Flexível. É possível migrar suas cargas de trabalho com o mínimo de indisponibilidade ao usar uma combinação de ferramentas de código aberto, como mysqldump ou a combinação de mydumper e myloader com o Data-in Replication.

A Data-in Replication é uma técnica que replica alterações de dados do servidor de origem para o servidor de destino com base no método de posição no arquivo de log binário. Nesse cenário, a instância do MySQL que opera como a origem (na qual as alterações de banco de dados se originam) grava atualizações e alterações como eventos no log binário. As informações no log binário são armazenadas em formatos de log diferentes de acordo com as alterações de banco de dados que estão sendo registradas. As réplicas são configuradas para ler o log binário da origem e executar os eventos do log no banco de dados local da réplica.

Configure a Replicação de dados no Banco de Dados do Azure para MySQL – Servidor Flexível para sincronizar dados de um servidor MySQL de origem para um servidor MySQL de destino. Você pode fazer um cutover seletivo dos seus aplicativos do banco de dados primário (ou banco de dados de origem) para o banco de dados de réplica (ou banco de dados de destino).

Consulte Migrar bancos de dados do Amazon Web Services para o Azure, que inclui cenários de migração de exemplo que podem corresponder ao seu caso de uso.

Neste tutorial, você aprenderá a configurar a replicação de entrada de dados (Data-in Replication) entre um servidor de origem que executa o Amazon Relational Database Service (RDS) para MySQL e um servidor de destino que executa o Banco de Dados do Azure para MySQL Flexible Server.

Considerações sobre o desempenho

Antes de começar este tutorial, considere as implicações de desempenho da localização e da capacidade do computador cliente que você usará para executar a operação.

Localização do cliente

Execute operações de despejo/restauração em um computador cliente inicializado na mesma localização que o servidor de banco de dados:

  • Para instâncias do Servidor Flexível do Banco de Dados do Azure para MySQL, o computador cliente deve estar na mesma rede virtual e zona de disponibilidade que o servidor de banco de dados de destino.
  • Para instâncias de banco de dados Amazon RDS de origem, a instância do cliente deve existir na mesma Amazon Virtual Private Cloud e na mesma zona de disponibilidade que o servidor do banco de dados de origem. No caso acima, é possível mover arquivos de despejo entre máquinas cliente usando protocolos de transferência de arquivo, como FTP ou SFTP, ou carregá-los no Armazenamento de Blobs do Azure. Para reduzir o tempo total de migração, compacte os arquivos antes de transferi-los.

Capacidade do cliente

Independentemente da localização, o computador cliente requer capacidade adequada de computação, de E/S e de rede para executar as operações solicitadas. As recomendações gerais são:

  • Se o despejo ou a restauração envolverem o processamento em tempo real de dados, por exemplo, compactação ou descompactação, escolha uma classe de instância com pelo menos um núcleo de CPU por thread de despejo/restauração.
  • Verifique se há largura de banda de rede suficiente disponível para a instância do cliente. Use tipos de instância que dão suporte para o recurso de rede acelerada. Para obter mais informações, confira a seção “Rede acelerada” no Guia de Rede de Máquina Virtual do Azure.
  • Verifique se a camada de armazenamento do computador cliente tem a capacidade esperada de leitura e gravação. Recomendamos que você use uma máquina virtual do Azure com o armazenamento SSD Premium.

Pré-requisitos

Para concluir este tutorial, você precisará:

  • Instale o mysqlclient no computador cliente para criar um arquivo de despejo e executar uma operação de restauração na instância de destino do Banco de Dados do Azure para MySQL – Servidor Flexível.

  • Em bancos de dados maiores, instale mydumper e myloader para despejo e restauração paralelos de bancos de dados.

    Observação

    Mydumper só pode ser executado em distribuições do Linux. Para obter mais informações, confira Como instalar o mydumper.

  • Crie uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL que execute a versão 5.7 ou 8.0.

    Importante

    Se o destino for o servidor flexível do Banco de Dados do Azure para MySQL com HA (Alta Disponibilidade) e redundância de zona, observe que a Replicação de Dados não tem suporte para essa configuração. Como solução, durante a criação do servidor, configure a HA com redundância de zona:

    1. Crie o servidor com a HA com redundância de zona habilitada.
    2. Desabilite a HA.
    3. Siga as instruções do artigo para configurar o Data-in Replication.
    4. Após a substituição, remova a configuração de Replicação de Dados.
    5. Habilite a HA.

Verifique se os vários parâmetros e recursos estão definidos e configurados corretamente, conforme descrito abaixo:

  • Por motivos de compatibilidade, os servidores de banco de dados de origem e de destino devem ter a mesma versão do MySQL.
  • Tenha uma chave primária em cada tabela. A falta de chaves primárias em tabelas pode deixar o processo de replicação mais lento.
  • Verifique se o conjunto de caracteres do banco de dados de origem e de destino são os mesmos.
  • Defina o parâmetro wait_timeout para um tempo razoável. O tempo depende da quantidade de dados ou da carga de trabalho que você deseja importar ou migrar.
  • Verifique se todas as tabelas usam InnoDB. O Servidor Flexível do Banco de Dados do Azure para MySQL dá suporte apenas ao mecanismo de armazenamento InnoDB.
  • Para tabelas grandes ou com muitos índices secundários, os efeitos da sobrecarga de desempenho ficam visíveis durante a restauração. Modifique os arquivos de despejo para que as instruções CREATE TABLE não incluam definições de chave secundárias. Depois de importar os dados, recrie os índices secundários para evitar a penalidade de desempenho durante o processo de restauração.

Por fim, para se preparar para a Replicação de Dados:

  • Verifique se a instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino pode se conectar-se ao servidor Amazon RDS para MySQL de origem pela porta 3306.
  • Certifique-se de que o servidor de origem Amazon RDS para MySQL permite o tráfego de entrada e saída na porta 3306.
  • Providencie conectividade site a site para o servidor de origem usando o Azure ExpressRoute ou o Gateway de VPN do Azure. Para obter mais informações sobre como criar redes virtuais, confira a documentação da Rede Virtual do Azure. Confira também os artigos de início rápido com detalhes passo a passo.
  • Configure os grupos de segurança de rede do seu servidor de banco de dados de origem para permitir o endereço IP do Servidor Flexível do Banco de Dados do Azure para MySQL de destino.

Importante

Se a instância de origem do Amazon RDS para MySQL tiver o GTID_mode definido como ON, a instância de destino do Banco de Dados do Azure para MySQL Servidor Flexível também deverá ter o GTID_mode definido como ON.

Configure a instância de destino do Banco de Dados do Azure para MySQL

Para configurar a instância de destino do Servidor Flexível do Banco de Dados do Azure para MySQL, que é o destino da Replicação de Dados:

  1. Defina o valor do parâmetro max_allowed_packet para o máximo de 1073741824, que é 1 GB. Esse valor impede qualquer problema de estouro relacionado a linhas longas.

  2. Defina os parâmetros slow_query_log, general_log, audit_log_enabled e query_store_capture_mode como OFF durante a migração para ajudar a eliminar sobrecargas relacionadas ao log de consulta.

  3. Aumente a capacidade de computação da instância de destino do Servidor Flexível do Banco de Dados do Azure para MySQL até o máximo de 64 vCores. Esse tamanho fornece mais recursos de computação ao restaurar o despejo de banco de dados do servidor de origem.

    Você sempre pode escalar de volta a computação para atender às demandas do aplicativo após a conclusão da migração.

  4. Aumente a capacidade de armazenamento para obter mais IOPS durante a migração ou aumente o limite máximo de IOPS para a migração.

    Observação

    A IOPS máxima disponível é determinada pelo tamanho da computação. Para obter mais informações, consulte a seção de IOPS em Opções de computação e armazenamento no Servidor Flexível do Banco de Dados do Azure para MySQL.

Configurar o servidor de origem Amazon RDS para MySQL

Para preparar e configurar o servidor MySQL hospedado no Amazon RDS, que é a origem da Data-in Replication:

  1. Confirme se o log binário está habilitado no Amazon RDS de origem para o servidor MySQL. Verifique se os backups automatizados estão habilitados ou certifique-se de que exista uma réplica de leitura para a instância de origem do Amazon RDS para MySQL.

  2. Certifique-se de que os arquivos de log binário no servidor de origem sejam mantidos até que as alterações sejam aplicadas na instância de destino do Servidor Flexível do Banco de Dados do Azure para MySQL.

    Com o Data-in Replication, o Banco de Dados do Azure para MySQL – Servidor Flexível não gerencia o processo de replicação.

  3. Para verificar a retenção dos logs binários no servidor Amazon RDS de origem e determinar por quantas horas eles são retidos, chame o procedimento armazenado mysql.rds_show_configuration:

    call mysql.rds_show_configuration;
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+
| name | value | description |
| +------------------------+-------+-----------------------------------------------------------------------------------------------------------+ |
| binlog retention hours | 24 | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
| source delay | 0 | source delay specifies replication delay in seconds between current instance and its master. |
| target delay | 0 | target delay specifies replication delay in seconds between current instance and its future read-replica. |
| +------------------------+------- +-----------------------------------------------------------------------------------------------------------+ |
| 3 rows in set (0.00 sec) |

  4. Para configurar o período de retenção de log binário, execute o procedimento armazenado rds_set_configuration para garantir que os logs binários sejam mantidos no servidor de origem pelo período desejado. Por exemplo:

    Call mysql.rds_set_configuration('binlog retention hours', 96);

    Quando você cria um despejo e faz uma restauração, o comando acima ajuda a acompanhar as alterações delta rapidamente.

    Observação

    Verifique se há espaço amplo em disco para armazenar os logs binários no servidor de origem, com base no período de retenção definido.

Há duas maneiras de gerar um dump de dados do servidor de origem do Amazon RDS for MySQL. Uma abordagem envolve gerar um dump de dados diretamente do servidor de origem. A outra abordagem é capturar um despejo em uma réplica de leitura do Amazon RDS para MySQL.

  • Para capturar um dump de dados diretamente do servidor de origem:

    1. Interrompa as gravações do aplicativo por alguns minutos para que o despejo de dados tenha consistência transacional.

      Também é possível definir temporariamente o parâmetro read_only para o valor 1 para que as operações de gravação não sejam processadas ao capturar um dump de dados.

    2. Depois de interromper as gravações no servidor de origem, colete o nome do arquivo de log binário e o deslocamento executando o comando Mysql> Show master status;.

    3. Salve esses valores para iniciar a replicação a partir da sua instância de Servidor Flexível do Banco de Dados do Azure para MySQL.

    4. Para criar um despejo dos dados, execute mysqldump com o seguinte comando:

      $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql

  • Se parar as gravações no servidor de origem não for uma opção ou se o desempenho de despejo de dados não for aceitável no servidor de origem, capture um despejo em um servidor de réplica:

    1. Crie uma réplica de leitura do Amazon MySQL com a mesma configuração do servidor de origem. Em seguida, crie o despejo na réplica.

    2. Deixe a réplica de leitura do Amazon RDS para MySQL acompanhar o servidor de origem do Amazon RDS para MySQL.

    3. Quando o atraso da réplica atingir 0 na réplica de leitura, pare a replicação chamando o procedimento armazenado mysql.rds_stop_replication.

      call mysql.rds_stop_replication;

    4. Com a replicação interrompida, conecte-se à réplica. Execute o comando SHOW SLAVE STATUS para recuperar o nome do arquivo de log binário atual do campo Relay_Master_Log_File e a posição do arquivo de log do campo Exec_Master_Log_Pos.

    5. Salve esses valores para iniciar a replicação a partir da sua instância de Servidor Flexível do Banco de Dados do Azure para MySQL.

    6. Para criar um despejo de dados da réplica de leitura do Amazon RDS para MySQL, execute mysqldump com o seguinte comando:

      $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql

    Observação

    Também é possível usar o mydumper para gerar um dump em paralelo dos dados do seu banco de dados de origem do Amazon RDS for MySQL. Para obter mais informações, confira Migrar grandes bancos de dados para o Servidor Flexível do Banco de Dados do Azure para MySQL usando mydumper/myloader.

  1. Para restaurar o banco de dados usando a restauração nativa do mysql, execute o seguinte comando:

    $ mysql -h <target_server> -u <targetuser> -p < dumpname.sql

    Observação

    Se, em vez disso, você estiver usando o myloader, consulte Migrar grandes bancos de dados para o Banco de Dados do Azure para MySQL Flexible Server usando mydumper/myloader.

  2. Entre no servidor de origem do Amazon RDS para MySQL e configure um usuário de replicação. Em seguida, conceda os privilégios necessários a esse usuário.

    • Se você estiver usando SSL, execute os seguintes comandos:

      CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%' REQUIRE SSL;
SHOW GRANTS FOR syncuser@'%';

    • Se você não estiver usando SSL, execute os seguintes comandos:

      CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%';
SHOW GRANTS FOR syncuser@'%';

    Os procedimentos armazenados executam todas as funções de replicação de entrada de dados. Para obter informações sobre todos os procedimentos, consulte procedimentos armazenados do Data-in Replication. Execute esses procedimentos armazenados no MySQL shell ou no MySQL Workbench.

  3. Para vincular o servidor de origem Amazon RDS for MySQL ao servidor de destino Banco de Dados do Azure para MySQL Flexible Server, faça logon na instância de destino do Banco de Dados do Azure para MySQL Flexible Server. Execute o seguinte comando para definir o servidor do Amazon RDS para MySQL como o servidor de origem:

    CALL mysql.az_replication_change_master('source_server','replication_user_name','replication_user_password',3306,'<master_bin_log_file>',master_bin_log_position,'<master_ssl_ca>');

  4. Para iniciar a replicação entre o servidor Amazon RDS para MySQL de origem e a instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino, execute o seguinte comando:

    CALL mysql.az_replication_start;

  5. Para verificar o status da replicação, no servidor de réplica, execute o seguinte comando:

    show slave status\G

    Se o estado dos parâmetros Slave_IO_Running e Slave_SQL_Running é Sim, a replicação foi iniciada e está em estado de execução.

  6. Verifique o valor do parâmetro Seconds_Behind_Master para determinar o quanto o servidor de destino está atrasado.

    Se o valor é 0, o destino processou todas as atualizações do servidor de origem. Se o valor é diferente de 0, o servidor de destino ainda está processando as atualizações.

Garanta uma transição bem-sucedida

Para garantir uma transição bem-sucedida:

  1. Configure os logins apropriados e as permissões no nível do banco de dados na instância de destino do Banco de Dados do Azure para MySQL – Flexible Server.
  2. Interrompa as operações de gravação no servidor de origem do Amazon RDS para MySQL.
  3. Certifique-se de que a instância do Servidor Flexível do Banco de Dados do Azure para MySQL de destino tenha alcançado o servidor de origem e de que o valor Seconds_Behind_Master seja 0 em show slave status.
  4. Chame o procedimento armazenado mysql.az_replication_stop para interromper a replicação, pois todas as alterações já foram replicadas para a instância de destino do Banco de Dados do Azure para MySQL - Servidor Flexível.
  5. Chame mysql.az_replication_remove_master para remover a configuração de Replicação de Dados.
  6. Redirecione clientes e aplicativos clientes para a instância de destino do Banco de Dados do Azure para MySQL Flexible Server.

Neste ponto, a migração está concluída. Seus aplicativos estão conectados ao servidor que executa o Banco de Dados do Azure para MySQL Flexible Server.

Conteúdo relacionado

  • Last updated on