Como configurar réplica de leitura para um banco MySQL no VPS imprimir

Réplica de leitura para MySQL no VPS: o que é e por que ela ajuda seu site a voar

Oi! Aqui é a Sensei da GeHost 🌱 Hoje vamos falar de um assunto que parece complicado, mas prometo destrinchar com calma: a réplica de leitura (ou "read replica") do seu banco de dados MySQL. Se o seu site ou sistema está crescendo e as consultas ao banco estão deixando tudo mais lento, esse é um dos caminhos mais elegantes para aliviar a carga.

Primeiro, o que é uma réplica de leitura?

Imagine que seu banco de dados principal (o "primário") é o único atendente de uma loja super movimentada: ele recebe pedidos novos (gravações) e responde perguntas de todo mundo (leituras) ao mesmo tempo. Uma réplica de leitura é como contratar um segundo atendente que fica de olho em tudo que o primeiro faz e mantém uma cópia atualizada — só que esse segundo atendente apenas responde perguntas, nunca recebe pedidos novos diretamente.

Na prática: o servidor primário continua recebendo todas as gravações (INSERT, UPDATE, DELETE) e replica essas mudanças automaticamente para um segundo servidor MySQL, chamado de réplica. Seu sistema então pode direcionar as consultas de leitura (SELECT) para a réplica, aliviando o servidor principal.

💡 Dica da Sensei: essa técnica é ótima para relatórios pesados, dashboards e sistemas com muito mais leitura do que escrita. Mas ela não resolve tudo — se o problema é uma consulta mal otimizada, replicar só vai espalhar o mesmo problema para dois lugares. Vale sempre revisar índices e queries antes.

Antes de começar: o que você vai precisar

Este é um procedimento de administração de servidor, feito via linha de comando (SSH), e não pelo cPanel. Ele pressupõe que você tenha acesso administrativo (root) ao ambiente onde o MySQL/MariaDB está instalado — seja em um VPS próprio, seja em um servidor dedicado.

• Dois servidores MySQL (ou MariaDB) rodando: um será o primário e outro a réplica;
• Acesso via SSH com privilégios administrativos em ambos;
• Uma janela de manutenção, pois vamos reiniciar o serviço do MySQL no primário;
• Uma cópia de segurança recente do banco (nunca custa ter um backup fresquinho antes de mexer em configuração de banco).

Se o seu ambiente é um plano de hospedagem compartilhada em cPanel (sem acesso root/SSH), esse tipo de configuração não é feita pelo próprio painel — nesse caso, fale com o nosso suporte para entender a melhor forma de atender à sua necessidade dentro do seu plano.

Passo 1 — Preparar o servidor primário

No servidor que vai ser o "primário", edite o arquivo de configuração do MySQL (geralmente my.cnf ou um arquivo dentro de /etc/mysql/mysql.conf.d/) e garanta que estas linhas estejam presentes, dentro da seção [mysqld]:

1. server-id = 1 — um número único que identifica esse servidor na "família" de replicação;
2. log_bin = mysql-bin — ativa o chamado "binary log", o diário de bordo de tudo que é gravado no banco;
3. binlog_do_db = nome_do_seu_banco — opcional, usado se você quiser replicar apenas um banco específico.

Depois de salvar, reinicie o serviço do MySQL para as mudanças entrarem em vigor.

Passo 2 — Criar um usuário exclusivo para replicação

Ainda no primário, conecte-se ao MySQL e crie um usuário que a réplica vai usar só para "escutar" as mudanças — nunca use o usuário administrativo do seu sistema para isso:

1. CREATE USER 'replica_user'@'%' IDENTIFIED BY 'uma-senha-bem-forte';
2. GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
3. FLUSH PRIVILEGES;

🔒 Dica da Sensei: troque o '%' pelo IP específico do servidor de réplica sempre que possível. Deixar aberto para qualquer origem é um convite indesejado para quem não deveria estar batendo à sua porta.

Passo 3 — Anotar a posição do log binário

Com o usuário criado, rode no primário:

SHOW MASTER STATUS;

Isso vai devolver duas informações importantes: o nome do arquivo de log (algo como mysql-bin.000001) e a posição (um número). Anote os dois — você vai precisar deles daqui a pouco.

Passo 4 — Exportar e importar os dados atuais

Agora é hora de dar à réplica uma "fotografia" do banco no momento exato da posição anotada acima:

1. No primário, gere um backup com mysqldump --single-transaction --routines --triggers -u usuario -p nome_do_banco > backup.sql;
2. Transfira esse arquivo com segurança para o servidor da réplica (por exemplo, via scp);
3. No servidor da réplica, importe com mysql -u usuario -p nome_do_banco < backup.sql.

Passo 5 — Configurar o servidor da réplica

No arquivo de configuração do MySQL da réplica, defina um server-id diferente do primário — por exemplo:

server-id = 2

Reinicie o serviço do MySQL na réplica para aplicar.

Passo 6 — Conectar a réplica ao primário

Ainda na réplica, conecte-se ao MySQL e informe ao servidor onde ele deve "ouvir" as mudanças (nas versões mais recentes do MySQL/MariaDB o comando pode ser CHANGE REPLICATION SOURCE TO; em versões um pouco mais antigas é CHANGE MASTER TO — confira a versão do seu MySQL):

CHANGE MASTER TO
MASTER_HOST='endereço_do_servidor_primario',
MASTER_USER='replica_user',
MASTER_PASSWORD='uma-senha-bem-forte',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=12345;

Troque MASTER_LOG_FILE e MASTER_LOG_POS pelos valores que você anotou no Passo 3.

Passo 7 — Ligar a réplica

Agora é só dar a largada:

START SLAVE; (ou START REPLICA; nas versões mais novas)

Para conferir se está tudo em ordem, rode:

SHOW SLAVE STATUS\G

Fique de olho em duas linhas nessa resposta: Slave_IO_Running e Slave_SQL_Running. As duas precisam estar como Yes. Se alguma delas estiver diferente, o campo Last_Error, logo abaixo, costuma dar a pista do que precisa ser ajustado.

Depois de configurada, e agora?

Com a réplica funcionando, o próximo passo é direcionar as consultas de leitura da sua aplicação para o novo servidor — isso geralmente é feito na camada da aplicação ou em uma ferramenta de balanceamento, e não no banco em si. Vale conversar com quem desenvolve o seu sistema para fazer esse ajuste com segurança.

🌱 Dica final da Sensei: acompanhe de tempos em tempos o valor de Seconds_Behind_Master no SHOW SLAVE STATUS. Ele mostra o quão "atrasada" a réplica está em relação ao primário. Um pouquinho de atraso é normal, mas se esse número ficar crescendo sem parar, é sinal de que algo precisa de atenção.

Se em algum ponto do caminho você travar ou preferir ter alguém especializado ao seu lado, não hesite em chamar o nosso suporte pelo painel.gehost.com.br. Configuração de replicação é coisa séria e estamos aqui para ajudar você a fazer isso com tranquilidade. Até a próxima! 💚