Como configurar o Banco de Dados do Azure para MySQL - Replicação de dados do Servidor Flexível

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

Este artigo descreve como configurar a replicação de dados no Banco de Dados do Azure para o servidor flexível MySQL configurando os servidores de origem e de réplica. Este artigo pressupõe que você tenha alguma experiência anterior com servidores e bancos de dados MySQL.

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.

Para criar uma réplica no Banco de Dados do Azure para instância de servidor flexível do MySQL, a replicação de dados sincroniza dados de um servidor MySQL de origem local, em máquinas virtuais (VMs) ou em serviços de banco de dados em nuvem. A replicação de dados pode ser configurada usando a replicação baseada em posição de arquivo de log binário (binlog) OU a replicação baseada em GTID. Para saber mais sobre a replicação binlog, consulte a Replicação MySQL.

Analise as limitações e os requisitos da replicação de dados antes de executar as etapas neste artigo.

Criar uma instância de servidor flexível do Banco de Dados do Azure para MySQL para usar como réplica

1. Crie uma nova instância do Banco de Dados do Azure para o servidor flexível MySQL (por exemplo, replica.mysql.database.azure.com). Consulte Criar um Banco de Dados do Azure para instância de servidor flexível do MySQL usando o portal do Azure para criação de servidor. Este servidor é o servidor de "réplica" para replicação de dados.

2. Crie as mesmas contas de usuário e os privilégios correspondentes.

   As contas de usuário não são replicadas do servidor de origem para o servidor de réplica. Se você planeja fornecer aos usuários acesso ao servidor de réplica, precisará criar todas as contas e privilégios correspondentes manualmente nesta instância de servidor flexível do Banco de Dados do Azure para MySQL recém-criada.

Configurar o servidor MySQL de origem

As etapas a seguir preparam e configuram o servidor MySQL hospedado localmente, em uma máquina virtual ou serviço de banco de dados hospedado por outros provedores de nuvem para replicação de dados. Este servidor é a "fonte" para a replicação de dados.

1. Analise os requisitos do servidor de origem antes de continuar.

2. Requisitos de rede

   • Verifique se o servidor de origem permite o tráfego de entrada e de saída na porta 3306 e se tem um endereço IP público, se o DNS é acessível publicamente ou se tem um FQDN (nome de domínio totalmente qualificado).

   • Se o acesso privado estiver em uso, verifique se você tem conectividade entre o servidor de origem e a Vnet na qual o servidor de réplica está hospedado.

   • Certifique-se de que fornecemos conectividade site a site para seus servidores de origem locais usando a Rota Expressa ou VPN. Para obter mais informações sobre como criar uma rede virtual, consulte a Documentação da Rede Virtual e, especialmente, os artigos de início rápido com detalhes passo a passo.

   • Se o acesso privado for usado no servidor de réplica e sua origem for a VM do Azure, verifique se a conectividade VNet para VNet está estabelecida. O emparelhamento VNet-Vnet é suportado. Você também pode usar outros métodos de conectividade para se comunicar entre redes virtuais em diferentes regiões, como conexão VNet para VNet. Para obter mais informações, consulte Gateway VPN VNet-to-VNet

   • Certifique-se de que as regras do Grupo de Segurança de Rede da rede virtual não bloqueiem a porta de saída 3306 (também de entrada se o MySQL estiver sendo executado na VM do Azure). Para obter mais detalhes sobre a filtragem de tráfego NSG de rede virtual, consulte o artigo Filtrar tráfego de rede com grupos de segurança de rede.

   • Configure as regras de firewall do servidor de origem para permitir o endereço IP do servidor de réplica.

3. Siga as etapas apropriadas com base em se você deseja usar a posição bin-log ou a replicação de dados baseada em GTID.

   Replicação baseada em posição de bin-log

   Verifique se o log binário foi habilitado na origem executando o seguinte comando:

   SHOW VARIABLES LIKE 'log_bin';
   

   Se a variável log_bin for retornada com o valor "ON", o log binário será habilitado no servidor.

   Se log_bin for retornado com o valor "OFF" e seu servidor de origem estiver sendo executado no local ou em máquinas virtuais onde você pode acessar o arquivo de configuração (my.cnf), você pode seguir as seguintes etapas:

   1. Localize seu arquivo de configuração do MySQL (my.cnf) no servidor de origem. Por exemplo: /etc/my.cnf

   2. Abra o arquivo de configuração para editá-lo e localize a seção mysqld no arquivo.

   3. Na seção mysqld, adicione a seguinte linha:

      log-bin=mysql-bin.log
      

   4. Reinicie o serviço MySQL no servidor de origem (ou Reiniciar) para que as alterações entrem em vigor.

   5. Depois que o servidor for reiniciado, verifique se o log binário está habilitado executando a mesma consulta anterior:

   SHOW VARIABLES LIKE 'log_bin';
   

   Replicação baseada em GTID

   O servidor mestre precisa ser iniciado com o modo GTID habilitado definindo a variável gtid_mode como ON. Também é essencial que a variável enforce_gtid_consistency esteja habilitada para garantir que apenas as instruções, que são seguras para a replicação de GTIDs do MySQL, sejam registradas.

   DEFINIR @@GLOBAL. ENFORCE_GTID_CONSISTENCY = LIGADO;

   DEFINIR @@GLOBAL. GTID_MODE = LIGADO;

   Se o servidor mestre for outra instância de servidor flexível do Banco de Dados do Azure para MySQL, esses parâmetros de servidor também poderão ser atualizados do portal navegando até a página de parâmetros do servidor.

4. Configure as configurações do servidor de origem.

   A replicação de dados requer que o parâmetro lower_case_table_names seja consistente entre os servidores de origem e de réplica. Este parâmetro é 1 por padrão no Banco de Dados do Azure para o servidor flexível MySQL.

   SET GLOBAL lower_case_table_names = 1;
   

5. Crie uma nova função de replicação e configure a permissão.

   Crie uma conta de usuário no servidor de origem configurada com privilégios de replicação. Isso pode ser feito através de comandos SQL ou uma ferramenta como o MySQL Workbench. Considere se você planeja replicar com SSL, pois isso precisará ser especificado ao criar o usuário. Consulte a documentação do MySQL para entender como adicionar contas de usuário no seu servidor de origem.

   Nos comandos a seguir, a nova função de replicação criada pode acessar a origem de qualquer máquina, não apenas da máquina que hospeda a própria origem. Isso é feito especificando "syncuser@'%'" no comando create user. Consulte a documentação do MySQL para saber mais sobre como especificar nomes de contas.

Comando SQL

Replicação com SSL

Para exigir SSL para todas as conexões de usuário, use o seguinte comando para criar um usuário:

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

Replicação sem SSL

Se o SSL não for necessário para todas as conexões, use o seguinte comando para criar um usuário:

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

Banco de trabalho MySQL

Para criar a função de replicação no MySQL Workbench, abra o painel Usuários e privilégios no painel Gerenciamento e selecione Adicionar conta.

Digite o nome de usuário no campo Nome de login.

Selecione o painel Funções administrativas e, em seguida, selecione Escravo de replicação na lista de Privilégios globais. Em seguida, selecione Aplicar para criar a função de replicação.

1. Defina o servidor de origem para o modo somente leitura.

Antes de começar a despejar o banco de dados, o servidor precisa ser colocado no modo somente leitura. Enquanto estiver no modo somente leitura, a fonte não poderá processar nenhuma transação de gravação. Avalie o impacto para o seu negócio e agende a janela somente leitura em um horário fora do pico, se necessário.

FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;

1. Obtenha o nome do arquivo de log binário e o deslocamento.

   Execute o comando para determinar o nome e o show master status deslocamento do arquivo de log binário atual.

      show master status;
   

Os resultados devem ser semelhantes aos seguintes. Certifique-se de anotar o nome do arquivo binário para uso em etapas posteriores.

Despejar e restaurar o servidor de origem

1. Determine quais bancos de dados e tabelas você deseja replicar no Banco de Dados do Azure para o servidor flexível MySQL e execute o despejo do servidor de origem.

   Você pode usar mysqldump para despejar bancos de dados do seu servidor primário. Para obter detalhes, consulte Dump & Restore. É desnecessário despejar a biblioteca MySQL e a biblioteca de teste.

2. Defina o servidor de origem para o modo de leitura/gravação.

   Depois que o banco de dados tiver sido despejado, altere o servidor MySQL de origem de volta para o modo de leitura/gravação.

   SET GLOBAL read_only = OFF;
   UNLOCK TABLES;
   

[!NOTA]

Antes que o servidor seja definido de volta para o modo de leitura/gravação, você pode recuperar as informações do GTID usando a variável global GTID_EXECUTED. O mesmo será usado no estágio posterior para definir o GTID no servidor de réplica

3. Restaure o arquivo de despejo para o novo servidor.

   Restaure o arquivo de despejo para o servidor criado no Banco de Dados do Azure para o servidor flexível MySQL. Consulte Dump & Restore para saber como restaurar um arquivo de despejo para um servidor MySQL. Se o arquivo de despejo for grande, carregue-o em uma máquina virtual no Azure na mesma região do servidor de réplica. Restaure-o para a instância de servidor flexível do Banco de Dados do Azure para MySQL a partir da máquina virtual.

Nota

Se você quiser evitar definir o banco de dados para ler somente quando você despejar e restaurar, você pode usar mydumper/myloader.

Definir GTID no servidor de réplica

1. Ignore a etapa se estiver usando a replicação baseada em posição do bin-log

2. As informações de GTID do arquivo de despejo retiradas da origem são necessárias para redefinir o histórico de GTID do servidor de destino (réplica).

3. Use essas informações de GTID da origem para executar a redefinição de GTID no servidor de réplica usando o seguinte comando da CLI:

   az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>
   

Para obter mais detalhes, consulte GTID Reset.

Nota

A redefinição do GTID não pode ser executada em um servidor habilitado para backup de redundância geográfica. Desative a redundância geográfica para executar a redefinição do GTID no servidor. Você pode ativar a opção de redundância geográfica novamente após a redefinição do GTID. A ação de redefinição do GTID invalida todos os backups disponíveis e, portanto, uma vez que a redundância geográfica é ativada novamente, pode levar um dia até que a restauração geográfica possa ser executada no servidor

Vincular servidores de origem e de réplica para iniciar a replicação de dados

1. Defina o servidor de origem.

   Todas as funções de replicação de dados são feitas por procedimentos armazenados. Você pode encontrar todos os procedimentos em Procedimentos armazenados de replicação de dados. Os procedimentos armazenados podem ser executados no shell do MySQL ou no MySQL Workbench.

Para vincular dois servidores e iniciar a replicação, faça logon no servidor de réplica de destino no serviço Banco de Dados do Azure para MySQL e defina a instância externa como o servidor de origem. Isso é feito usando o mysql.az_replication_change_master ou mysql.az_replication_change_master_with_gtid procedimento armazenado no Banco de Dados do Azure para servidor MySQL.

CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');

CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>,'<master_ssl_ca>');

• master_host: Nome do host do servidor de origem
• master_user: Nome de usuário para o servidor de origem
• master_password: Senha para o servidor de origem
• master_port: número da porta na qual o servidor de origem está escutando conexões. (3306 é a porta padrão na qual o MySQL está escutando)
• master_log_file: nome do arquivo de log binário da execução show master status
• master_log_pos: posição de log binário da execução show master status
• master_ssl_ca: contexto do certificado de autoridade de certificação. Se não estiver usando SSL, passe a cadeia de caracteres vazia.

Recomenda-se passar esse parâmetro como uma variável. Para obter mais informações, visite os exemplos a seguir.

Nota

• Se o servidor de origem estiver hospedado em uma VM do Azure, defina "Permitir acesso aos serviços do Azure" como "ATIVADO" para permitir que os servidores de origem e de réplica se comuniquem entre si. Essa configuração pode ser alterada nas opções de segurança de conexão. Para obter mais informações, consulte Gerenciar regras de firewall usando o portal.
• Se você usou mydumper/myloader para despejar o banco de dados, então você pode obter o master_log_file e master_log_pos do arquivo /backup/metadata .

Exemplos

Replicação com SSL

A variável @cert é criada executando os seguintes comandos MySQL:

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

A replicação com SSL é configurada entre um servidor de origem hospedado no domínio "companya.com" e um servidor de réplica hospedado no Banco de Dados do Azure para o servidor flexível MySQL. Este procedimento armazenado é executado na réplica.

CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);

CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @cert);

Replicação sem SSL

A replicação sem SSL é configurada entre um servidor de origem hospedado no domínio "companya.com" e um servidor de réplica hospedado no Banco de Dados do Azure para servidor flexível MySQL. Este procedimento armazenado é executado na réplica.

CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');

CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');

1. Inicie a replicação.

   Chame o procedimento armazenado para iniciar a mysql.az_replication_start replicação.

   CALL mysql.az_replication_start;
   

2. Verifique o status da replicação.

   Chame o comando no servidor de réplica para exibir o show slave status status da replicação.

   show slave status;
   

Para saber o status correto da replicação, consulte as métricas de replicação - Status de E/S da réplica e Status SQL da réplica na página de monitoramento.

Se o for "0", a Seconds_Behind_Master replicação está funcionando bem. Seconds_Behind_Master indica o quão tarde a réplica está. Se o valor não for "0", significa que a réplica está processando atualizações.

Outros procedimentos armazenados úteis para operações de replicação de dados

Parar replicação

Para interromper a replicação entre o servidor de origem e o servidor de réplica, use o seguinte procedimento armazenado:

CALL mysql.az_replication_stop;

Remover relação de replicação

Para remover a relação entre o servidor de origem e o servidor de réplica, use o seguinte procedimento armazenado:

CALL mysql.az_replication_remove_master;

Ignorar erro de replicação

Para ignorar um erro de replicação e permitir que a replicação continue, use o seguinte procedimento armazenado:

CALL mysql.az_replication_skip_counter;

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Próximos passos

• Saiba mais sobre a replicação de dados para o banco de dados do Azure para o servidor flexível MySQL.