Compartilhar via

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

  • Artigo

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 despejo e restauração do MySQL, Importação e Exportação do Workbench do MySQL, ou o Serviço de Migração de Banco de Dados do Azure para migrar seus bancos de dados MySQL para o Servidor Flexível do Banco de Dados do Azure para MySQL. É possível migrar cargas de trabalho com tempo de inatividade mínimo usando uma combinação de ferramentas de código aberto, como mysqldump ou mydumper e myloader com a Replicação de Dados.

A Replicação de Dados é 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 do 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 uma substituição seletiva dos aplicativos do primário (ou banco de dados de origem) para a réplica (ou banco de dados de destino).

Neste tutorial, você aprenderá como configurar a Replicação de Dados entre um servidor de origem que executa o Serviço de Banco de Dados Relacional da Amazon (RDS) para MySQL e um servidor de destino que executa o Servidor Flexível do Banco de Dados do Azure para MySQL.

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.

Local 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 seu computador cliente para criar um despejo e realizar uma operação de restauração na sua instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino.

  • 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 o artigo para configurar a Replicação de Dados.
    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 dependendo 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 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. Escale verticalmente o tamanho da computação da instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino para 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. Escale verticalmente o tamanho do armazenamento para obter mais IOPS durante a migração ou aumente o IOPS máximo na 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 Replicação de Dados:

  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 se existe uma réplica de leitura do servidor do Amazon RDS para MySQL de origem.

  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 a Replicação de Dados, o Servidor Flexível do Banco de Dados do Azure para MySQL não gerenciará o processo de replicação.

  3. Para verificar a retenção de log binário no servidor de origem Amazon RDS para determinar o número de horas em que os logs binários 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 capturar um despejo de dados do servidor de origem Amazon RDS para MySQL. Uma abordagem é capturar um despejo de dados diretamente no servidor de origem. A outra abordagem é capturar um despejo em uma réplica de leitura do Amazon RDS para MySQL.

  • Para capturar um despejo de dados diretamente no 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 como o valor 1 para que as gravações não sejam processadas ao capturar um despejo 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 mydumper para capturar um despejo paralelizado dos dados do banco de dados de origem do Amazon RDS para 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 você estiver usando o myloader, confira Migrar grandes bancos de dados para o Servidor Flexível do Banco de Dados do Azure para MySQL 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 fazem todas as funções de Replicação de Dados. Para obter informações sobre todos os procedimentos, confira Procedimentos armazenados na Replicação de Dados. Execute esses procedimentos armazenados no MySQL shell ou no MySQL Workbench.

  3. Para vincular o servidor de origem Amazon RDS para MySQL e o servidor de destino Servidor Flexível do Banco de Dados do Azure para MySQL, entre na instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino. 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.

Garantir uma substituição bem-sucedida

Para garantir o sucesso da substituição:

  1. Configure os logons apropriados e as permissões em nível de banco de dados na instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino.
  2. Pare as gravações no servidor de origem do Amazon RDS para MySQL.
  3. Certifique-se de que a instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino tenha se atualizado em relação ao servidor de origem e que o Seconds_Behind_Master valor seja 0 de show slave status.
  4. Chame o procedimento armazenado mysql.az_replication_stop para parar a replicação porque todas as alterações foram replicadas para a instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino.
  5. Chame mysql.az_replication_remove_master para remover a configuração de Replicação de Dados.
  6. Redirecione clientes e aplicativos cliente para a instância de Servidor Flexível do Banco de Dados do Azure para MySQL de destino.

Neste ponto, a migração está concluída. Seus aplicativos estão conectados ao servidor em execução no Servidor Flexível do Banco de Dados do Azure para MySQL.

Conteúdo relacionado