Configurar MariaDB 11.4 com replicação assíncrona no Fedora 42

Configurar MariaDB 11.4 com replicação assíncrona no Fedora 42 é montar um primary que grava o binary log e uma replica que aplica os eventos depois do commit, sem bloquear a aplicação. Para colocar a topologia no ar com segurança, siga estes passos:

1. Instale MariaDB 11.4 nos dois nós Fedora 42 e sincronize relógio e firewall.
2. Habilite log_bin, server_id e GTID no primary; crie usuário REPLICATION SLAVE.
3. Faça dump consistente com --master-data e restaure na replica.
4. Aponte a replica ao primary com CHANGE MASTER e inicie o SQL thread.
5. Valide com SHOW REPLICA STATUS e teste leitura/escrita controlada.
6. Monitore lag, disco e rede antes de expor leituras de produção.

Pré-requisitos

• Dois servidores ou VPS com Fedora 42 atualizado (primary 203.0.113.10 e replica 203.0.113.11 nos exemplos).
• Acesso root ou sudo via SSH em ambos os nós.
• MariaDB 11.4 disponível nos repositórios oficiais ou no repositório MariaDB para Fedora.
• Porta TCP 3306 liberada somente do IP da replica para o primary no firewalld.
• Hostname resolvível ou entradas em /etc/hosts; NTP/chrony ativo.
• Espaço em disco para binlog no primary e para o dataset completo na replica.
• Backup recente antes de alterar bind-address ou recriar usuários de replicação.

Se você ainda está escolhendo entre hospedagem compartilhada e máquina própria para banco, o comparativo Hospedagem de sites vs. VPS: qual é a melhor opção? ajuda a dimensionar o ambiente. Para o primeiro acesso aos nós, use o fluxo de Acessando servidores VPS Linux da AviraHost.

Configurar MariaDB 11.4 com replicação assíncrona no Fedora 42 no primary

O binary log é a base da replicação assíncrona: cada commit elegível vira eventos que a replica consome depois. No Fedora 42, instale o servidor e garanta que o serviço sobe com systemd antes de editar a configuração.

sudo dnf install -y mariadb-server mariadb
sudo systemctl enable --now mariadb
sudo mysql_secure_installation

Output esperado:
Complete!
Created symlink ... mariadb.service
● mariadb.service - MariaDB 11.4 database server
     Active: active (running)

Edite o arquivo de configuração do servidor (em geral /etc/my.cnf.d/server.cnf) e defina identidade única, binlog e GTID de domínio. O server_id do primary deve ser diferente do da replica.

[mysqld]
server_id=1
log_bin=mysql-bin
binlog_format=ROW
expire_logs_days=7
gtid_domain_id=1
log_slave_updates=ON
bind-address=203.0.113.10
# opcional em redes privadas:
# skip-name-resolve

Reinicie e confira variáveis críticas:

sudo systemctl restart mariadb
sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('server_id','log_bin','gtid_domain_id','binlog_format');"

Output esperado:
+----------------+-----------+
| Variable_name  | Value     |
+----------------+-----------+
| binlog_format  | ROW       |
| gtid_domain_id | 1         |
| log_bin        | ON        |
| server_id      | 1         |
+----------------+-----------+

Crie o usuário exclusivo de replicação com o mínimo de privilégios. Não use root remoto nem senha fraca.

sudo mariadb <<'SQL'
CREATE USER 'repl'@'203.0.113.11' IDENTIFIED BY 'SenhaForte_Repl_2026';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'203.0.113.11';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;
SQL

Output esperado:
File: mysql-bin.000003
Position: 345
Binlog_Do_DB:
Binlog_Ignore_DB:

Anote File e Position se for configurar posição clássica; com GTID o failover fica mais simples depois. Libere o firewall só para o IP da replica:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.11" port port="3306" protocol="tcp" accept'
sudo firewall-cmd --reload
sudo ss -lntp | grep 3306

Atenção: abrir 3306 para 0.0.0.0/0 expõe o banco a varreduras na internet. Mantenha bind-address no IP privado ou da interface de réplica e restrinja a origem no firewalld.

Preparar dump consistente e a replica no Fedora 42

Snapshot lógico com posição de binlog evita “buraco” entre o backup e o START REPLICA. No primary, com carga controlada se possível, gere o dump de todas as bases de aplicação (ajuste --databases conforme o seu caso):

sudo mariadb-dump --single-transaction --master-data=2 --routines --triggers --all-databases \
  -uroot -p > /root/full-primary.sql
sudo scp /root/full-primary.sql [email protected]:/root/

Na replica, instale o mesmo MariaDB 11.4, aplique server_id distinto e parâmetros alinhados ao primary, porém sem receber escritas da aplicação:

sudo dnf install -y mariadb-server mariadb
sudo systemctl enable --now mariadb

[mysqld]
server_id=2
log_bin=mysql-bin
binlog_format=ROW
gtid_domain_id=1
log_slave_updates=ON
read_only=ON
super_read_only=ON
bind-address=203.0.113.11
relay_log=relay-bin

sudo systemctl restart mariadb
sudo mariadb < /root/full-primary.sql

Com o dataset restaurado, configure a origem. No MariaDB 11.4 a sintaxe CHANGE MASTER TO permanece válida; use o host do primary, o usuário repl e, se estiver em modo GTID, MASTER_USE_GTID=slave_pos após importar posições coerentes — ou informe MASTER_LOG_FILE e MASTER_LOG_POS lidos do cabeçalho do dump (--master-data=2 grava um comentário CHANGE MASTER no SQL).

sudo mariadb <<'SQL'
STOP REPLICA;
CHANGE MASTER TO
  MASTER_HOST='203.0.113.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='SenhaForte_Repl_2026',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mysql-bin.000003',
  MASTER_LOG_POS=345,
  MASTER_CONNECT_RETRY=10;
START REPLICA;
SHOW REPLICA STATUS\G
SQL

Output esperado (trechos):
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 0
Last_IO_Error:
Last_SQL_Error:

Confirme que a aplicação de escrita aponta só ao primary. Leituras de relatórios ou filas podem usar a replica quando Seconds_Behind_Source estiver estável perto de zero. Em ambientes com painel, o acesso remoto a bancos costuma seguir regras parecidas às de Conectando remotamente ao MySQL - cPanel, sempre com IP de origem restrito.

Validar lag, GTID e escala de leitura

Seconds_Behind_Source é o indicador operacional mais usado no dia a dia da replica MariaDB: ele estima o atraso entre o primary e a aplicação dos eventos. Após inserir dados de teste no primary, leia na replica.

# no primary
sudo mariadb -e "CREATE DATABASE IF NOT EXISTS lab_repl; USE lab_repl; CREATE TABLE t(id INT PRIMARY KEY, v VARCHAR(32)); INSERT INTO t VALUES (1,'ok-fedora42');"
# na replica
sudo mariadb -e "SELECT * FROM lab_repl.t; SHOW REPLICA STATUS\G" | head -n 40

Output esperado:
id      v
1       ok-fedora42
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 0

Para operação com GTID no MariaDB 11.4, mantenha gtid_domain_id coerente nos dois nós e documente o domínio usado em runbooks de failover. GTID não é obrigatório para a replicação assíncrona funcionar, mas reduz erro humano ao reapontar réplicas. Monitore também:

• Crescimento de mysql-bin.* no primary e política expire_logs_days ou purge controlado.
• Uso de disco do relay log na replica.
• Erros em /var/log/mariadb/mariadb.log após reinícios.
• Conectividade com ss e teste pontual mariadb -h 203.0.113.10 -urepl -p -e "SELECT 1" a partir da replica.

Se o serviço não subir após mudanças de cnf, o diagnóstico de unidades systemd descrito em Como solucionar problemas de inicialização de serviços no VPS Linux evita perder tempo em sintomas genéricos de “failed”.

Problemas comuns e como resolver

Sintoma: Replica_IO_Running: No e erro de autenticação

Causa: usuário repl criado para outro host, senha divergente ou firewall bloqueando 3306.
Solução: no primary, confira SELECT user,host FROM mysql.user WHERE user='repl'; e regrave a senha com ALTER USER. Na replica, STOP REPLICA; CHANGE MASTER TO com a senha correta; START REPLICA. Valide rich rule do firewalld e bind-address.

Sintoma: Replica_SQL_Running: No com erro de chave duplicada

Causa: escrita acidental na replica ou restore inconsistente que divergiu o dataset.
Solução: coloque read_only e super_read_only de volta, pare a aplicação que escreveu no nó errado, realinhe com novo dump do primary se a divergência for ampla, ou corrija o evento pontual só se souber exatamente o impacto. Evite SKIP de eventos em produção sem análise.

Sintoma: Seconds_Behind_Source sobe sem parar

Causa: rede lenta entre os nós, disco saturado na replica, queries longas no SQL thread ou primary gerando binlog em volume maior que a replica aplica.
Solução: meça I/O e CPU na replica, revise índices das tabelas quentes, evite cargas batch enormes sem janela, e confirme que não há lock prolongado. Cheques de rede (latência e perda) entre 203.0.113.10 e 203.0.113.11 costumam explicar picos de lag.

Sintoma: primary sem espaço por binlogs antigos

Causa: expire_logs_days ausente ou replica parada há dias ainda “precisando” de arquivos antigos.
Solução: recupere a replica primeiro; só então faça PURGE BINLOGS com critério seguro. Nunca apague arquivos mysql-bin.* no filesystem com rm enquanto o MariaDB estiver usando a sequência.

Perguntas frequentes sobre configurar MariaDB 11.4 com replicação assíncrona no Fedora 42

O que é replicação assíncrona no MariaDB 11.4?

Na replicação assíncrona o primary grava o binlog e a replica aplica os eventos depois, sem bloquear o commit da aplicação. Isso reduz latência de escrita e permite escalar leituras em outro nó no Fedora 42, com o trade-off de um atraso (lag) possível entre os servidores.

Preciso de GTID para replicar MariaDB 11.4 no Fedora 42?

GTID não é obrigatório, mas simplifica failover, reconfiguração e rastreio de posição no binlog. No MariaDB 11.4 em Fedora 42, habilitar gtid_domain_id e log_bin no primary e na replica deixa a troca de mestre e o troubleshooting bem mais previsíveis.

Qual porta e firewall liberar entre primary e replica?

A replica conecta na porta 3306 (ou a porta customizada) do primary. No Fedora 42 com firewalld, libere apenas o IP da replica para essa porta TCP, mantenha bind-address controlado e use usuário de replicação com REPLICATION SLAVE, nunca root remoto aberto à internet.

Como saber se a replica está em dia com o primary?

No nó replica execute SHOW REPLICA STATUS\G e confira Replica_IO_Running e Replica_SQL_Running como Yes, além de Seconds_Behind_Source próximo de zero. Atrase alto costuma indicar rede lenta, disco saturado ou consultas pesadas bloqueando a aplicação dos eventos.

Replicação assíncrona substitui backup do MariaDB?

Não. Replica protege disponibilidade e escala leitura, mas erros lógicos, DROP acidental ou corrupção podem se propagar. Mantenha dumps ou backups físicos testados do primary (e, se fizer sentido, da replica) além da topologia de replicação.

Conclusão

• Deixe primary e replica com server_id únicos, binlog ROW e firewall liberando só o IP da replica na porta do MariaDB 11.4.
• Use dump com --master-data, usuário repl dedicado e SHOW REPLICA STATUS até IO/SQL em Yes com lag próximo de zero.
• Trate a replica como escala de leitura e continuidade, nunca como substituto de backup testado.

Leia também

• Configurar MariaDB 11.4 no AlmaLinux 9: do padrão ao máximo
• Checklist MariaDB vs MySQL: diferenças que impactam sua hospedagem
• Como configurar MariaDB no Ubuntu 24.04 para WordPress

Precisa de ajuda com MariaDB e VPS no Fedora?

Um VPS com recursos previsíveis facilita manter primary e replica isolados, com rede privada e snapshots quando você for expandir a topologia. Se quiser dimensionar nós para banco e aplicação no mesmo provedor, avalie os planos adequados ao seu workload.

Ver servidores VPS AviraHost