Cómo corregir el error de base de datos corrupta en el servidor de MU Online

Pocos incidentes asustan más a un administrador de servidor de MU Online que abrir el GameServer por la mañana y encontrar errores de tabla corrupta en la base de datos — con el riesgo real de perder personajes, ítems y progreso de los jugadores. La buena noticia es que la mayoría de los casos de corrupción son recuperables, total o parcialmente, siempre que el diagnóstico y la corrección sigan un orden cuidadoso que no empeore el daño. Este tutorial cubre el proceso completo: identificar el tipo y la extensión de la corrupción, recuperar la mayor cantidad de datos posible, restaurar desde backup cuando sea necesario, e implementar una rutina que reduzca drásticamente el riesgo de que esto vuelva a ocurrir.

Reconociendo los síntomas de corrupción

Las señales más comunes de corrupción de base de datos en un servidor de MU incluyen: el GameServer fallando al iniciar con un error relacionado con una tabla específica (Character, Warehouse, AccountCharacter), consultas SQL simples devolviendo el error Table 'X' is marked as crashed, personajes o ítems desapareciendo o apareciendo duplicados, y el propio MySQL registrando errores de E/S o de índice corrupto en el log (mysqld.log o el Visor de eventos en Windows).

Primera acción: deja de escribir en la base de datos

Antes de cualquier diagnóstico, detén el GameServer y cualquier otro proceso que escriba en la base de datos (JoinServer, panel web, herramientas de administración). Seguir operando sobre una base de datos corrupta aumenta el riesgo de que la corrupción se propague a otras tablas o de sobrescribir datos que todavía serían recuperables. Haz una copia bruta de los archivos de datos de MySQL (directorio data/, generalmente en /var/lib/mysql en Linux o C:\ProgramData\MySQL\MySQL Server X.X\Data en Windows) antes de intentar cualquier reparación — esa copia es tu red de seguridad en caso de que la reparación empeore la situación.

Identificando el motor de almacenamiento de las tablas afectadas

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

El procedimiento de recuperación cambia según el motor:

Reparando tablas MyISAM corruptas

Con MySQL detenido, usa myisamchk directamente en los archivos:

sudo systemctl stop mysql

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

sudo systemctl start mysql

La flag -r (recover) intenta reconstruir el índice y recuperar la mayor cantidad de líneas posible. Si myisamchk reporta que no logró recuperar por completo, prueba con la flag más agresiva -o (safe recover), que es más lenta pero más cautelosa en la reconstrucción.

Alternativamente, con MySQL en ejecución, puedes usar el comando SQL equivalente:

CHECK TABLE Character;
REPAIR TABLE Character;

Recuperando InnoDB con force_recovery

Si InnoDB no arranca normalmente tras una corrupción, agrega la directiva de recuperación forzada en my.cnf/my.ini, comenzando por el nivel más suave:

[mysqld]
innodb_force_recovery = 1

Levanta el servicio, haz un dump completo de la base de datos (mysqldump) mientras todavía está en modo de recuperación, y restaura ese dump en una instancia nueva y limpia de MySQL. Nunca operes en producción con innodb_force_recovery activo por mucho tiempo — ese modo desactiva protecciones internas y existe solo para permitir la extracción segura de los datos antes de recrear la base desde cero.

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

# Después, en una instancia nueva/limpia:
mysql -u root -p MuOnline < recovery_dump.sql

Si el nivel 1 no es suficiente para que el dump se complete, aumenta gradualmente hasta el nivel 4 o 6 (los niveles más altos son más destructivos y deben ser el último recurso, pues ignoran verificaciones de integridad cada vez más fundamentales).

Restaurando desde backup cuando la reparación falla

Si la reparación directa no recupera los datos de forma confiable, la restauración del último backup válido es el camino más seguro:

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

Antes de restaurar, compara el timestamp del backup con el momento estimado de la corrupción — si el backup es de varias horas o días antes del incidente, evalúa si vale la pena intentar recuperar manualmente las diferencias (registros de creación de personaje, drops recientes) a partir de los logs del GameServer, si tu emulador mantiene ese tipo de log de auditoría.

Verificando la integridad tras la recuperación

Después de reparar o restaurar, ejecuta verificaciones básicas antes de liberar el servidor para los jugadores:

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

Compara los conteos con lo que esperarías según el número de jugadores activos — una caída abrupta e inexplicable en el número de filas es señal de que la recuperación no fue completa.

Investigando la causa raíz

Corregir la corrupción sin entender la causa es resolver el síntoma, no el problema. Las causas más comunes son: corte de energía o apagado abrupto de la máquina, kill -9 al proceso de MySQL en vez de un cierre gracioso, disco con sectores defectuosos, y falta de espacio en disco durante una escritura. Revisa los logs del sistema operativo y de MySQL (mysqld.log) en el horario aproximado de la corrupción para identificar cuál de estos escenarios ocurrió.

# Verificar la salud del disco (Linux)
sudo smartctl -a /dev/sda

# Verificar el espacio en disco disponible
df -h

Implementando una rutina de backup para prevenir la recurrencia

Automatiza el dump diario con un cron job (Linux) o el Programador de Tareas (Windows), guardando los archivos en un lugar fuera de la propia máquina del servidor (otro disco, otro servidor, o almacenamiento en la nube), para que un problema de hardware no destruya simultáneamente la base de datos y los backups.

# Ejemplo de cron job diario a las 4 de la madrugada
0 4 * * * mysqldump -u root -psenha MuOnline | gzip > /backup/mu_$(date +\%F).sql.gz

Errores comunes y soluciones

Lista de verificación de recuperación de base de datos corrupta

• GameServer y demás procesos detenidos antes de cualquier acción.
• Copia bruta de los archivos de datos hecha antes de la reparación.
• Motor de almacenamiento identificado (MyISAM, InnoDB, Aria).
• Reparación intentada con la herramienta apropiada para el motor.
• Restauración de backup realizada en caso de que la reparación no sea suficiente.
• Integridad verificada (conteo de filas, CHECK TABLE) antes de liberar el servidor.
• Causa raíz investigada (disco, energía, cierre abrupto).
• Rutina de backup automatizada y almacenada fuera de la máquina principal.

Con la base de datos recuperada y una rutina de backup implementada, vale la pena revisar toda la infraestructura del servidor para reducir otros puntos de falla antes de que se conviertan en incidentes. Consulta el tutorial de creación de servidor de MU Online para revisar los fundamentos completos de la configuración de tu entorno.

Preguntas frecuentes