Configurar a replicação de dados no Banco de Dados do Azure para MariaDB

Artigo
06/01/2023

Importante

O Banco de Dados do Azure para MariaDB está a caminho da desativação. É altamente recomendável que você migre para o Banco de Dados do Azure para MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para MariaDB?.

Este artigo descreve como configurar a replicação de dados no Banco de Dados do Azure para MariaDB por meio da definição dos servidores de origem e de réplica. Pressupõe-se que você tenha alguma experiência anterior com os servidores e bancos de dados MariaDB.

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

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

Observação

Para servidores de origem da versão 10.2 ou mais recente, recomenda-se configurar a replicação de dados com o ID de transação global.

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.

Criar um servidor MariaDB para usar como réplica

Crie um novo servidor de Banco de Dados do Azure para MariaDB (por exemplo, replica.mariadb.database.azure.com). Ele será o servidor de réplica na replicação nos dados.

Para saber mais sobre a criação de servidor, consulte Criar um servidor de Banco de Dados do Azure para MariaDB no portal do Azure.

Importante

Crie o servidor de Banco de Dados do Azure para MariaDB nas camadas de preço "Propósito geral" ou "Otimizado para memória".
Crie contas de usuário idênticas e privilégios correspondentes.

As contas de usuário não são replicadas do servidor de origem para o de réplica. Para dar ao usuário o acesso ao servidor de réplica, crie manualmente todas as contas e os privilégios correspondentes no novo servidor de Banco de Dados do Azure para MariaDB 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.

Configurar o servidor de origem

As etapas a seguir preparam e configuram o servidor MariaDB hospedado no local, em uma VM ou em um serviço de banco de dados em nuvem para a replicação de dados. O servidor MariaDB é a origem na replicação de dados.

Analise os requisitos do servidor primário antes de continuar.
Verifique se o servidor de origem permite o tráfego de entrada e de saída na porta 3306, além de ter um endereço IP público, o DNS acessível publicamente ou um FQDN (nome de domínio totalmente qualificado).

Teste a conectividade com o servidor de origem tentando se conectar por uma ferramenta como a linha de comando do MySQL hospedada em outro computador ou o Azure Cloud Shell disponível no portal do Azure.

Se sua organização tiver políticas de segurança estritas e não permitir que todos os endereços IP no servidor de origem habilitem a comunicação do Azure com ele, será possível usar o comando a seguir para determinar o endereço IP do servidor de Banco de Dados do Azure para MariaDB.
1. Conecte-se ao Banco de Dados do Azure para MariaDB por meio de uma ferramenta como a linha de comando do MySQL.
2. Execute a consulta abaixo.
```
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. Faça o seguinte no utilitário ping para obter o endereço IP.
```
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

Ele 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 log binário.

Para ver se o log binário está habilitado no primário, digite o seguinte comando:
```
SHOW VARIABLES LIKE 'log_bin';
```
Se a variável log_bin retornar o valor ON, o log binário estará habilitado no servidor.

Se log_bin retornar o valor OFF, edite o arquivo my. cnf para que log_bin=ON ative o log binário. Reinicie o servidor para que a alteração entre em vigor.
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. O parâmetro lower_case_table_names é configurado por padrão como 1 no Banco de Dados do Azure para MariaDB.
```
SET GLOBAL lower_case_table_names = 1;
```
Crie uma nova função de replicação e configure as permissões.

Crie uma conta de usuário no servidor de origem configurada com privilégios de replicação. Você pode criar uma conta usando os comandos SQL ou o MySQL Workbench. Para a replicação com SSL, especifique a opção ao criar a conta de usuário.

Para saber como adicionar contas de usuário ao servidor de origem, consulte a Documentação do MariaDB.

Com os comandos a seguir, a nova função de replicação criada pode acessar a origem em qualquer computador, não apenas naquele que a hospeda. Para habilitar esse acesso, especifique syncuser@'%' no comando para criar um usuário.

Para saber mais sobre a documentação do MariaDB, consulte Especificando 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
  
  Para não exigir SSL em 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 MySQL Workbench, abra o painel Gerenciamento e selecione Usuários e privilégios. Em seguida, selecione Adicionar conta.

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

Abra o painel Funções administrativas e, na lista de Privilégios globais, selecione Servidor subordinado da replicação. Selecione Aplicar para criar a função de replicação.
Configure o servidor de origem para o modo somente leitura.

Antes de despejar um banco de dados, o servidor deve ser colocado no modo somente leitura. Nesse modo, a origem não será capaz de processar transações de gravação. Para evitar impactos nos negócios, agende a janela relativa ao modo somente leitura fora do horário de pico.
```
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
```
Obtenha 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 a tabela a seguir:

Anote o nome do arquivo binário para usá-lo em etapas posteriores.
Obtenha a posição de GTID (opcional; necessário para a replicação com GTID).

Execute a função BINLOG_GTID_POS para obter a posição de GTID para o nome e o deslocamento do arquivo de log binário correspondente.
```
select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
```

Despejar e restaurar o servidor de origem

Despeje todos os bancos de dados do servidor de origem.

Para isso, use mysqldump. Não é necessário despejar as bibliotecas MySQL e de teste.

Para saber mais, consulte Despejo e restauração.
Defina o servidor de origem para o modo de leitura/gravação.

Depois do despejo do banco de dados, retorne o servidor MariaDB de origem para o modo de leitura/gravação.
```
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
```
Restaure arquivo de despejo no novo servidor.

Restaure o arquivo de despejo para o servidor criado no banco de dados do Azure para o serviço MariaDB. Consulte Despejo e restauração para saber como restaurar um arquivo de despejo em um servidor MariaDB.

Se o arquivo for grande, carregue-o em uma VM do Azure na mesma região do servidor de réplica. Em seguida, restaure-o dessa VM para o servidor de Banco de Dados do Azure para MariaDB.

Vincular os 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 MySQL Workbench.

Para vincular dois servidores e iniciar a replicação, conecte-se ao servidor de réplica de destino no serviço de Banco de Dados do Azure para MariaDB. Em seguida, defina a instância externa como o servidor de origem usando o procedimento armazenado mysql.az_replication_change_master ou mysql.az_replication_change_master_with_gtid no servidor de BD do Azure para MariaDB.
```
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');
```
ou
```
CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', 3306, '<master_gtid_pos>', '<master_ssl_ca>');
```
- master_host: nome de host do servidor de origem
- master_user: nome de usuário do servidor de origem
- master_password: senha do servidor de origem
- 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_gtid_pos: posição de GTID da execução select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
- master_ssl_ca: contexto do certificado da autoridade de certificação. Se você não estiver usando SSL, transmita uma cadeia de caracteres vazia.*
*Recomenda-se transmitir o parâmetro master_ssl_ca como uma variável. Para obter mais informações, consulte os exemplos a seguir.

Exemplos
- Replicação com SSL
  
  Crie a variável @cert executando os seguintes comandos:
```
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 MariaDB. Esse procedimento armazenado é executado na réplica.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mariadb-bin.000016', 475, @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 MariaDB. Esse procedimento armazenado é executado na réplica.
```
CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mariadb-bin.000016', 475, '');
```
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;
```
A replicação estará funcionando se Slave_IO_Running e Slave_SQL_Running estiverem no estado yes e o valor de Seconds_Behind_Master for 0. Seconds_Behind_Master indica o atraso da réplica. Se o valor não for 0, a réplica estará processando as atualizações.
Atualize as variáveis de servidor correspondentes para tornar a replicação de dados mais segura (necessário apenas para a replicação sem GTID).

Devido a uma limitação de replicação nativa no MariaDB, você deve definir as variáveis sync_master_info e sync_relay_log_info no cenário de replicação sem GTID.

Verifique as variáveis sync_master_info e sync_relay_log_info do servidor de réplica para garantir que a replicação de dados esteja estável e defina as variáveis como 1.

Outros procedimentos armazenados

Parar replicação

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

CALL mysql.az_replication_stop;

Remover a relação de replicação

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

CALL mysql.az_replication_remove_master;

Ignorar o 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;

Próximas etapas

Saiba mais sobre Replicação de entrada de dados para o Banco de Dados do Azure para o MariaDB.