Migrar o Banco de Dados do Azure para MySQL - Servidor Único para o Banco de Dados do Azure para MySQL - Servidor Flexível com ferramentas de código aberto

  • Artigo

Você pode migrar uma instância de Banco de Dados do Azure para MySQL - Servidor Único para o Banco de Dados do Azure para MySQL - Servidor Flexível com o mínimo de tempo de inatividade para seus aplicativos usando uma combinação de ferramentas de código aberto, como mydumper/myloader e replicação 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.

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 operando como origem (na qual as alterações do 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 para executar os eventos no sinal binário no banco de dados local da réplica.

Se você configurar a replicação de dados para sincronizar dados de uma instância do Banco de Dados do Azure para MySQL para outra, poderá fazer uma substituição seletiva de seus aplicativos do banco de dados primário (ou de origem) para a réplica (ou banco de dados de destino).

Neste tutorial, você usará o mydumper/myloader e a replicação de Dados para migrar um banco de dados de amostra (classicmodels) de uma instância de Banco de Dados do Azure para MySQL - Servidor Único para uma instância de Banco de Dados do Azure para MySQL - Servidor Flexível e, em seguida, sincronizar dados.

Neste tutorial, você aprenderá a:

  • Configurar as Configurações de Rede para replicar dados em cenários diferentes.
  • Configurar a replicação de dados entre a réplica e a primária.
  • Testar a replicação.
  • Substituir para concluir a migração.

Pré-requisitos

Para concluir este tutorial, você precisará:

  • Uma instância do Servidor Único do Banco de Dados do Azure para MySQL na versão 5.7 ou 8.0.

    Observação

    Se você estiver executando o Servidor Único do Banco de Dados do Azure para MySQL versão 5.6, atualize sua instância para 5.7 e configure os dados na replicação. Para saber mais, confira Atualização de versão principal no Banco de Dados do Azure para MySQL – Servidor Único.

  • Uma instância do Servidor Flexível do Banco de Dados do Azure para MySQL. Para obter mais informações, consulte o artigo Criar uma instância no Servidor flexível do Banco de Dados do Azure para MySQL.

    Observação

    Não há suporte para a configuração da Replicação de Dados em servidores de alta disponibilidade com redundância de zona. Se você quiser ter alta disponibilidade com redundância de zona para seu servidor de destino, execute as seguintes etapas:

    1. Crie o servidor com redundância de zona com alta disponibilidade habilitada
    2. Desabilitar a alta disponibilidade
    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. Habilitar a alta disponibilidade

    Certifique-se de que GTID_Mode tenha a mesma configuração nos servidores de origem e de destino.

  • Conectar e criar um banco de dados usando o MySQL Workbench. Para obter mais informações, consulte o artigo Usar o MySQL Workbench para conectar e consultar dados.

  • Garantir que você tenha uma VM do Azure executando o Linux na mesma região (ou na mesma VNet, com acesso privado) que hospeda seus bancos de dados de origem e de destino.

  • Instalar o cliente mysql ou o MySQL Workbench (as ferramentas de cliente) em sua VM do Azure. Verifique se você pode se conectar tanto ao servidor primário quanto ao de réplica. Para os fins deste artigo, o cliente mysql está instalado.

  • Instalar o mydumper/myloader em sua VM do Azure. Para obter mais informações, confira o artigo mydumper/myloader.

  • Baixar e executar o script de banco de dados de exemplo para o banco de dados classicmodels no servidor de origem.

  • Configure binlog_expire_logs_seconds no servidor de origem para garantir que os binlogs não sejam limpos antes que a réplica confirme as alterações. Após a substituição bem-sucedida, você poderá redefinir o valor.

Configurar os requisitos de rede

Para configurar a replicação de dados, você precisa garantir que o destino possa se conectar à origem pela porta 3306. Com base no tipo de ponto de extremidade definido na origem, execute as etapas apropriadas a seguir.

Configurar replicação de dados

Para configurar a Replicação de dados, execute os seguintes passos:

  1. Entre na VM do Azure na qual você instalou a ferramenta de cliente mysql.

  2. Conecte-se à origem e ao destino usando a ferramenta de cliente mysql.

  3. Use a ferramenta de cliente mysql para determinar se o log_bin está habilitado na origem executando o seguinte comando:

    SHOW VARIABLES LIKE 'log_bin';

    Observação

    Com o Servidor Único do Banco de Dados do Azure para MySQL com o armazenamento grande, que dá suporte a até 16 TB, ele é habilitado por padrão.

    Dica

    Com o Servidor Único do Banco de Dados do Azure para MySQL que dá suporte a até 4 TB, ele não é habilitado por padrão. No entanto, se você promover uma réplica de leitura para o servidor de origem e, em seguida, excluí-la, o parâmetro será definido como ON.

  4. Com base na imposição de SSL para o servidor de origem, crie um usuário no servidor de origem com a permissão de replicação executando o comando apropriado.

    Se você estiver usando SSL, execute o comando a seguir:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;

    Se você não estiver usando o SSL, execute o seguinte comando:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

  5. Para fazer backup do banco de dados usando mydumper, execute o seguinte comando na VM do Azure na qual instalamos o mydumper\myloader:

    mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<Password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl  --regex '^(classicmodels\.)' -L mydumper-logs.txt

    Dica

    A opção --trx-consistency-only é necessária para consistência transacional enquanto fazemos backup.

    • O equivalente ao mydumper de --single-transaction do mydumper.
    • Útil se todas as tabelas forem InnoDB.
    • A thread “principal” só precisa manter o bloqueio global até que as threads de “despejo” possam iniciar uma transação.
    • Oferece a menor duração de bloqueio global

    A thread “principal” só precisa manter o bloqueio global até que as threads de “despejo” possam iniciar uma transação.

    As variáveis neste comando são explicadas abaixo:

    HOW-TO-MANAGE-FIREWALL-PORTAL --host: nome do servidor primário

    • --user: Nome de um usuário (no formato nomedeusuários@nomedoservidor desde que o servidor primário esteja executando o Banco de Dados do Azure para MySQL – Servidor Único). Você pode usar o administrador do servidor ou um usuário com permissões SELECT e RELOAD.
    • --Password: A senha do usuário acima

    Para obter mais informações sobre como usar o mydumper, consulte mydumper/myloader

  6. Leia o arquivo de metadados para determinar o nome do arquivo de log binário e o deslocamento executando o seguinte comando:

    cat ./backup/metadata

    Neste comando, ./backup refere-se ao diretório de saída usado no comando da etapa anterior.

    Os resultados devem aparecer conforme mostrado na imagem a seguir:

    Continuous sync with the Azure Database Migration Service

    Anote o nome do arquivo binário para ele ser usado em etapas posteriores.

  7. Restaure o banco de dados usando o myloader executando o seguinte comando:

    myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<Password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txt

    As variáveis neste comando são explicadas abaixo:

    • --host: O nome do servidor de réplica
    • --user: O nome de um usuário. Você pode usar o administrador do servidor ou um usuário com permissão de leitura/gravação capaz de restaurar os esquemas e os dados no banco de dados
    • --Password: A senha do usuário acima

  8. Dependendo da imposição de SSL no servidor primário, conecte-se ao servidor de réplica usando a ferramenta de cliente mysql e execute as etapas a seguir.

    • Se a imposição de SSL estiver habilitada, então:

      i. Faça o download do certificado necessário para se comunicar por SSL com o servidor de Banco de Dados do Azure para MySQL a partir daqui.

      ii. Abra o arquivo no bloco de notas e cole o conteúdo na seção "COLOCAR O CONTEXTO DO CERTIFICADO DE CHAVE PÚBLICA AQUI".

      SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE
-----END CERTIFICATE-----'

      III. Para configurar a replicação de dados, execute o seguinte comando:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, @cert);

      Observação

      Determine a posição e o nome do arquivo das informações obtidas na etapa 6.

    • Se a imposição de SSL não estiver habilitada, execute o seguinte comando:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, ‘’);

  9. Para iniciar a replicação a partir do servidor de réplica, chame o procedimento armazenado abaixo.

    call  mysql.az_replication_start;

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

    show slave status \G;

    Observação

    Se você estiver usando o MySQL Workbench, o modificador \G não será necessário.

    Se o estado de Slave_IO_Running e Slave_SQL_Running forem “Sim”, e o valor de Seconds_Behind_Master for 0, a replicação está funcionando bem. O valor de Seconds_Behind_Master indica se há atraso da réplica. Se o valor é diferente de 0, a réplica está processando atualizações.

Testando a replicação (opcional)

Para confirmar se a replicação de dados está funcionando corretamente, você pode verificar se as alterações nas tabelas primárias foram replicadas para a réplica.

  1. Identifique uma tabela a ser usada para teste, por exemplo, a tabela Clientes, e, em seguida, confirme se o número de entradas que ela contém é o mesmo nos servidores primário e de réplica, executando o seguinte comando em cada um:

    select count(*) from customers;

  2. Anote a contagem de entrada para comparação posterior.

    Para testar a replicação, tente adicionar alguns dados às tabelas de cliente no servidor primário e verifique se os novos dados são replicados. Nesse caso, você adicionará duas linhas a uma tabela no servidor primário e, em seguida, confirmará que elas são replicadas no servidor de réplica.

  3. Na tabela Clientes no servidor primário, insira linhas executando o seguinte comando:

    insert  into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values
(<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');

  4. Para verificar o status da replicação, chame show slave status \G para confirmar que a replicação está funcionando conforme o esperado.

  5. Para confirmar que a contagem é a mesma, no servidor de réplica, execute o seguinte comando:

    select count(*) from customers;

Garantir uma substituição bem-sucedida

Para garantir uma substituição bem-sucedida, execute as seguintes tarefas:

  1. Configure o firewall de nível de servidor apropriado e regras de rede virtual para se conectar ao servidor de destino. Você pode comparar as regras de firewall para a origem e o destino no Portal.
  2. Configure as entradas apropriadas e as permissões no nível do banco de dados no servidor de destino. Você pode executar SELECT FROM mysql.user; nos servidores de origem e de destino para comparação.
  3. Certifique-se de que todas as conexões de entrada para o Servidor Único do Banco de Dados do Azure para MySQL sejam interrompidas.

    Dica

    Você pode definir o Servidor Único do Banco de Dados do Azure para MySQL como somente leitura.

  4. Verifique se a réplica foi atualizada com a primária executando show slave status \G e confirmando se o valor do parâmetro Seconds_Behind_Master é 0.
  5. Redirecione os clientes e aplicativos cliente para a instância de destino do Servidor Flexível do Banco de Dados do Azure para MySQL.
  6. Execute a substituição final executando o procedimento armazenado mysql.az_replication_stop, que irá parar a replicação do servidor de réplica.
  7. Chame mysql.az_replication_remove_master para remover a configuração de replicação de dados.

Neste ponto, seus aplicativos estão conectados ao novo Servidor Flexível do Banco de Dados do Azure para MySQL, e as alterações na fonte não serão mais replicadas para o destino. Criar e gerenciar regras de firewall do Banco de Dados do Azure para MySQL usando o Portal do Azure

Próximas etapas