Como corrigir erro de banco de dados corrompido no servidor de MU Online

Poucos incidentes assustam mais um administrador de servidor de MU Online do que abrir o GameServer pela manhã e encontrar erros de tabela corrompida no banco de dados — com o risco real de perder personagens, itens e progresso de jogadores. A boa notícia é que a maioria dos casos de corrupção é recuperável, total ou parcialmente, desde que o diagnóstico e a correção sigam uma ordem cuidadosa que não piore o dano. Este tutorial cobre o processo completo: identificar o tipo e a extensão da corrupção, recuperar o máximo de dados possível, restaurar de backup quando necessário, e implementar uma rotina que reduza drasticamente o risco de isso acontecer de novo.

Reconhecendo os sintomas de corrupção

Os sinais mais comuns de corrupção de banco de dados em um servidor de MU incluem: o GameServer falhando ao iniciar com erro relacionado a uma tabela específica (Character, Warehouse, AccountCharacter), consultas SQL simples retornando erro Table 'X' is marked as crashed, personagens ou itens desaparecendo ou aparecendo duplicados, e o próprio MySQL registrando erros de I/O ou de índice corrompido no log (mysqld.log ou Event Viewer no Windows).

Primeira ação: pare de escrever no banco

Antes de qualquer diagnóstico, pare o GameServer e qualquer outro processo que escreva no banco (JoinServer, painel web, ferramentas de administração). Continuar operando sobre um banco corrompido aumenta o risco de a corrupção se espalhar para outras tabelas ou de sobrescrever dados que ainda seriam recuperáveis. Faça uma cópia bruta dos arquivos de dados do MySQL (diretório data/, geralmente em /var/lib/mysql no Linux ou C:\ProgramData\MySQL\MySQL Server X.X\Data no Windows) antes de tentar qualquer reparo — essa cópia é sua rede de segurança caso o reparo piore a situação.

Identificando o motor de armazenamento das tabelas afetadas

SELECT TABLE_NAME, ENGINE 
FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'MuOnline';

O procedimento de recuperação muda conforme o motor:

Reparando tabelas MyISAM corrompidas

Com o MySQL parado, use myisamchk diretamente nos arquivos:

sudo systemctl stop mysql

cd /var/lib/mysql/MuOnline
myisamchk -r Character.MYI
myisamchk -r Warehouse.MYI

sudo systemctl start mysql

A flag -r (recover) tenta reconstruir o índice e recuperar o máximo de linhas possível. Se myisamchk reportar que não conseguiu recuperar completamente, tente a flag mais agressiva -o (safe recover), que é mais lenta mas mais cautelosa na reconstrução.

Alternativamente, com o MySQL rodando, você pode usar o comando SQL equivalente:

CHECK TABLE Character;
REPAIR TABLE Character;

Recuperando InnoDB com force_recovery

Se o InnoDB não sobe normalmente após uma corrupção, adicione a diretiva de recuperação forçada no my.cnf/my.ini, começando pelo nível mais brando:

[mysqld]
innodb_force_recovery = 1

Suba o serviço, faça um dump completo do banco (mysqldump) enquanto ainda está no modo de recuperação, e restaure esse dump em uma instância nova e limpa do MySQL. Nunca opere em produção com innodb_force_recovery ativo por muito tempo — esse modo desativa proteções internas e existe apenas para permitir a extração segura dos dados antes de recriar o banco do zero.

mysqldump -u root -p --single-transaction MuOnline > recovery_dump.sql

# Depois, em uma instância nova/limpa:
mysql -u root -p MuOnline < recovery_dump.sql

Se o nível 1 não for suficiente para o dump completar, aumente gradualmente até o nível 4 ou 6 (os níveis mais altos são mais destrutivos e devem ser o último recurso, pois ignoram verificações de integridade cada vez mais fundamentais).

Restaurando a partir de backup quando o reparo falha

Se o reparo direto não recuperar os dados de forma confiável, a restauração do último backup válido é o caminho mais seguro:

# Restaurar backup completo
mysql -u root -p MuOnline < backup_2026-07-28.sql

Antes de restaurar, compare o timestamp do backup com o momento estimado da corrupção — se o backup for de várias horas ou dias antes do incidente, avalie se vale a pena tentar recuperar manualmente as diferenças (registros de criação de personagem, drops recentes) a partir de logs do GameServer, se seu emulador mantiver esse tipo de log de auditoria.

Verificando integridade após a recuperação

Depois de reparar ou restaurar, rode verificações básicas antes de liberar o servidor para os jogadores:

CHECK TABLE Character, Warehouse, AccountCharacter, Guild;
SELECT COUNT(*) FROM Character;
SELECT COUNT(*) FROM Warehouse;

Compare as contagens com o que você esperaria com base no número de jogadores ativos — uma queda abrupta e inexplicável no número de linhas é sinal de que a recuperação não foi completa.

Investigando a causa raiz

Corrigir a corrupção sem entender a causa é resolver o sintoma, não o problema. As causas mais comuns são: queda de energia ou desligamento abrupto da máquina, kill -9 no processo do MySQL em vez de um encerramento gracioso, disco com setores defeituosos, e falta de espaço em disco durante uma escrita. Verifique os logs do sistema operacional e do MySQL (mysqld.log) no horário aproximado da corrupção para identificar qual desses cenários ocorreu.

# Verificar saúde do disco (Linux)
sudo smartctl -a /dev/sda

# Verificar espaço em disco disponível
df -h

Implementando rotina de backup para prevenir recorrência

Automatize o dump diário com um cron job (Linux) ou Agendador de Tarefas (Windows), gravando os arquivos em um local fora da própria máquina do servidor (outro disco, outro servidor, ou armazenamento em nuvem), para que um problema de hardware não destrua simultaneamente o banco e os backups.

# Exemplo de cron job diário às 4h da manhã
0 4 * * * mysqldump -u root -psenha MuOnline | gzip > /backup/mu_$(date +\%F).sql.gz

Erros comuns e soluções

Checklist de recuperação de banco corrompido

• GameServer e demais processos parados antes de qualquer ação.
• Cópia bruta dos arquivos de dados feita antes do reparo.
• Motor de armazenamento identificado (MyISAM, InnoDB, Aria).
• Reparo tentado com a ferramenta apropriada ao motor.
• Restauração de backup realizada caso o reparo não seja suficiente.
• Integridade verificada (contagem de linhas, CHECK TABLE) antes de liberar o servidor.
• Causa raiz investigada (disco, energia, encerramento abrupto).
• Rotina de backup automatizada e armazenada fora da máquina principal.

Com o banco recuperado e uma rotina de backup implementada, vale revisar toda a infraestrutura do servidor para reduzir outros pontos de falha antes que se tornem incidentes. Consulte o tutorial de criação de servidor de MU Online para revisar os fundamentos completos da configuração do seu ambiente.

Perguntas frequentes