Replicação MySQL Master-Slave para servidores de MU Online

Replicação MySQL Master-Slave é a técnica mais usada para dar redundância e distribuir carga de leitura em servidores de MU Online que já ultrapassaram o estágio inicial e precisam de mais confiabilidade. Diferente de um backup estático, a réplica fica constantemente sincronizada com o banco principal, permitindo tanto contingência contra falhas quanto alívio de carga em consultas pesadas. Este tutorial detalha a configuração completa usando GTID (o método recomendado atualmente), monitoramento de lag e o procedimento de promoção do slave.

O que é replicação Master-Slave e quando faz sentido implementar

Na replicação Master-Slave, o servidor master recebe todas as escritas (tudo que o GameServer grava: login, criação de personagem, movimentação de itens, level up) e registra cada transação em um log binário (binlog). O servidor slave lê esse binlog continuamente e aplica as mesmas mudanças em sua própria cópia do banco. Faz sentido implementar quando o servidor já tem população estável, quando consultas administrativas/relatórios começam a impactar a performance do banco principal, ou como base para um plano de contingência mais sério do que apenas backups periódicos.

Pré-requisitos técnicos

• Duas instâncias MySQL/MariaDB na mesma versão major (evita incompatibilidade de replicação).
• Rede confiável entre os dois servidores, idealmente privada/VPN.
• Espaço em disco no slave equivalente ou maior que o master.
• Acesso root a ambas as instâncias para configuração inicial.
• Janela de manutenção de baixo movimento para o dump inicial.

Habilitando GTID no servidor master

GTID (Global Transaction Identifier) simplifica drasticamente a configuração e a recuperação de replicação, eliminando a necessidade de rastrear manualmente arquivo e posição do binlog. No my.cnf do master:

[mysqld]
server-id = 1
log_bin = mysql-bin
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW

Reinicie o serviço MySQL após a alteração.

Criando o usuário de replicação

CREATE USER 'repl_mu'@'%' IDENTIFIED BY 'SenhaForteReplicacao456';
GRANT REPLICATION SLAVE ON *.* TO 'repl_mu'@'%';
FLUSH PRIVILEGES;

Restrinja o % para o IP específico do slave sempre que possível, reduzindo a superfície de ataque desse usuário privilegiado.

Fazendo o dump inicial do banco

Com o master ainda rodando, gere um dump consistente incluindo a posição de GTID:

mysqldump --all-databases --single-transaction --gtid --master-data=2 \
  -u root -p > dump_inicial_mu.sql

A flag --single-transaction evita lock prolongado em tabelas InnoDB (a engine padrão das tabelas de contas na maioria dos emuladores), reduzindo o impacto no GameServer durante a exportação.

Restaurando o dump no slave

Transfira o arquivo ao servidor slave e importe:

scp dump_inicial_mu.sql usuario@ip_do_slave:/tmp/
mysql -u root -p < /tmp/dump_inicial_mu.sql

Configurando o slave com GTID

No my.cnf do slave:

[mysqld]
server-id = 2
log_bin = mysql-bin
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON

Reinicie o MySQL do slave e configure a conexão com o master:

CHANGE MASTER TO
  MASTER_HOST='ip_do_master',
  MASTER_USER='repl_mu',
  MASTER_PASSWORD='SenhaForteReplicacao456',
  MASTER_AUTO_POSITION = 1;
START SLAVE;

Validando o funcionamento da replicação

SHOW SLAVE STATUS\G

Confirme Slave_IO_Running: Yes, Slave_SQL_Running: Yes e observe Seconds_Behind_Master. Um teste prático adicional é criar um personagem de teste no GameServer conectado ao master e verificar, poucos segundos depois, se o registro aparece no slave via consulta direta.

Tabela de parâmetros importantes de configuração

Monitorando o lag de replicação continuamente

Configure um script simples que roda a cada minuto e alerta se Seconds_Behind_Master ultrapassar um limite aceitável (recomendação: 5-10 segundos para servidores de MU, onde a experiência do jogador depende de dados atualizados rapidamente):

#!/bin/bash
LAG=$(mysql -u root -p"senha" -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master | awk '{print $2}')
if [ "$LAG" -gt 10 ]; then
  echo "ALERTA: lag de replicação em ${LAG}s" | ./notify_discord.sh
fi

Usando o slave para aliviar carga de leitura

Depois de validada a replicação, redirecione consultas de leitura não-críticas para o slave: relatórios administrativos do painel web, rankings, consultas de auditoria e estatísticas. Mantenha todas as escritas e leituras críticas em tempo real (login, verificação de item durante troca) apontadas para o master, já que o slave pode ter alguns segundos de atraso.

Procedimento de promoção do slave em caso de falha do master

Quando o master falha, o slave precisa ser promovido manualmente (sem uma ferramenta de orquestração automatizada):

1. Confirme que o master está realmente indisponível (não é apenas lentidão de rede).
2. No slave, execute STOP SLAVE; e depois RESET SLAVE ALL; para removê-lo do modo réplica.
3. Desative read_only (SET GLOBAL read_only = OFF;).
4. Reaponte a connection string do GameServer e do painel web para o IP do (agora ex-)slave.
5. Assim que o antigo master voltar, reconfigure-o como slave do novo master antes de reintroduzi-lo, nunca o contrário.

Erros comuns e soluções

Checklist de replicação MySQL Master-Slave

• GTID habilitado em master e slave (gtid_mode = ON).
• Usuário de replicação criado com permissão mínima necessária.
• Dump inicial feito com --single-transaction --gtid e restaurado no slave.
• SHOW SLAVE STATUS confirmando IO e SQL threads rodando.
• read_only ativado no slave para prevenir escrita acidental.
• Monitoramento de lag configurado com alerta automático.
• Procedimento de promoção do slave documentado e testado.
• Parte das leituras administrativas redirecionadas ao slave.

Com a replicação funcionando, o passo seguinte é integrar isso a um plano geral de contingência de infraestrutura, cobrindo também GameServer e ConnectServer — o tutorial de criação de servidor de MU Online traz a base completa para quem está estruturando ou revisando esse ambiente.

Perguntas frequentes