Tutorial: Migrar Base de Dados Azure para MySQL – Single Server to Azure Database for MySQL – Servidor Flexível com tempo mínimo de inatividade

  • Artigo
  • 10 minutos para ler

Pode migrar uma instância da Azure Database para o MySQL – Single Server to Azure Database for MySQL – Servidor Flexível com tempo mínimo de inatividade para as suas aplicações, utilizando uma combinação de ferramentas de código aberto, como o mydumper/myloader e a replicação de data-in.

Nota

Este artigo contém referências ao termo escravo, um termo que a Microsoft já não utiliza. Quando o termo for removido do software, vamos removê-lo deste artigo.

A replicação de dados é uma técnica que replica as alterações de dados do servidor de origem para o servidor de destino com base no método de posição binária do ficheiro de registo. Neste cenário, o caso MySQL que funciona como a fonte (na qual a base de dados muda de origem) escreve atualizações e alterações como "eventos" para o registo binário. As informações no registo binário são armazenadas em diferentes formatos de registo de acordo com as alterações na base de dados que estão a ser registadas. As réplicas são configuradas para ler o registo binário a partir da fonte e executar os eventos no registo binário na base de dados local da réplica.

Se configurar a replicação de data-in para sincronizar dados de uma instância da Base de Dados Azure para o MySQL para outra, pode fazer uma redução seletiva das suas aplicações da base de dados primária (ou base de dados de origem) para a réplica (ou base de dados alvo).

Neste tutorial, você usará a replicação mydumper/myloader e data-in para migrar uma base de dados de amostra (modelos clássicos) de um exemplo de Azure Database for MySQL - Single Server para uma instância de Azure Database para MySQL - Servidor Flexível e, em seguida, sincronizar dados.

Neste tutorial, ficará a saber como:

  • Configurar definições de rede para replicação de dados para diferentes cenários.
  • Configure a replicação de dados entre a primária e a réplica.
  • Teste a replicação.
  • Corte para completar a migração.

Pré-requisitos

Para concluir este tutorial, precisa de:

  • Um exemplo de Azure Database para mySQL Single Server executar a versão 5.7 ou 8.0.

    Nota

    Se estiver a executar a Base de Dados Azure para a versão 5.6 do MySQL Single Server, atualize a sua instância para 5.7 e, em seguida, configuure dados em replicação. Para saber mais, consulte a atualização da versão Major na Base de Dados Azure para MySQL - Single Server.

  • Um exemplo de Azure Database para o MySQL Flexible Server. Para obter mais informações, consulte o artigo Criar uma instância na Base de Dados Azure para o MySQL Flexible Server.

    Nota

    A configuração da replicação de dados para servidores de alta disponibilidade redundantes de zona não é suportada. Se quiser ter HA de zona redundante para o seu servidor alvo, então execute estes passos:

    1. Criar o servidor com Zona redundante HA ativado
    2. Desativar HA
    3. Siga o artigo para configurar a replicação de dados
    4. Corte de post remove a configuração de replicação de dados
    5. Ativar HA

    Certifique-se de que GTID_Mode tem a mesma definição nos servidores de origem e alvo.

  • Para ligar e criar uma base de dados utilizando a bancada MySQL Workbench. Para obter mais informações, consulte o artigo Use a bancada mySQL workbench para ligar e consultar dados.

  • Para garantir que tem um Azure VM a executar o Linux na mesma região (ou no mesmo VNet, com acesso privado) que acolhe as suas bases de dados de origem e alvo.

  • Para instalar o cliente Mysql ou a Bancada MySQL (as ferramentas do cliente) no seu Azure VM. Certifique-se de que pode ligar-se ao servidor primário e replicado. Para efeitos deste artigo, o cliente Mysql está instalado.

  • Para instalar o mydumper/myloader no seu Azure VM. Para mais informações, consulte o artigo mydumper/myloader.

  • Para descarregar e executar o script da base de dados de amostras para a base de dados de modelos clássicos no servidor de origem.

  • Configurar binlog_expire_logs_seconds no servidor de origem para garantir que os binlogs não são purgados antes que a réplica cometa as alterações. Postar corte bem sucedido pode redefinir o valor.

Configurar requisitos de rede

Para configurar a replicação do Data-in, é necessário garantir que o alvo pode ligar-se à fonte sobre a porta 3306. Com base no tipo de ponto final montado na fonte, execute os passos seguintes.

Configurar a replicação de dados

Para configurar dados na replicação, execute os seguintes passos:

  1. Inscreva-se no Azure VM no qual instalou a ferramenta cliente mysql.

  2. Ligue-se à fonte e ao alvo utilizando a ferramenta cliente mysql.

  3. Utilize a ferramenta cliente mysql para determinar se log_bin está ativado na fonte executando o seguinte comando:

    SHOW VARIABLES LIKE 'log_bin';

    Nota

    Com a Base de Dados Azure para o MySQL Single Server com o grande armazenamento, que suporta até 16TB, isto ativado por padrão.

    Dica

    Com a Base de Dados Azure para o MySQL Single Server, que suporta até 4TB, esta não é ativada por padrão. No entanto, se promover uma réplica de leitura para o servidor de origem e, em seguida, eliminar a réplica de leitura, o parâmetro será definido para ON.

  4. Com base na aplicação SSL do servidor de origem, crie um utilizador no servidor de origem com a permissão de replicação executando o comando apropriado.

    Se estiver a utilizar sSL, executar o seguinte comando:

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

    Se não estiver a utilizar sSL, executar o seguinte comando:

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

  5. Para fazer a rede de dados utilizando o mydumper, execute o seguinte comando no Azure VM onde instalamos o mydumper\myloader:

    $ mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<Password> --outputdir=./backup --rows=100 -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-consistência - apenas é necessária para a consistência transacional enquanto fazemos backup.

    • O equivalente ao mysqldump's-single-transaction.
    • Útil se todas as suas mesas forem InnoDB.
    • O fio "principal" só precisa de manter o bloqueio global até que os fios de "despejo" possam iniciar uma transação.
    • Oferece a duração mais curta do bloqueio global

    O fio "principal" só precisa de manter o bloqueio global até que os fios de "despejo" possam iniciar uma transação.

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

    • -hospedeiro: Nome do servidor primário
    • -utilizador: O nome de um utilizador (no formato username@servername uma vez que o servidor primário está a executar a Base de Dados Azure para o MySQL - Servidor Único). Pode utilizar a administração do servidor ou um utilizador com permissões SELECT e RELOAD.
    • --Senha: Palavra-passe do utilizador acima

    Para obter mais informações sobre a utilização do mydumper, consulte mydumper/myloader

  6. Leia o ficheiro de metadados para determinar o nome do ficheiro de registo binário e compense executando o seguinte comando:

    $ cat ./backup/metadata

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

    Os resultados devem figurar como indicado na seguinte imagem:

    Continuous sync with the Azure Database Migration Service

    Certifique-se de que regista o nome do ficheiro binário para utilização em etapas posteriores.

  7. Restaurar a base de dados utilizando 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:

    • -hospedeiro: Nome do servidor de réplica
    • -utilizador: Nome de um utilizador. Pode utilizar o administrador do servidor ou um utilizador com permissão de leitura\write capaz de restaurar os esquemas e dados para a base de dados
    • --Senha: Palavra-passe para o utilizador acima

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

    • Se a execução da SSL estiver ativada, então:

      i. Faça o download do certificado necessário para comunicar através do SSL com o seu Azure Database para o servidor MySQL a partir daqui.

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

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

      iii. Para configurar dados em replicação, executar 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

      Determinar a posição e o nome do ficheiro a partir das informações obtidas no passo 6.

    • Se a execução da SSL não estiver ativada, então executar 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, ligue para o procedimento abaixo armazenado.

    call  mysql.az_replication_start;

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

    show slave status \G;

    Nota

    Se estiver a utilizar a bancada MySQL Workbench, não é necessário modificar \G.

    Se o estado de Slave_IO_Running e Slave_SQL_Running são Sim e o valor de Seconds_Behind_Master é 0, então a replicação está a funcionar bem. Seconds_Behind_Master indica quão tarde é a réplica. Se o valor for algo diferente de 0, então a réplica está a processar atualizações.

Testar a replicação (opcional)

Para confirmar que a replicação do Data-in está a funcionar corretamente, pode verificar se as alterações nas tabelas primárias foram replicadas na réplica.

  1. Identifique uma tabela para utilizar para testes, por exemplo, a tabela Clientes e, em seguida, confirme que o número de entradas que contém é o mesmo nos servidores primários e réplicas executando o seguinte comando em cada um:

    select count(*) from customers;

  2. Tome nota da contagem de entrada para comparação posterior.

    Para testar a replicação, tente adicionar alguns dados às tabelas de clientes no servidor primário e ver então verificar se os novos dados são replicados. Neste caso, irá adicionar duas linhas a uma tabela no servidor primário e, em seguida, confirmar que são replicadas no servidor de réplicas.

  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 estado de replicação, ligue para o estado de escravo do show \G para confirmar que a replicação está a funcionar como esperado.

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

    select count(*) from customers;

Garantir um corte bem sucedido

Para garantir um corte bem sucedido, execute as seguintes tarefas:

  1. Configure as regras de firewall e rede virtual adequadas ao nível do servidor para ligar ao Servidor alvo. Pode comparar as regras de firewall para a fonte e o alvo a partir do portal.
  2. Configure os logins apropriados e permissões de nível de base de dados no servidor alvo. Pode executar SELECT * FROM mysql.user; nos servidores de origem e alvo para comparar.
  3. Certifique-se de que todas as ligações recebidas da Azure Database para o MySQL Single Server estão paradas.

    Dica

    Pode definir a Base de Dados Azure para o MySQL Single Server para ler apenas.

  4. Certifique-se de que a réplica alcançou a primária executando o estado de escravo do show \G e confirmando que o valor para o parâmetro Seconds_Behind_Master é 0.
  5. Redirecione os clientes e aplicações de clientes para a instância alvo da Base de Dados Azure para o MySQL Flexible Server.
  6. Execute o corte final executando o procedimento de mysql.az_replication_stop armazenado, que impedirá a replicação do servidor de réplica.
  7. Ligue mysql.az_replication_remove_master para remover a configuração de replicação de dados.

Neste momento, as suas aplicações estão ligadas à nova Base de Dados Azure para o servidor MySQL Flexible e as alterações na fonte deixarão de se replicar ao alvo.

Passos seguintes