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

Artigo
10/26/2023

Importante

O Banco de Dados do Azure para MariaDB está no caminho da aposentadoria. É altamente recomendável migrar 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 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 MariaDB.

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

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

Nota

Se o servidor de origem for a versão 10.2 ou mais recente, recomendamos que você configure a Replicação de Dados usando a ID de Transação Global.

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.

Criar um servidor MariaDB para usar como réplica

Crie um novo Banco de Dados do Azure para o servidor MariaDB (por exemplo, replica.mariadb.database.azure.com). O servidor é o servidor de réplica na Replicação Data-in.

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

Importante

Você deve criar o Banco de Dados do Azure para o servidor MariaDB nas camadas de preços de Uso Geral ou Memória Otimizada.
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 servidor de réplica. Para fornecer acesso de usuário ao servidor de réplica, você deve criar manualmente todas as contas e privilégios correspondentes no recém-criado Banco de Dados do Azure para o servidor MariaDB.
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.

Configurar o servidor de origem

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

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

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 o servidor de origem, você poderá usar o comando abaixo para determinar o endereço IP do seu Banco de Dados do Azure para o servidor MariaDB.
1. Entre no seu Banco de Dados do Azure para MariaDB usando uma ferramenta como a linha de comando MySQL.
2. Execute a consulta abaixo.
```
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. Execute o abaixo 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.
Nota

Este endereço IP pode mudar devido a operações de manutenção/implementaçã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.

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 será 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.
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. O lower_case_table_names parâmetro é definido como 1 por padrão 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 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 comandos SQL ou MySQL Workbench. Se você planeja replicar com SSL, você deve especificar isso 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.

Usando os comandos a seguir, a nova função de replicação pode acessar a origem de qualquer máquina, não apenas a máquina que hospeda a própria origem. Para esse acesso, especifique syncuser@'%' no comando para criar um usuário.

Para saber mais sobre a documentação do MariaDB, consulte Especificando nomes de contas.

Comando SQL
- Replicação com SSL
  
  Para exigir SSL para todas as conexões de usuário, digite 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, digite 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, no painel Gerenciamento , selecione Usuários e Privilégios. Em seguida, selecione Adicionar conta.

Introduza um nome de utilizador no campo Nome de início de sessão.

Selecione o painel Funções administrativas e, na lista de Privilégios Globais, selecione Escravo de replicação. Selecione Aplicar para criar a função de replicação.
Defina 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. Enquanto estiver no modo somente leitura, a fonte não pode processar nenhuma transação de gravação. Para ajudar a evitar o impacto nos negócios, agende a janela somente leitura durante um horário fora do pico.
```
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
```
Obtenha o nome e o deslocamento do arquivo de log binário atual.

Para determinar o nome e o deslocamento do arquivo de log binário atual, execute o comando show master status.
```
show master status;
```
Os resultados devem ser semelhantes à tabela seguinte:

Observe o nome do arquivo binário, porque ele será usado em etapas posteriores.
Obtenha a posição GTID (opcional, necessária para replicação com GTID).

Execute a função BINLOG_GTID_POS para obter a posição GTID para o nome do arquivo binlog correspondente e offset.
```
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.

Use mysqldump para despejar todos os bancos de dados do servidor de origem. Não é necessário despejar a biblioteca MySQL e a biblioteca de teste.

Para obter mais informações, consulte Despejar e restaurar.
Defina o servidor de origem para o modo de leitura/gravação.

Depois que o banco de dados for despejado, altere o servidor MariaDB 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 serviço Banco de Dados do Azure para MariaDB. Consulte Dump & Restore para saber como restaurar um arquivo de despejo para um servidor MariaDB.

Se o arquivo de despejo for grande, carregue-o em uma VM no Azure na mesma região do servidor de réplica. Restaure-o para o Banco de Dados do Azure para o servidor MariaDB a partir da VM.

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 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, entre no servidor de réplica de destino no serviço Banco de Dados do Azure para MariaDB. Em seguida, defina a instância externa como o servidor de origem 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 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 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_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_gtid_pos: Posição GTID da corrida select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
- master_ssl_ca: contexto do certificado de autoridade de certificação. Se você não estiver usando SSL, passe uma cadeia de caracteres vazia.*
*Recomendamos passar 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. Este 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. Este 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 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 Slave_IO_Running e estão no estado yes, e Slave_SQL_Running o valor de Seconds_Behind_Master é 0, a replicação está funcionando. Seconds_Behind_Master indica o quão tarde a réplica está. Se o valor não 0for , a réplica está processando atualizações.
Atualize as variáveis de servidor correspondentes para tornar a replicação de dados mais segura (necessária apenas para replicação sem GTID).

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

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

Outros procedimentos armazenados

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 a 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 o erro de replicação

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

CALL mysql.az_replication_skip_counter;

Próximos passos

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

Share via