Como configurar o Banco de Dados do Azure para a Replicação de Dados MySQL

Artigo
12/19/2023

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

Este artigo descreve como configurar a Replicação de Dados no Banco de Dados do Azure para 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 serviço Banco de Dados do Azure para MySQL, a Replicação Data-in 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 Data-in é baseada na posição do arquivo de log binário (binlog) ou na replicação baseada em GTID nativa do MySQL. Para saber mais sobre a replicação binlog, consulte a visão geral da replicação binlog do MySQL.

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

Criar um Banco de Dados do Azure para instância de servidor único MySQL para usar como réplica

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

Importante

O Banco de Dados do Azure para servidor MySQL deve ser criado nas camadas de preços de Uso Geral ou Memória Otimizada, pois a replicação de dados só é suportada nessas camadas. O GTID é suportado nas versões 5.7 e 8.0 e apenas em servidores que suportam armazenamento de até 16 TB (armazenamento de uso geral v2).
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 neste recém-criado Banco de Dados do Azure para servidor MySQL.
Adicione o endereço IP do servidor de origem às regras de firewall da réplica.

Atualize as regras de firewall com o portal do Azure ou a CLI do Azure.
Opcional - Se desejar usar a replicação baseada em GTID do servidor de origem para o servidor de réplica do Banco de Dados do Azure para MySQL, será necessário habilitar os seguintes parâmetros de servidor no Banco de Dados do Azure para servidor MySQL, conforme mostrado na imagem do portal abaixo:

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.

Analise os requisitos do servidor de origem antes de continuar.
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).

Teste a conectividade com o servidor de origem tentando se conectar a partir de uma ferramenta como a linha de comando MySQL hospedada em outra máquina ou do Azure Cloud Shell disponível no portal do Azure.

Se sua organização tiver políticas de segurança rígidas e não permitir que todos os endereços IP no servidor de origem habilitem a comunicação do Azure com seu servidor de origem, você poderá usar o comando abaixo para determinar o endereço IP do seu servidor MySQL.
1. Entre no seu Banco de Dados do Azure para servidor MySQL usando uma ferramenta como a linha de comando MySQL.
2. Execute a seguinte consulta.
```
mysql> SELECT @@global.redirect_server_host;
```
  Abaixo está um exemplo de saída:
```
+-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+
```
3. Saia da linha de comando do MySQL.
4. Para obter o endereço IP, execute o seguinte comando no utilitário ping:
```
ping <output of step 2b>
```
  Por exemplo:
```
C:\Users\testuser> ping e299ae56f000.tr1830.westus1-a.worker.database.windows.net
Pinging tr1830.westus1-a.worker.database.windows.net (**11.11.111.111**) 56(84) bytes of data.
```
5. Configure as regras de firewall do servidor de origem para incluir o endereço IP de saída da etapa anterior na porta 3306.
  
  Nota
  
  Este endereço IP pode mudar devido a operações de manutenção/implantação. Este método de conectividade é apenas para clientes que não podem permitir todos os endereços IP na porta 3306.
Ative o registro binário.

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 etapas abaixo:
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 servidor de origem do MySQL 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';
```
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 MySQL.
```
SET GLOBAL lower_case_table_names = 1;
```
Opcional - Se desejar usar a replicação baseada em GTID, será necessário verificar se o GTID está habilitado no servidor de origem. Você pode executar o seguinte comando em seu servidor MySQL de origem para ver se gtid_mode está ON.
```
show variables like 'gtid_mode';
```
Importante

Todos os servidores têm gtid_mode definido como o valor padrão OFF. Você não precisa ativar o GTID no servidor MySQL de origem especificamente para configurar a replicação de dados. Se o GTID já estiver habilitado no servidor de origem, você pode, opcionalmente, usar a replicação baseada em GTID para configurar a Replicação de Dados também com o Banco de Dados do Azure para servidor único MySQL. Você pode usar a replicação baseada em arquivo para configurar a replicação de dados para todos os servidores, independentemente da configuração de gitd_mode no servidor de origem.
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.
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;
```
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

Determine quais bancos de dados e tabelas você deseja replicar no Banco de Dados do Azure para 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.
Opcional - Se você deseja usar a replicação baseada em gtid, precisará identificar o GTID da última transação executada na primária. Você pode usar o comando a seguir para anotar o GTID da última transação executada no servidor mestre.
```
show global variables like 'gtid_executed';
```
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;
```
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 serviço 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 o Banco de Dados do Azure para o servidor MySQL a partir da máquina virtual.
Opcional - Observe o GTID do servidor restaurado no Banco de Dados do Azure para MySQL para garantir que ele seja igual ao servidor primário. Você pode usar o comando a seguir para anotar o GTID do valor GTID limpo no Banco de Dados do Azure para o servidor de réplica MySQL. O valor de gtid_purged deve ser o mesmo que gtid_executed no mestre anotado na etapa 2 para que a replicação baseada em GTID funcione.
```
show global variables like 'gtid_purged';
```

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

Defina o servidor de origem.

Todas as funções de replicação Data-in são feitas por procedimentos armazenados. Você pode encontrar todos os procedimentos em Data-in Replication Stored Procedures. 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 procedimento armazenado no Banco de Dados do Azure para o 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>');
```
Opcional - Se você deseja usar a replicação baseada em gtid, você precisará usar o seguinte comando para vincular os dois servidores
```
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, consulte 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 .

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 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);
```
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 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, '');
```
Configure a filtragem.

Se você quiser ignorar a replicação de algumas tabelas do seu mestre, atualize o parâmetro do replicate_wild_ignore_table servidor no servidor de réplica. Você pode fornecer mais de um padrão de tabela usando uma lista separada por vírgula.

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Para atualizar o parâmetro, você pode usar o portal do Azure ou a CLI do Azure.
Inicie a replicação.

Chame o procedimento armazenado para iniciar a mysql.az_replication_start replicação.
```
CALL mysql.az_replication_start;
```
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;
```
Se o estado de e são "sim" e Slave_SQL_Running o valor de Seconds_Behind_MasterSlave_IO_Running é "0", a 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;

Opcional - Se você deseja usar a replicação baseada em gtid, use o seguinte procedimento armazenado para ignorar uma transação

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

O procedimento pode ignorar a transação para o determinado GTID. Se o formato GTID não estiver correto ou se a transação GTID já tiver sido executada, o procedimento não será executado. O GTID de uma transação pode ser determinado analisando o log binário para verificar os eventos da transação. MySQL fornece um utilitário mysqlbinlog para analisar logs binários e exibir seu conteúdo em formato de texto, que pode ser usado para identificar GTID da transação.

Importante

Este procedimento só pode ser usado para ignorar uma transação e não pode ser usado para ignorar o conjunto gtid ou definir gtid_purged.

Para ignorar a próxima transação após a posição de replicação atual, use o comando a seguir para identificar o GTID da próxima transação, conforme mostrado abaixo.

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

Show binary log results

Próximos passos

Saiba mais sobre a Replicação de Dados para o Banco de Dados do Azure para MySQL.