Tutorial: Migrar Base de Dados Azure para MySQL – Single Server to Azure Database for MySQL – Servidor Flexível com tempo mínimo de inatividade
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:
- Criar o servidor com Zona redundante HA ativado
- Desativar HA
- Siga o artigo para configurar a replicação de dados
- Corte de post remove a configuração de replicação de dados
- 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.
- Se um ponto final público estiver ativado na fonte, então certifique-se de que o alvo pode ligar-se à fonte, permitindo "Permitir o acesso aos serviços Azure" na regra da firewall. Para saber mais, consulte as regras de Firewall - Azure Database for MySQL.
- Se um ponto final privado e "Negar o acesso público" estiver ativado na fonte, então instale o link privado no mesmo VNet que hospeda o alvo. Para saber mais, consulte Private Link - Azure Database for MySQL.
Configurar a replicação de dados
Para configurar dados na replicação, execute os seguintes passos:
Inscreva-se no Azure VM no qual instalou a ferramenta cliente mysql.
Ligue-se à fonte e ao alvo utilizando a ferramenta cliente mysql.
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.
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'@'%';
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
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:
Certifique-se de que regista o nome do ficheiro binário para utilização em etapas posteriores.
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
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>, ‘’);
Para iniciar a replicação a partir do servidor de réplica, ligue para o procedimento abaixo armazenado.
call mysql.az_replication_start;
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.
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;
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.
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');
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.
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:
- 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.
- 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.
- 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.
- 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.
- Redirecione os clientes e aplicações de clientes para a instância alvo da Base de Dados Azure para o MySQL Flexible Server.
- Execute o corte final executando o procedimento de mysql.az_replication_stop armazenado, que impedirá a replicação do servidor de réplica.
- 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
- Saiba mais sobre a replicação de dados Replicar dados na Base de Dados Azure para o MySQL Flexible Server e Configure Azure Database para replicação de dados do servidor flexível MySQL
- Saiba mais sobre a resolução de erros comuns na Base de Dados Azure para o MySQL.
- Saiba mais sobre a migração do MySQL para a Base de Dados Azure para o MySQL offline utilizando o Serviço de Migração da Base de Dados Azure.