A escalabilidade de bancos de dados é um dos desafios mais críticos para profissionais de TI que gerenciam infraestrutura em nuvem. Em ambientes de VPS, onde os recursos são compartilhados ou limitados, a necessidade de distribuir a carga de leitura e garantir a continuidade do serviço torna a replicação de dados uma solução indispensável. Neste tutorial técnico, exploraremos a implementação prática da replicação Master-Slave no MariaDB, focando em configuração robusta, segurança e monitoramento.
A arquitetura Master-Slave permite que escritas ocorram exclusivamente no servidor principal (Master), enquanto as leituras sejam distribuídas entre o Master e um ou mais servidores secundários (Slaves). Essa separação não apenas melhora a performance geral do banco de dados, mas também serve como base para estratégias de alta disponibilidade e disaster recovery. Vamos configurar dois nós em uma rede privada, garantindo que os dados se mantenham sincronizados com baixa latência.
1. Pré-requisitos e Topologia da Infraestrutura
Para garantir a consistência dos dados e a segurança da comunicação, é fundamental definir claramente os papéis de cada servidor. Recomendamos o uso de interfaces de rede privadas (VPC ou VLAN) para a comunicação de replicação, evitando que o tráfego de dados sensíveis trafegue pela internet pública.
A topologia adotada neste guia é composta por dois servidores Linux (Debian/Ubuntu ou CentOS/RHEL), ambos executando MariaDB 10.5 ou superior:
- MariaDB Master (Escrita): IP
192.168.1.10 - MariaDB Slave (Leitura): IP
192.168.1.20
Ambos os servidores devem ter o MariaDB instalado e atualizado. Certifique-se de que o firewall permita a comunicação na porta padrão 3306 apenas entre os IPs internos dessas máquinas. A consistência da versão do MariaDB é crucial; diferenças maiores podem causar incompatibilidades no formato do binlog.
2. Configurando o Servidor Master (Escrita)
O servidor Master é responsável por registrar todas as alterações de dados em um arquivo chamado binary log (binlog). O Slave consome esses logs para aplicar as mesmas operações localmente.
A primeira etapa é editar o arquivo de configuração principal do MariaDB, geralmente localizado em /etc/mysql/mariadb.conf.d/90-server.cnf ou /etc/my.cnf, dependendo da distribuição. Adicione ou modifique as seguintes diretrizes na seção [mysqld]:
[mysqld]
# Identificador único para este servidor no cluster
server-id = 1
# Ativa o binário log, essencial para a replicação
log_bin = /var/log/mysql/mariadb-bin
# Nome do banco de dados que será replicado. Use '*' para todos.
binlog_do_db = meu_app_db
# Define quanto tempo os logs são mantidos (ex: 7 dias)
expire_logs_days = 7
# Garante que o Slave receba um ID único se precisar ser Master de outro
max_binlog_size = 100MApós salvar as alterações, reinicie o serviço para aplicar a configuração:
sudo systemctl restart mariadbAgora, é necessário criar um usuário dedicado apenas para a replicação. Nunca utilize a conta root para replicação, pois isso representa um risco de segurança significativo se o Slave for comprometido.
mysql -u root -p
CREATE USER 'repl_user'@'192.168.1.20' IDENTIFIED BY 'SenhaForteAqui';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.20';
FLUSH PRIVILEGES;
EXIT;Com o usuário criado, vamos obter o estado atual do binlog para sincronizar o Slave a partir deste ponto exato. Execute no MariaDB:
SHOW MASTER STATUS;Anote os valores de File (nome do arquivo de log) e Position (posição do ponteiro). Esses dados serão críticos na configuração do Slave para evitar perda de transações.
3. Configurando o Servidor Slave (Leitura)
O servidor Slave deve ser configurado para ouvir as instruções vindas do Master e aplicá-las em sua base local. Edite novamente o arquivo de configuração no Slave (/etc/mysql/mariadb.conf.d/90-server.cnf). Adicione ou ajuste as seguintes linhas:
[mysqld]
# ID único diferente do Master (obrigatório)
server-id = 2
# Ativa o relay log, onde o Slave armazena temporariamente os eventos recebidos
relay_log = /var/log/mysql/relay-bin
# Garante que o Slave continue a replicação mesmo se falhar temporariamente
read_only = 1O parâmetro read_only = 1 é uma prática recomendada de segurança. Ele impede que escritas acidentais ocorram no Slave, mantendo a integridade dos dados. Usuários com privilégio SUPER ainda podem escrever, mas aplicações comuns receberão erro de permissão.
Reinicie o serviço MariaDB no Slave:
sudo systemctl restart mariadb4. Realizando a Sincronização Inicial (Snapshot)
Se já existirem dados no Master que precisam ser movidos para o Slave, é necessário realizar um snapshot consistente antes de iniciar o processo de replicação em tempo real. A ferramenta mariabackup ou o método tradicional com mysqldump são opções válidas. Para este tutorial, utilizaremos uma abordagem simples com travamento de tabelas para garantir consistência.
No Master, abra um shell e execute:
mysql -u root -p -e "FLUSH TABLES WITH READ LOCK;"
mysqldump -u root -p --all-databases --master-data=2 > backup_master.sql
mysql -u root -p -e "UNLOCK TABLES;"O comando --master-data=2 injeta no dump as instruções necessárias para configurar o Slave, facilitando a recuperação do ponto exato de sincronização. Copie o arquivo gerado para o Slave:
scp backup_master.sql [email protected]:/tmp/No Slave, importe o banco de dados:
mysql -u root -p < /tmp/backup_master.sql5. Ativando a Replicação no Slave
Agora que os dados estão sincronizados e as configurações de servidor foram aplicadas, conecte-se ao MariaDB no Slave e configure a conexão com o Master.
mysql -u root -p
STOP SLAVE; -- Garante que não há processos antigos rodando
CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl_user',
MASTER_PASSWORD='SenhaForteAqui',
MASTER_LOG_FILE='mariadb-bin.000001', -- Substitua pelo valor do SHOW MASTER STATUS
MASTER_LOG_POS=154; -- Substitua pelo valor da Position
START SLAVE;Se você utilizou o --master-data no dump, o Slave pode já ter as informações corretas. No entanto, verificar manualmente evita erros de "Off-by-one" ou falhas de conexão.
6. Verificação e Monitoramento da Saúde da Replicação
O sucesso da configuração é confirmado ao verificar o status do thread de replicação no Slave. Execute:
SHOW SLAVE STATUS\GObserve dois campos cruciais na saída:
- Slave_IO_Running: Deve ser
Yes. Este thread lê os eventos do binlog do Master. - Slave_SQL_Running: Deve ser
Yes. Este thread aplica os eventos lidos no banco local.
Se ambos forem "Yes", a replicação está ativa. O campo Last_IO_Error e Last_SQL_Error devem estar vazios. Se houver erros, leia as mensagens para diagnosticar problemas de conexão, permissão ou inconsistência de dados.
7. Boas Práticas de Tuning e Performance
A replicação não é "configurar e esquecer". Para garantir que o Slave acompanhe o ritmo do Master em ambientes de alta carga, ajustes de performance são necessários.
Otimização do Relay Log: No arquivo de configuração do Slave, considere aumentar o tamanho do buffer de relay log para reduzir a latência de escrita em disco:
relay_log_info_repository = TABLE
master_info_repository = TABLEUsar tabelas (TABLE) em vez de arquivos (FILE) para armazenar o estado da replicação oferece maior resiliência contra quedas de energia e facilita a recuperação automática após reinicializações.
Monitoramento de Delay: Em cenários críticos, monitore o Seconds_Behind_Master. Um valor alto indica que o Slave está com dificuldade de aplicar as transações. Isso pode ser causado por I/O lento no disco ou CPU saturada. Considere usar ferramentas como mha-manager ou soluções de monitoramento da Toda Solução para alertas proativos.
8. Considerações Finais sobre Alta Disponibilidade
A replicação Master-Slave é o primeiro passo para uma infraestrutura resiliente. No entanto, ela não protege contra a falha do Master. Se o servidor principal cair, o Slave não assume automaticamente as escritas nesta configuração básica.
Para alcançar alta disponibilidade real (failover automático), considere implementar soluções como MariaDB Galera Cluster (replicação síncrona multi-master) ou ferramentas de orquestração como MHA (Master High Availability). Estas soluções adicionam complexidade, mas garantem que seu serviço permaneça online mesmo durante falhas de hardware.
Lembre-se sempre de testar seus backups e procedimentos de failover em um ambiente de staging antes de aplicar em produção. A consistência dos dados é o ativo mais valioso da sua aplicação.