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

Nota

Este artigo poderá conter referências ao termo slave (secundário), um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo 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 a 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 diferentes formatos de log de acordo com as alterações do 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 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 transferência 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á mydumper/myloader e replicação de dados para migrar um banco de dados de exemplo (classicmodels) de uma instância do Banco de Dados do Azure para MySQL - Servidor Único para uma instância do Banco de Dados do Azure para MySQL - Servidor Flexível e, em seguida, sincronizar dados.

Neste tutorial, irá aprender a:

  • Configure as configurações de rede para replicação de dados para diferentes cenários.
  • Configure a replicação de dados entre o primário e a réplica.
  • Teste a replicação.
  • Substituição para concluir a migração.

Pré-requisitos

Para concluir este tutorial, precisa de:

  • Uma instância do Banco de Dados do Azure para MySQL Single Server executando a versão 5.7 ou 8.0.

    Nota

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

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

    Nota

    Não há suporte para a configuração da replicação Data-in para servidores de alta disponibilidade redundantes de zona. Se você gostaria de ter HA redundante de zona para seu servidor de destino, execute estas etapas:

    1. Criar o servidor com HA redundante de zona habilitada
    2. Desativar 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. Ativar HA

    Verifique se GTID_Mode tem a mesma configuração nos servidores de origem e de destino.

  • Para 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.

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

  • Para instalar o cliente mysql ou o MySQL Workbench (as ferramentas de cliente) na sua VM do Azure. Certifique-se de que você possa se conectar ao servidor primário e ao servidor de réplica. Para os fins deste artigo, o cliente mysql está instalado.

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

  • Para 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 o corte bem-sucedido, você pode redefinir o valor.

Configurar requisitos de rede

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

Configurar a replicação de dados

Para configurar Dados na replicação, execute as seguintes etapas:

  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 log_bin está habilitado na fonte executando o seguinte comando:

    SHOW VARIABLES LIKE 'log_bin';

    Nota

    Com o Banco de Dados do Azure para MySQL Single Server com o grande armazenamento, que suporta até 16TB, isso é habilitado por padrão.

    Gorjeta

    Com o Banco de Dados do Azure para MySQL Single Server, que oferece suporte a até 4TB, isso não é habilitado por padrão. No entanto, se você promover uma réplica de leitura para o servidor de origem e, em seguida, excluir a réplica de leitura, 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 seguinte comando:

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

    Se você não estiver usando 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 onde 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

    Gorjeta

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

    • O equivalente mydumper de mysqldump's --single-transaction.
    • Útil se todas as suas tabelas forem InnoDB.
    • O thread "principal" só precisa manter o bloqueio global até que os threads "dump" possam iniciar uma transação.
    • Oferece a menor duração de bloqueio global

    O thread "principal" só precisa manter o bloqueio global até que os threads "dump" 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 username@servername uma vez que o servidor primário está 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.
    • --Senha: Senha do usuário acima

    Para obter mais informações sobre como usar 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 na etapa anterior.

    Os resultados devem aparecer como mostrado na imagem a seguir:

    Continuous sync with the Azure Database Migration Service

    Certifique-se de anotar o nome do arquivo binário para uso em etapas posteriores.

  7. Restaure o banco de dados usando 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: Nome do servidor de réplica
    • --user: 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 dados para o banco de dados
    • --Senha: Senha para o usuário acima

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

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

      i. Transfira o certificado necessário para comunicar através de SSL com a sua Base de Dados do Azure para o servidor MySQL a partir daqui.

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

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

      iii. Para configurar Dados na replicação, 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);

      Nota

      Determine a posição e o nome do arquivo a partir 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 da replicação, no servidor de réplica, execute o seguinte comando:

    show slave status \G;

    Nota

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

    Se o estado de Slave_IO_Running e Slave_SQL_Running for Sim e o valor de Seconds_Behind_Master for 0, a replicação está funcionando bem. Seconds_Behind_Master indica o quão tarde a réplica está. Se o valor for 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 entradas para comparação posterior.

    Para testar a replicação, tente adicionar alguns dados às tabelas do cliente no servidor primário e, em seguida, verifique se os novos dados são replicados. Nesse caso, você adicionará duas linhas a uma tabela no servidor primário e confirmará se elas foram 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 o show slave status \G para confirmar se a replicação está funcionando conforme o esperado.

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

    select count(*) from customers;

Garanta uma transição bem-sucedida

Para garantir uma transferência com êxito, execute as seguintes tarefas:

  1. Configure as regras de firewall e rede virtual ao nível do servidor adequadas para ligar ao servidor de destino. Você pode comparar as regras de firewall para a origem e o destino a partir do portal.
  2. Configure logins apropriados e 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 comparar.
  3. Certifique-se de que todas as conexões de entrada com o Banco de Dados do Azure para Servidor Único MySQL sejam interrompidas.

    Gorjeta

    Você pode definir o Banco de Dados do Azure para MySQL Single Server como somente leitura.

  4. Certifique-se de que a réplica alcançou o primário executando show slave status \G e confirmando que o valor para o parâmetro Seconds_Behind_Master é 0.
  5. Redirecionar clientes e aplicativos cliente para a instância de destino do Banco de Dados do Azure para o Servidor Flexível MySQL.
  6. Execute a transferência final ao executar o procedimento armazenado mysql.az_replication_stop, que impedirá 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 banco de dados do Azure para servidor MySQL flexível e as alterações na origem não serão mais replicadas para o destino. Criar e gerir regras de firewall da Base de Dados do Azure para MySQL com o portal do Azure

Próximos passos