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

Artigo
12/19/2023

APLICA-SE A:Banco de Dados do Azure para MySQL – Servidor Único Banco de Dados do Azure para MySQL – Servidor Flexível

Importante

O Banco de Dados do Azure para servidor único MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para o servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

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, Exportação e Importação do MySQL Workbench ou 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 o servidor flexível 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 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á a configurar a replicação de entrada de dados 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 servidor flexível 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 de servidor flexíveis do Banco de Dados do Azure para MySQL, a máquina 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 despejo e execute uma operação de restauração na 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 Banco de Dados do Azure para servidor flexível MySQL que execute a versão 5.7 ou 8.0.
Importante

Se o seu destino for o servidor flexível do Banco de Dados do Azure para MySQL com alta disponibilidade (HA) com 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 oferece 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 ao servidor Amazon RDS for 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 for MySQL tiver GTID_mode definida como ON, a instância de destino do servidor flexível do Banco de Dados do Azure para MySQL também deverá ter GTID_mode definida como ON.

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

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

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.
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.
Aumente 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.
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 IOPS em Opções de computação e armazenamento no Banco de Dados do Azure para servidor flexível 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:

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.
Certifique-se de que os arquivos de log binários no servidor de origem sejam mantidos até que as alterações sejam aplicadas na instância de destino do Banco de Dados do Azure para servidor flexível MySQL.

Com a replicação de entrada de dados, o servidor flexível do Banco de Dados do Azure para MySQL não gerencia o processo de replicação.

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:

mysql> 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)

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:
```
Mysql> 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 de 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.
```
Mysql> 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 de 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, consulte Migrar grandes bancos de dados para o Banco de Dados do Azure para servidor flexível MySQL usando mydumper/myloader.

Vincular servidores de origem e de réplica para iniciar a Replicação de Dados

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 myloader, consulte Migrar bancos de dados grandes para o Banco de Dados do Azure para servidor flexível MySQL usando mydumper/myloader.
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:
```
Mysql> CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
Mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%' REQUIRE SSL;
Mysql> SHOW GRANTS FOR syncuser@'%';
```
- Se você não estiver usando SSL, execute os seguintes comandos:
```
Mysql> CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
Mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%';
Mysql> 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.
Para vincular o servidor de origem do Amazon RDS for MySQL e o servidor de destino do 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>');
```
Para iniciar a replicação entre o servidor Amazon RDS for 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:
```
Mysql> CALL mysql.az_replication_start;
```
Para verificar o status da replicação, no servidor de réplica, execute o seguinte comando:
```
Mysql> 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.
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:

Configure os logons apropriados e as permissões no nível do banco de dados na instância de servidor flexível do Banco de Dados do Azure para MySQL de destino.
Pare as gravações no servidor de origem do Amazon RDS para MySQL.
Verifique se a instância de servidor flexível do Banco de Dados do Azure para MySQL de destino alcançou o servidor de origem e se o Seconds_Behind_Master valor é 0 de show slave status.
Chame o procedimento mysql.az_replication_stop armazenado para interromper 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.
Chame mysql.az_replication_remove_master para remover a configuração de Replicação de Dados.
Redirecionar 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 que executa o Banco de Dados do Azure para o servidor flexível MySQL.

Próximas etapas

Para obter mais informações sobre como migrar bancos de dados para o servidor flexível do Banco de Dados do Azure para MySQL, consulte o Guia de Migração de Banco de Dados.
Assista ao vídeo Easily migrate MySQL/PostgreSQL apps to Azure managed service. Ele contém uma demonstração que mostra como migrar aplicativos MySQL para o Banco de Dados do Azure para o servidor flexível MySQL.