Cómo escalar la base de datos (réplicas y backup en caliente) en MU Online

La base de datos es el activo más valioso de un servidor de MU Online. Los GameServers pueden caerse y volver, el proxy puede cambiarse, el sitio puede quedar fuera del aire por minutos, pero si la base de datos se corrompe o se pierde, se va todo: cuentas, personajes, ítems, resets, guilds, historial. A medida que la población crece, la base de datos también se vuelve un cuello de botella — las consultas de ranking pesan, el sitio consume lectura, los GameServers se disputan la escritura y un pico de accesos puede dejar el juego entero lento. Escalar la base de datos con réplicas de lectura y proteger los datos con backup en caliente resuelve los dos problemas de una vez: más capacidad y más seguridad.

Este tutorial muestra cómo separar lectura de escritura usando réplicas, cómo configurar backups sin tirar el servidor, cómo planificar la retención y cómo probar la restauración — porque un backup que nunca fue restaurado no es backup, es esperanza. Los comandos, nombres y valores aquí son ejemplos y varían según el SGBD (SQL Server, MySQL/MariaDB, PostgreSQL) y según la versión de tu emulador. Lo que no varía son los principios de consistencia, replicación y recuperación.

Dónde la base de datos se vuelve un cuello de botella en MU

Antes de escalar, entiende la carga. El tráfico de base de datos en MU se divide en dos tipos bien distintos:

• Escritura crítica: guardar personaje, mover ítem, actualizar zen, aplicar reset, grabar guild. Necesita ir a un único punto autoritativo, el primario, para que no haya conflicto ni ítem duplicado.
• Lectura pesada: rankings, conteo de online, estadísticas del sitio, panel de admin, logs. No altera nada y puede ser servida por copias.

El error común es meter todo en la misma base de datos y ver el sitio de ranking trabar el juego en horario pico. La estrategia de escalado parte de separar esos dos mundos: escritura concentrada y consistente en el primario, lectura distribuida en réplicas.

Requisitos previos

Antes de empezar:

• Un servidor de MU funcional con la base de datos ya en producción. Si aún estás en la base, consulta cómo crear un servidor de MU Online antes.
• Saber qué SGBD usas. Muchos emuladores de MU usan SQL Server; los forks y versiones modernas pueden usar MySQL/MariaDB. Los mecanismos de réplica y backup difieren entre ellos.
• Máquina(s) adicional(es) para hospedar la réplica y/o el destino de backup, idealmente en un lugar separado del primario.
• Acceso administrativo al SGBD (usuario con permiso para configurar replicación y backup).
• Espacio de almacenamiento planificado para los backups. Estima el tamaño de la base de datos y multiplícalo por la retención deseada. Ejemplo: una base de datos de algunos GB con retención de varios días exige decenas de GB reservados (varía según población y frecuencia).
• Herramienta de programación (Agent de SQL Server, cron, tareas programadas) para automatizar los backups.

Anota el modelo de recuperación que quieres. Define cuánto progreso es aceptable perder en un desastre (el llamado RPO) y cuánto tiempo toleras de indisponibilidad (el RTO). Esos dos números guían todas las decisiones de abajo.

Paso 1 — Definir RPO y RTO

Toda la estrategia de base de datos deriva de dos preguntas:

• RPO (¿cuánto puedo perder?): si la base de datos muere ahora, ¿acepto perder 5 minutos de juego? ¿1 hora? ¿Un día? Cuanto menor sea el RPO, más frecuentes y sofisticados serán los backups.
• RTO (¿cuánto puedo estar fuera?): ¿cuánto tiempo puede estar el servidor off mientras restauras? Minutos exigen réplica con failover; horas permiten restauración de backup.

Un ejemplo de meta razonable para un servidor medio: RPO de pocos minutos (con logs de transacción frecuentes) y RTO de menos de una hora (con backup en caliente listo y, idealmente, una réplica). Ajusta al tamaño y a la seriedad de tu proyecto.

Paso 2 — Configurar el modelo de recuperación y los tipos de backup

En SQL Server, el modelo de recuperación determina lo que es posible. Para permitir la restauración a un punto en el tiempo, usa el modelo FULL, que mantiene el log de transacciones hasta el backup de log.

Los tres tipos de backup que componen una estrategia sólida:

Ejemplo de comandos de backup en SQL Server (nombres y rutas son 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 del log de transacciones
BACKUP LOG MuOnline
TO DISK = 'D:\Backups\MuOnline_log.trn'
WITH INIT;

En MySQL/MariaDB, el equivalente para el backup en caliente suele hacerse con herramientas como el mecanismo de dump consistente o snapshots físicos con binlog habilitado para point-in-time. El concepto es el mismo: base periódica + log continuo. Adáptalo a tu SGBD.

Paso 3 — Hacer backup en caliente sin tirar el servidor

El punto central del backup en caliente es que corre con la base de datos en línea, sin sacar a los jugadores. Los SGBD modernos lo soportan nativamente: el backup lee una imagen consistente mientras el juego sigue grabando.

Buenas prácticas de backup en caliente:

1. Graba el backup en un disco/volumen diferente del de la base de datos, para que un fallo de disco no se lleve datos y backup juntos.
2. Copia el backup fuera de la máquina justo después (otro servidor, almacenamiento remoto). Un backup en la misma máquina que la base de datos protege poco.
3. Habilita la compresión para reducir el espacio y el tiempo de transferencia.
4. Programa los backups en horarios de menor movimiento para el full, y frecuentes para el log.
5. Verifica la integridad del archivo generado (checksum/verify) para no descubrir demasiado tarde que está corrupto.

Ejemplo de verificación de backup en SQL Server:

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

Nunca confíes en un backup que no pasó por verificación y, más importante, que nunca fue restaurado de verdad (ver Paso 6).

Paso 4 — Configurar réplica de lectura

La réplica es una copia de la base de datos mantenida en sincronía con el primario, usada para servir lecturas y como candidata a failover. La idea: el sitio, los rankings y los informes golpean la réplica; los GameServers siguen escribiendo en el primario.

Las tecnologías varían:

• SQL Server: Always On Availability Groups (réplica secundaria legible), Log Shipping o replicación transaccional.
• MySQL/MariaDB: replicación primario-réplica basada en binlog (asíncrona o semisíncrona).
• PostgreSQL: streaming replication con hot standby.

El flujo conceptual para configurar una réplica de lectura:

1. Restaura una copia reciente de la base de datos en la máquina de la réplica.
2. Conecta la réplica al primario mediante el mecanismo de replicación del SGBD.
3. La réplica pasa a aplicar continuamente los cambios del primario.
4. Apunta las lecturas no críticas (sitio, ranking) a la réplica.

Un detalle crucial: la replicación suele ser asíncrona, es decir, la réplica puede estar algunos segundos por detrás del primario. Para el ranking y el sitio, ese retraso es irrelevante. Para la escritura de juego, jamás uses la réplica — la fuente de la verdad es siempre el primario, si no arriesgas la duplicación de ítems.

Paso 5 — Dirigir las lecturas correctas a la réplica

Tener la réplica no sirve de nada si nada la usa. Redirige conscientemente:

• Sitio y panel: apunta la connection string de lectura del sitio a la réplica.
• Rankings y estadísticas: las consultas pesadas y periódicas deben correr en la réplica.
• Informes de admin: auditoría y métricas en la réplica o en una réplica dedicada solo a eso.
• Juego (GameServer/DataServer): permanece 100% en el primario, lectura y escritura, para garantizar la consistencia de la sesión.

Una separación clara de connection strings:

Esto libera al primario para enfocarse en lo que importa: grabar el progreso de los jugadores sin trabarse.

Paso 6 — Probar la restauración de verdad

Este es el paso que casi todo el mundo se salta y que separa a quien tiene backup de quien solo cree que lo tiene. Un backup solo es válido si ya lo restauraste y confirmaste que el juego arranca.

Rutina de prueba de restauración:

1. Toma el backup más reciente (full + diferencial + logs).
2. Restaura en una máquina o instancia separada, nunca encima de la producción.
3. Levanta un GameServer de prueba apuntando a la base de datos restaurada.
4. Verifica: las cuentas existen, los personajes tienen ítems, los resets y el zen coinciden.
5. Cronometra el proceso entero — ese es tu RTO real.

Ejemplo de restauración point-in-time en SQL Server:

-- Restaura el full con NORECOVERY para aplicar más 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 los logs hasta un instante específico
RESTORE LOG MuOnline_Teste
FROM DISK = 'D:\Backups\MuOnline_log.trn'
WITH RECOVERY, STOPAT = '2026-07-14T22:15:00';

Haz esta prueba periódicamente, no solo una vez. Los backups y las versiones cambian, y una prueba antigua no garantiza la de hoy.

Paso 7 — Planificar el failover

El failover es lo que haces cuando el primario muere de verdad. Con una réplica lista, el plan es promoverla a primario y reapuntar los GameServers a ella.

Elementos de un plan de failover:

• Réplica actualizada y verificada, lista para convertirse en primario.
• Procedimiento documentado de promoción (comandos exactos de tu SGBD).
• Reapunte de las connection strings de los GameServers/DataServer al nuevo primario.
• Comunicación con los jugadores sobre el mantenimiento de emergencia.
• Decisión sobre la automatización: el failover automático reduce el RTO pero exige una configuración cuidadosa (ej.: Always On con testigo) para evitar el "split brain".

Incluso un failover manual bien ensayado, que lleve pocos minutos, ya es un enorme salto de resiliencia frente a no tener ningún plan.

Paso 8 — Mantenimiento y retención

Una base de datos escalada exige mantenimiento continuo, si no se degrada:

• Retención de backups: mantén una ventana (ej.: varios días de full + logs) y descarta lo que pasó, controlando el costo de almacenamiento. Guarda al menos una copia off-site.
• Índices y estadísticas: reorganiza/reconstruye los índices periódicamente para mantener las consultas rápidas.
• Monitoreo del lag de la réplica: alerta si la réplica queda muy por detrás del primario.
• Monitoreo de espacio: un log de transacciones al que no se le hace backup crece sin parar y llena el disco.
• Alertas de fallo de backup: un backup que falló silenciosamente es un desastre esperando a suceder.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• RPO y RTO definidos y documentados
• Modelo de recuperación adecuado (ej.: FULL en SQL Server)
• Backup completo programado
• Backups diferencial y de log programados conforme al RPO
• Backup en caliente corriendo sin tirar el servidor
• Backups grabados en un disco diferente y copiados fuera de la máquina
• Verificación de integridad después de cada backup
• Réplica de lectura configurada y sincronizando
• Sitio, ranking e informes apuntando a la réplica
• GameServer/DataServer apuntando solo al primario
• Restauración probada en un entorno separado y RTO cronometrado
• Plan de failover documentado y ensayado
• Retención definida con copia off-site
• Monitoreo de lag, espacio y fallos de backup activo

Conclusión

Escalar la base de datos de un servidor de MU Online es, al mismo tiempo, un trabajo de rendimiento y de supervivencia. Las réplicas de lectura le quitan al primario el peso de los rankings, sitios e informes, dejándolo libre para grabar el progreso de los jugadores con consistencia. El backup en caliente garantiza que, pase lo que pase, puedes volver a un punto en el tiempo sin haber tirado el servidor para ello. Y el plan de failover transforma un desastre de días perdidos en un mantenimiento de minutos. Trata los comandos, tamaños y frecuencias de esta guía como ejemplos y ajústalos a tu SGBD y a tu Season, pero nunca renuncies a los principios: escritura concentrada en el primario, lectura distribuida, backup probado y recuperación ensayada. Es lo que separa a un servidor que pierde todo en un incidente de uno que sobrevive y sigue creciendo.

Preguntas frecuentes