Como configurar a replicação nos dados para o Banco de Dados do Azure para MySQL

Artigo
05/03/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 da desativação. É altamente recomendável que você atualize para o servidor flexível do Banco de Dados do Azure para MySQL. Para obter mais informações sobre a migração para o servidor flexível do Banco de Dados do Azure para MySQL, confira O que está acontecendo com o Servidor Único do Banco de Dados do Azure para MySQL?

Este artigo descreve como configurar a Replicação de Dados no Banco de Dados do Azure para MySQL ao configurar 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.

Observação

Este artigo contém referências ao termo servidor subordinado, um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Para criar uma réplica no serviço de Banco de Dados do Azure para MySQL, a Replicação de Dados sincroniza dados de um servidor MySQL local de origem, em VMs (máquinas virtuais) ou em serviços de banco de dados de nuvem. A Replicação de Dados se baseia na replicação nativa baseada na posição do arquivo de log binário (binlog) ou baseada em GTID para o MySQL. Para saber mais sobre a replicação do binlog, confira a visão geral da replicação do binlog do MySQL.

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

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

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

Importante

O servidor do Banco de Dados MySQL do Azure deve ser criado nos tipos de preço Uso Geral ou com Otimizado para Memória, já que a replicação de dados só tem suporte nesses tipos. O GTID tem suporte nas versões 5.7 e 8.0 e apenas em servidores compatíveis com um armazenamento de até 16 TB (armazenamento v2 de uso geral).
Crie as mesmas contas de usuário e privilégios correspondentes.

Contas de usuário não são replicadas do servidor de origem para o servidor de réplica. Caso planeje fornecer aos usuários acesso ao servidor de réplica, você precisa criar manualmente todas as contas e privilégios correspondentes no servidor do Banco de Dados do Azure para MySQL recém-criado.
Adicione o endereço IP do servidor de origem às regras de firewall da réplica.

Atualizar regras de firewall usando o Portal do Azure ou a CLI do Azure.
Opcional – se você quiser 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, precisará habilitar os seguintes parâmetros de servidor no servidor do Banco de Dados do Azure para MySQL:
- enforce_gtid_consistency
- gtid_mode

Configurar o servidor MySQL de origem

As etapas a seguir preparam e configuram o servidor MySQL hospedado no local, em uma máquina virtual ou serviço de banco de dados hospedado por outros provedores de nuvem para replicação de entrada nos dados. Esse servidor é a "origem" da 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 ele tem um endereço IP público, se o DNS pode ser acessado publicamente ou se ele tem um FQDN (nome de domínio totalmente qualificado).

Para testar a conectividade ao servidor de origem, tente se conectar a partir de uma ferramenta como a linha de comando do MySQL hospedada em outro computador ou a partir do Azure Cloud Shell disponível no portal do Azure.

Caso sua organização tenha políticas de segurança estritas e não vá permitir que todos os endereços IP no servidor de origem habilitem a comunicação do Azure para o servidor de origem, você poderá usar o comando a seguir para determinar o endereço IP do servidor MySQL.
1. Entre no servidor do Banco de Dados do Azure para MySQL usando uma ferramenta como a linha de comando do MySQL.
2. Execute a consulta a seguir.
```
mysql> SELECT @@global.redirect_server_host;
```
  Abaixo estão alguns exemplos 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.
  
  Observação
  
  Este endereço IP pode mudar devido a operações de manutenção/implantação. Esse método de conectividade destina-se apenas a clientes que não podem permitir todos os endereços IP na porta 3306.
Ative o registro em log binário.

Execute o seguinte comando para verificar se o registro em log binário foi habilitado na origem:
```
SHOW VARIABLES LIKE 'log_bin';
```
Se a variável log_bin for retornada com o valor "ON", isso significa que o registro em log binário está habilitado no servidor.

Se log_bin for retornado com o valor "OFF" e o servidor de origem estiver em execução no local ou em máquinas virtuais em que você pode acessar o arquivo de configuração (my.cnf), você poderá seguir as etapas abaixo:
1. Localize o 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 MySQL para as alterações entrarem em vigor.
5. Depois que o servidor for reiniciado, verifique se o registro em log binário está habilitado executando a mesma consulta que antes:
```
SHOW VARIABLES LIKE 'log_bin';
```
Defina 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. Esse parâmetro é 1 por padrão no Banco de Dados do Azure para MySQL.
```
SET GLOBAL lower_case_table_names = 1;
```
Opcional – caso deseje usar a Replicação baseada em GTID, você precisará verificar se o GTID está habilitado no servidor de origem. Você pode executar o comando a seguir em seu servidor MySQL de origem para ver se gtid_mode estiver 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 habilitar GTID no servidor MySQL de origem especificamente para configurar a Replicação de Dados. Caso o GTID já esteja habilitado no servidor de origem, opcionalmente, você poderá usar a replicação baseada em GTID para configurar também a Replicação de Dados com o servidor único do Banco de Dados do Azure para MySQL. Você pode usar a replicação baseada em arquivos para configurar a replicação de dados para todos os servidores, independentemente da configuração do 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 que é configurado com privilégios de replicação. Isso pode ser feito por meio de comandos SQL ou de uma ferramenta como o Workbench do MySQL. Leve em conta se você planeja replicar com SSL, pois isso precisa ser especificado na criação do usuário. Confira a documentação do MySQL para entender como adicionar contas de usuário ao seu servidor de origem.

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

Comando SQL

Replicação com SSL

Para exigir SSL em 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 exigido 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'@'%';
```
Workbench do MySQL

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

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

Selecione o painel Funções administrativas painel e selecione Replicação subordinada na lista de Privilégios globais. Depois selecione Aplicar para criar a função de replicação.
Configure 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. No modo somente leitura, a origem será capaz de processar todas as transações de gravação. Avalie o impacto em seus negócios e agende a janela de somente leitura em um horário fora de pico, se necessário.
```
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
```

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

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

 show master status;

Os resultados devem ser semelhantes ao seguinte. Anote o nome do arquivo binário para ele ser usado em etapas posteriores.

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |      120 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

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 o mysqldump para despejar os bancos de dados do servidor primário. Para obter detalhes, consulte Despejar e restaurar. Não é necessário despejar as bibliotecas normal e de teste do MySQL.
Opcional – caso deseje usar a replicação baseada em gtid, você precisará identificar o GTID da última transação executada no primário. Você pode usar o comando a seguir para observar 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, retorne o servidor MySQL de origem ao modo de leitura/gravação.
```
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
```
Restaure arquivo de despejo no novo servidor.

Restaure o arquivo de despejo no servidor criado no serviço Banco de Dados do Azure para MySQL. Consulte Despejar e restaurar para saber como restaurar um arquivo de despejo em um servidor MySQL. Se o arquivo de despejo é grande, carregue-o em uma máquina virtual do Azure na mesma região do servidor de réplica. Restaure-o no serviço Banco de Dados do Azure para MySQL da máquina virtual.
Opcional – observe o GTID do servidor restaurado no Banco de Dados do Azure para MySQL para garantir que ele seja o mesmo que o servidor primário. Você pode usar o comando a seguir para anotar o GTID do valor do GTID limpo no servidor de réplica do Banco de Dados do Azure para MySQL. O valor do gtid_purged deve ser o mesmo que gtid_executed no mestre observado na Etapa 2 para que a replicação baseada no 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 nos dados são feitas por procedimentos armazenados. Você pode encontrar todos os procedimentos em Procedimentos armazenados de replicação nos dados. Os procedimentos armazenados podem ser executados no shell do MySQL ou no Workbench do MySQL.

Para vincular dois servidores e iniciar a replicação, faça logon no servidor de réplica de destino no serviço de Banco de Dados do Azure para MySQL e defina a instância externa como o servidor de origem. Isso é feito usando o procedimento armazenado mysql.az_replication_change_master no servidor do Banco de Dados do Azure para 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 – caso deseje usar a replicação baseada em gtid, você precisará usar o comando a seguir 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 do servidor de origem
- master_password: a senha para o servidor de origem
- master_port: número da porta na qual o servidor de origem está escutando conexões. (A 3306 é a porta padrão na qual o MySQL está escutando)
- master_log_file: nome de arquivo de log binário de show master status em execução
- master_log_pos: posição de log binário de show master status em execução
- master_ssl_ca: contexto do certificado da AC. Se não estiver usando SSL, passe em uma cadeia de caracteres vazia.
  
  É recomendável passar esse parâmetro como uma variável. Para obter mais informações, consulte os exemplos a seguir.
Observação

Se o servidor de origem estiver hospedado em uma VM do Azure, defina "Permitir acesso a serviços do Azure" como "ON" para permitir que os servidores de origem e de réplica se comuniquem entre si. Essa configuração pode ser alterada a partir das opções Segurança de conexão. Para obter mais informações, confira Gerenciar regras de firewall usando o portal.

Exemplos

Replicação com SSL

A variável @cert é criada executando os seguintes comandos do 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. Esse 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. Esse 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.

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

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 mysql.az_replication_start para iniciar a replicação.
```
CALL mysql.az_replication_start;
```
Verifique o status da replicação.

Chame o comando show slave status no servidor de réplica para exibir o status de replicação.
```
show slave status;
```
Se os estados de Slave_IO_Running e Slave_SQL_Running forem "yes" e o valor de Seconds_Behind_Master for "0", a replicação está funcionando bem. Seconds_Behind_Master indica o atraso da réplica. Se o valor não for "0", isso significa que a réplica está processando as 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 de réplica, use o seguinte procedimento armazenado:

CALL mysql.az_replication_stop;

Remover relação de replicação

Para remover o relacionamento 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 – caso queira usar a replicação baseada em gtid, use o procedimento armazenado a seguir para ignorar uma transação

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

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

Importante

Esse procedimento só pode ser usado para ignorar uma transação, não para ignorar os conjuntos gtid ou 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]

mysql> show binlog event is 'mysql-bin.000007' from 194 limit 10;
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                            |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------+
| mysql-bin.000007 | 194 | Gtid        |         2 |         259 | Set @@SESSION.GTID_NEXT= 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb' |
| mysql-bin.000007 | 259 | Query       |         2 |         331 | BEGIN                                                           |
| mysql-bin.000007 | 331 | Table_map   |         2 |         383 | table_id: 108 (test.testgtid)                                   |
| mysql-bin.000007 | 383 | Delete_rows |         2 |         463 | table_id: 108 flags: STMT_END_F                                 |
| mysql-bin.000007 | 463 | Xid         |         2 |         949 | COMMIT /* xid=14 */                                             |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------+
5 rows in set (0.00 sec)

Próximas etapas

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

Compartilhar via