Como escalar o banco (réplicas e backup quente) no MU Online

O banco de dados é o ativo mais valioso de um servidor de MU Online. GameServers podem cair e voltar, o proxy pode ser trocado, o site pode ficar fora do ar por minutos, mas se o banco corromper ou for perdido, some tudo: contas, personagens, itens, resets, guildas, histórico. À medida que a população cresce, o banco também vira gargalo — consultas de ranking pesam, o site consome leitura, os GameServers disputam escrita e um pico de acessos pode deixar o jogo inteiro lento. Escalar o banco com réplicas de leitura e proteger os dados com backup quente resolve os dois problemas de uma vez: mais capacidade e mais segurança.

Este tutorial mostra como separar leitura de escrita usando réplicas, como configurar backups sem derrubar o servidor, como planejar a retenção e como testar a restauração — porque backup que nunca foi restaurado não é backup, é esperança. Os comandos, nomes e valores aqui são exemplos e variam por SGBD (SQL Server, MySQL/MariaDB, PostgreSQL) e por versão do seu emulador. O que não varia são os princípios de consistência, replicação e recuperação.

Onde o banco vira gargalo no MU

Antes de escalar, entenda a carga. O tráfego de banco no MU se divide em dois tipos bem distintos:

• Escrita crítica: salvar personagem, mover item, atualizar zen, aplicar reset, gravar guild. Precisa ir para um único ponto autoritativo, o primário, para não haver conflito ou item duplicado.
• Leitura pesada: rankings, contagem de online, estatísticas do site, painel de admin, logs. Não altera nada e pode ser servida por cópias.

O erro comum é jogar tudo no mesmo banco e ver o site de ranking travar o jogo em horário de pico. A estratégia de escala parte de separar esses dois mundos: escrita concentrada e consistente no primário, leitura distribuída em réplicas.

Pré-requisitos

Antes de começar:

• Um servidor de MU funcional com o banco já em produção. Se ainda está na base, veja como criar servidor de MU Online antes.
• Saber qual SGBD você usa. Muitos emuladores de MU usam SQL Server; forks e versões modernas podem usar MySQL/MariaDB. Os mecanismos de réplica e backup diferem entre eles.
• Máquina(s) adicional(is) para hospedar réplica e/ou destino de backup, idealmente em local separado do primário.
• Acesso administrativo ao SGBD (usuário com permissão de configurar replicação e backup).
• Espaço de armazenamento planejado para backups. Estime o tamanho do banco e multiplique pela retenção desejada. Exemplo: banco de alguns GB com retenção de vários dias exige dezenas de GB reservados (varia por população e frequência).
• Ferramenta de agendamento (Agent do SQL Server, cron, tarefas agendadas) para automatizar backups.

Anote o modelo de recuperação que você quer. Ele define quanto de progresso é aceitável perder num desastre (o chamado RPO) e quanto tempo você tolera de indisponibilidade (o RTO). Esses dois números guiam todas as decisões abaixo.

Passo 1 — Definir RPO e RTO

Toda a estratégia de banco decorre de duas perguntas:

• RPO (quanto posso perder?): se o banco morrer agora, aceito perder 5 minutos de jogo? 1 hora? Um dia? Quanto menor o RPO, mais frequentes e mais sofisticados os backups.
• RTO (quanto posso ficar fora?): quanto tempo o servidor pode ficar off enquanto você restaura? Minutos exigem réplica com failover; horas permitem restauração de backup.

Um exemplo de meta razoável para um servidor médio: RPO de poucos minutos (com logs de transação frequentes) e RTO de menos de uma hora (com backup quente pronto e, idealmente, uma réplica). Ajuste ao tamanho e à seriedade do seu projeto.

Passo 2 — Configurar o modelo de recuperação e os tipos de backup

No SQL Server, o modelo de recuperação determina o que é possível. Para permitir restauração a um ponto no tempo, use o modelo FULL, que mantém o log de transações até o backup de log.

Os três tipos de backup que compõem uma estratégia sólida:

Exemplo de comandos de backup no SQL Server (nomes e caminhos são ilustrativos):

-- Backup completo
BACKUP DATABASE MuOnline
TO DISK = 'D:\Backups\MuOnline_full.bak'
WITH INIT, COMPRESSION;

-- Backup diferencial
BACKUP DATABASE MuOnline
TO DISK = 'D:\Backups\MuOnline_diff.bak'
WITH DIFFERENTIAL, INIT, COMPRESSION;

-- Backup do log de transações
BACKUP LOG MuOnline
TO DISK = 'D:\Backups\MuOnline_log.trn'
WITH INIT;

Em MySQL/MariaDB, o equivalente para backup quente costuma ser feito com ferramentas como o mecanismo de dump consistente ou snapshots físicos com binlog habilitado para point-in-time. O conceito é o mesmo: base periódica + log contínuo. Adapte ao seu SGBD.

Passo 3 — Fazer backup quente sem derrubar o servidor

O ponto central do backup quente é que ele roda com o banco online, sem tirar os jogadores. Os SGBDs modernos suportam isso nativamente: o backup lê uma imagem consistente enquanto o jogo continua gravando.

Boas práticas de backup quente:

1. Grave o backup em disco/volume diferente do banco, para que uma falha de disco não leve dados e backup juntos.
2. Copie o backup para fora da máquina logo em seguida (outro servidor, storage remoto). Backup na mesma máquina que o banco protege pouco.
3. Habilite compressão para reduzir espaço e tempo de transferência.
4. Agende os backups em horários de menor movimento para o full, e frequentes para o log.
5. Verifique a integridade do arquivo gerado (checksum/verify) para não descobrir tarde demais que está corrompido.

Exemplo de verificação de backup no SQL Server:

RESTORE VERIFYONLY
FROM DISK = 'D:\Backups\MuOnline_full.bak';

Nunca confie num backup que não passou por verificação e, mais importante, que nunca foi restaurado de verdade (ver Passo 6).

Passo 4 — Configurar réplica de leitura

A réplica é uma cópia do banco mantida em sincronia com o primário, usada para servir leituras e como candidata a failover. A ideia: o site, os rankings e relatórios batem na réplica; os GameServers continuam escrevendo no primário.

As tecnologias variam:

• SQL Server: Always On Availability Groups (réplica secundária legível), Log Shipping ou replicação transacional.
• MySQL/MariaDB: replicação primário-réplica baseada em binlog (assíncrona ou semissíncrona).
• PostgreSQL: streaming replication com hot standby.

O fluxo conceitual para configurar uma réplica de leitura:

1. Restaure uma cópia recente do banco na máquina da réplica.
2. Conecte a réplica ao primário pelo mecanismo de replicação do SGBD.
3. A réplica passa a aplicar continuamente as mudanças do primário.
4. Aponte as leituras não críticas (site, ranking) para a réplica.

Um detalhe crucial: a replicação costuma ser assíncrona, ou seja, a réplica pode estar alguns segundos atrás do primário. Para ranking e site, esse atraso é irrelevante. Para escrita de jogo, jamais use a réplica — a fonte da verdade é sempre o primário, senão você arrisca duplicação de itens.

Passo 5 — Direcionar as leituras corretas para a réplica

Ter a réplica não adianta se nada usa ela. Redirecione conscientemente:

• Site e painel: aponte a connection string de leitura do site para a réplica.
• Rankings e estatísticas: consultas pesadas e periódicas devem rodar na réplica.
• Relatórios de admin: auditoria e métricas na réplica ou em uma réplica dedicada só a isso.
• Jogo (GameServer/DataServer): permanece 100% no primário, leitura e escrita, para garantir consistência da sessão.

Uma separação clara de connection strings:

Isso libera o primário para focar no que importa: gravar o progresso dos jogadores sem travar.

Passo 6 — Testar a restauração de verdade

Este é o passo que quase todo mundo pula e que separa quem tem backup de quem só acha que tem. Um backup só é válido se você já restaurou ele e confirmou que o jogo sobe.

Rotina de teste de restauração:

1. Pegue o backup mais recente (full + diferencial + logs).
2. Restaure em uma máquina ou instância separada, nunca por cima da produção.
3. Suba um GameServer de teste apontando para o banco restaurado.
4. Verifique: contas existem, personagens têm itens, resets e zen conferem.
5. Cronometre o processo inteiro — esse é o seu RTO real.

Exemplo de restauração point-in-time no SQL Server:

-- Restaura o full com NORECOVERY para aplicar mais backups
RESTORE DATABASE MuOnline_Teste
FROM DISK = 'D:\Backups\MuOnline_full.bak'
WITH NORECOVERY, MOVE 'MuOnline' TO 'D:\Data\MuOnline_Teste.mdf',
     MOVE 'MuOnline_log' TO 'D:\Data\MuOnline_Teste.ldf';

-- Aplica logs até um instante específico
RESTORE LOG MuOnline_Teste
FROM DISK = 'D:\Backups\MuOnline_log.trn'
WITH RECOVERY, STOPAT = '2026-07-14T22:15:00';

Faça esse teste periodicamente, não apenas uma vez. Backups e versões mudam, e um teste antigo não garante o de hoje.

Passo 7 — Planejar failover

Failover é o que você faz quando o primário morre de verdade. Com uma réplica pronta, o plano é promovê-la a primário e reapontar os GameServers para ela.

Elementos de um plano de failover:

• Réplica atualizada e verificada, pronta para virar primário.
• Procedimento documentado de promoção (comandos exatos do seu SGBD).
• Reaponte de connection strings dos GameServers/DataServer para o novo primário.
• Comunicação com os jogadores sobre a manutenção emergencial.
• Decisão sobre automação: failover automático reduz o RTO mas exige configuração cuidadosa (ex.: Always On com testemunha) para evitar "split brain".

Mesmo um failover manual bem ensaiado, que leve poucos minutos, já é um enorme salto de resiliência frente a não ter plano nenhum.

Passo 8 — Manutenção e retenção

Banco escalado exige manutenção contínua, senão degrada:

• Retenção de backups: mantenha uma janela (ex.: vários dias de full + logs) e descarte o que passou, controlando custo de armazenamento. Guarde ao menos uma cópia off-site.
• Índices e estatísticas: reorganize/reconstrua índices periodicamente para manter as consultas rápidas.
• Monitoramento de lag da réplica: alerta se a réplica ficar muito atrás do primário.
• Monitoramento de espaço: log de transações que não é feito backup cresce sem parar e enche o disco.
• Alertas de falha de backup: um backup que falhou silenciosamente é um desastre esperando acontecer.

Erros comuns e soluções

Checklist de lançamento

• RPO e RTO definidos e documentados
• Modelo de recuperação adequado (ex.: FULL no SQL Server)
• Backup completo agendado
• Backups diferencial e de log agendados conforme o RPO
• Backup quente rodando sem derrubar o servidor
• Backups gravados em disco diferente e copiados para fora da máquina
• Verificação de integridade após cada backup
• Réplica de leitura configurada e sincronizando
• Site, ranking e relatórios apontando para a réplica
• GameServer/DataServer apontando só para o primário
• Restauração testada em ambiente separado e RTO cronometrado
• Plano de failover documentado e ensaiado
• Retenção definida com cópia off-site
• Monitoramento de lag, espaço e falhas de backup ativo

Conclusão

Escalar o banco de um servidor de MU Online é, ao mesmo tempo, um trabalho de performance e de sobrevivência. Réplicas de leitura tiram do primário o peso de rankings, sites e relatórios, deixando-o livre para gravar o progresso dos jogadores com consistência. Backup quente garante que, aconteça o que acontecer, você consegue voltar a um ponto no tempo sem ter derrubado o servidor para isso. E o plano de failover transforma um desastre de dias perdidos em uma manutenção de minutos. Trate os comandos, tamanhos e frequências deste guia como exemplos e ajuste ao seu SGBD e à sua Season, mas nunca abra mão dos princípios: escrita concentrada no primário, leitura distribuída, backup testado e recuperação ensaiada. É o que separa um servidor que perde tudo num incidente de um que sobrevive e continua crescendo.

Perguntas frequentes