10 min de leitura · Guia técnico
MariaDB 11.4 com Replicação Mestre-Escravo é uma arquitetura de alta disponibilidade onde um servidor principal (mestre) processa todas as operações de escrita e replica esses dados para um ou mais servidores secundários (escravos). Para configurar este ambiente no Alpine Linux 3.22, siga estes passos:
- Instale o MariaDB 11.4 em ambos os servidores utilizando o gerenciador de pacotes apk.
- Configure o arquivo my.cnf no mestre com um server-id exclusivo e habilite o log-bin.
- Crie um usuário de replicação no mestre com privilégios específicos de REPLICATION SLAVE.
- Realize o backup dos dados atuais e identifique as coordenadas do log binário (File e Position).
- Configure o nó escravo com as credenciais do mestre e inicie o processo de sincronização.
Pré-requisitos
- Dois servidores VPS com Alpine Linux 3.22 instalado (Mestre e Escravo).
- Acesso root ou privilégios sudo em ambas as instâncias.
- Conectividade de rede entre os servidores (preferencialmente via rede privada).
- MariaDB 11.4 ou superior disponível nos repositórios oficiais.
- Porta 3306 aberta no firewall para comunicação entre os nós.
Configurando a replicação de dados MariaDB no nó mestre
A replicação de dados MariaDB exige que o servidor mestre registre todas as alterações em arquivos de log binários. No Alpine Linux 3.22, o gerenciamento de serviços é feito pelo OpenRC, o que torna o processo extremamente leve e rápido. O primeiro passo é garantir que o MariaDB esteja instalado e ouvindo em todas as interfaces de rede necessárias, não apenas no localhost.
apk update
apk add mariadb mariadb-client
rc-service mariadb start
rc-update add mariadb default
Após a instalação, edite o arquivo de configuração, geralmente localizado em /etc/my.cnf.d/mariadb-server.cnf. Você deve definir um ID único para o servidor e ativar o log binário, que é o motor da replicação.
[mariadb]
log-bin = mysql-bin
server-id = 1
bind-address = 0.0.0.0
Reinicie o serviço para aplicar as mudanças: rc-service mariadb restart. Agora, acesse o console do MariaDB e crie o usuário que o escravo usará para se conectar. Substitua 'IP_DO_ESCRAVO' pelo endereço real do seu servidor secundário.
CREATE USER 'replicador'@'IP_DO_ESCRAVO' IDENTIFIED BY 'sua_senha_segura';
GRANT REPLICATION SLAVE ON *.* TO 'replicador'@'IP_DO_ESCRAVO';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;
Output esperado: Uma tabela mostrando o nome do arquivo (ex: mysql-bin.000001) e a posição (ex: 450). Anote esses valores, pois eles serão fundamentais para sincronizar o escravo.
Implementando alta disponibilidade no Alpine Linux com o nó escravo
Para garantir a alta disponibilidade no Alpine Linux, o nó escravo deve ser configurado para ler os logs gerados pelo mestre. Uma das grandes vantagens de utilizar o Alpine 3.22 é o consumo mínimo de memória RAM, o que permite que o banco de dados utilize quase todo o recurso disponível para cache de índices e buffers de leitura. No escravo, a instalação segue o mesmo padrão do mestre, mas a configuração no my.cnf difere ligeiramente.
[mariadb]
server-id = 2
read-only = 1
O parâmetro read-only = 1 é uma boa prática para evitar que aplicações escrevam acidentalmente no escravo, o que causaria uma divergência de dados e interromperia a replicação. Após reiniciar o serviço no escravo, você deve apontá-lo para o mestre utilizando as coordenadas obtidas anteriormente.
STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='IP_DO_MESTRE',
MASTER_USER='replicador',
MASTER_PASSWORD='sua_senha_segura',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=450;
START SLAVE;
Para verificar se a conexão foi estabelecida com sucesso, execute o comando SHOW SLAVE STATUS\G;. Você deve procurar pelas linhas Slave_IO_Running: Yes e Slave_SQL_Running: Yes. Se ambas estiverem como "Yes", seu sistema de redundância está operacional.
Otimização de performance em VPS com MariaDB 11.4
A otimização de performance em VPS rodando MariaDB 11.4 no Alpine Linux 3.22 é potencializada pela biblioteca musl libc, que é mais eficiente em termos de alocação de memória do que a glibc tradicional. Em um cenário de replicação, é vital ajustar o innodb_flush_log_at_trx_commit. No mestre, manter o valor em 1 garante durabilidade máxima, enquanto no escravo, você pode alterar para 2 ou 0 para acelerar a aplicação dos logs, caso a consistência imediata em caso de queda de energia não seja a prioridade absoluta no nó de leitura.
Além disso, considere o uso de links simbólicos para os logs binários se você possuir volumes de armazenamento distintos. Para entender melhor como gerenciar esses recursos, veja nossas Dicas de Otimização de Servidores Linux. O MariaDB 11.4 introduziu melhorias significativas no otimizador de consultas, o que reduz o overhead de CPU durante a replicação paralela (Multi-Source Replication), permitindo que o escravo processe múltiplas transações simultaneamente sem atrasar o Seconds_Behind_Master. Para ativar a replicação paralela, defina slave_parallel_threads = 4 (ou um valor correspondente ao número de núcleos disponíveis) no arquivo my.cnf do escravo e reinicie o serviço.
Outro ponto crucial é o ajuste do max_allowed_packet. Se sua aplicação lida com campos BLOB grandes, certifique-se de que este valor seja idêntico em ambos os servidores para evitar erros de truncamento durante o transporte dos logs binários pela rede.
Segurança de banco de dados Linux e logs binários
A segurança de banco de dados Linux não deve ser negligenciada ao expor a porta 3306 para replicação. No Alpine Linux, recomendamos o uso do awall ou nftables para restringir o acesso à porta do MariaDB apenas ao IP do servidor parceiro. Além disso, a versão 11.4 suporta criptografia nativa para o tráfego de replicação, o que protege os dados contra interceptação (sniffing) na rede.
Os logs binários do banco de dados podem crescer rapidamente, consumindo todo o espaço em disco se não forem gerenciados. Configure a variável expire_logs_days ou binlog_expire_logs_seconds no mestre para remover automaticamente logs antigos após um período de retenção seguro (geralmente 3 a 7 dias). Se você ainda tem dúvidas sobre como o ambiente virtualizado influencia esses recursos, confira nosso artigo Compreendendo o Servidor VPS: O que é e Como Funciona!.
Atenção: Nunca apague os arquivos de log binário manualmente via terminal (rm). Use sempre o comando SQL PURGE BINARY LOGS para garantir que o índice do MariaDB permaneça consistente e não quebre a replicação ativa.
Problemas comuns e como resolver
Sintoma: Slave_IO_Running: No
Causa: Geralmente relacionado a problemas de rede, credenciais incorretas do usuário de replicação ou firewall bloqueando a porta 3306.
Solução: Verifique se consegue pingar o mestre a partir do escravo e teste a conexão manual usando mysql -u replicador -p -h IP_DO_MESTRE. Certifique-se de que o bind-address no mestre não está definido apenas para 127.0.0.1.
Sintoma: Erro de Duplicate Entry (1062) no Escravo
Causa: Ocorre quando alguém insere dados manualmente no escravo que conflitam com uma nova inserção vinda do mestre.
Solução: Ative o modo read_only no escravo. Para corrigir o erro atual, você pode usar SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;, mas tenha cuidado, pois isso pode causar inconsistência de dados.
Sintoma: Seconds_Behind_Master aumentando constantemente
Causa: O escravo não consegue processar as transações na mesma velocidade que o mestre as gera, muitas vezes devido a gargalos de I/O de disco ou CPU única.
Solução: Habilite a replicação paralela configurando slave_parallel_threads com um valor maior que 0 no arquivo de configuração do escravo.
Perguntas frequentes sobre MariaDB 11.4 com Replicação Mestre-Escravo
O que é a replicação mestre-escravo no MariaDB 11.4?
É um processo onde os dados de um servidor principal (mestre) são copiados automaticamente para um ou mais servidores secundários (escravos). Isso permite distribuir a carga de leitura e criar redundância de dados para recuperação de desastres.
Por que utilizar o Alpine Linux 3.22 para bancos de dados?
O Alpine Linux 3.22 é focado em segurança e minimalismo, utilizando a biblioteca musl libc e BusyBox. Sua pegada leve reduz a superfície de ataque e o consumo de recursos, sendo ideal para instâncias MariaDB em ambientes de alta densidade.
Como verificar se a replicação do MariaDB está funcionando?
No servidor escravo, execute o comando 'SHOW SLAVE STATUS\G;' e verifique se os campos Slave_IO_Running e Slave_SQL_Running estão marcados como 'Yes'. Isso confirma que o transporte e a execução dos logs binários estão ativos.
É possível configurar replicação MariaDB entre distribuições diferentes?
Sim, a replicação do MariaDB é baseada em logs binários e é compatível entre diferentes distribuições Linux, desde que as versões do MariaDB sejam compatíveis. No entanto, manter a mesma versão 11.4 em ambos os nós evita inconsistências de sintaxe.
Conclusão
- A replicação mestre-escravo é essencial para escalabilidade de leitura e segurança de dados em aplicações críticas.
- O Alpine Linux 3.22 oferece o ambiente mais leve possível para rodar MariaDB 11.4, maximizando o uso de hardware do VPS.
- Monitorar o status da replicação e manter o nó escravo em modo somente leitura são práticas indispensáveis para a estabilidade do cluster.
Leia também
- Como Instalar e Configurar o MariaDB no VPS Linux para Bancos de Dados Rápidos e Seguros
- Otimizar MariaDB 10.11 no Rocky Linux 9: tuning essencial
- Como Instalar e Configurar o Failover de Rede no VPS Linux para Alta Disponibilidade
Precisa de ajuda com MariaDB 11.4 com Replicação Mestre-Escravo?
Configurar clusters de banco de dados exige precisão técnica e uma infraestrutura robusta para evitar latência entre os nós. Nossa equipe de especialistas pode auxiliar na configuração, monitoramento e suporte especializado para o seu ambiente MariaDB em produção.
Fale com nossos especialistas em suporte e infraestrutura VPS