Cómo migrar tu servidor de MU Online de una VPS a un servidor dedicado

Migrar un servidor privado de MU Online de una VPS a un servidor dedicado es el paso natural cuando la comunidad crece y los límites de CPU, IO de disco y red compartidos empiezan a generar lag, timeout de login y caídas en el horario pico. A diferencia de una simple actualización de plan, esta migración implica cambiar de host físico, lo que normalmente significa una IP nueva, una nueva instalación de sistema operativo y la necesidad de mover una base de datos MySQL completa sin perder un solo personaje. Este tutorial cubre la planificación de hardware, la preparación del entorno nuevo, la migración de datos y archivos, el cambio de DNS y el cutover final con la menor indisponibilidad posible, además de los errores que más arruinan esta migración en la práctica.

Por qué migrar de VPS a dedicado

Una VPS comparte CPU, disco y red con otras VPS en el mismo host físico, incluso cuando el plan promete recursos "garantizados". En un servidor de MU con muchos jugadores simultáneos, MySQL ejecuta un volumen alto de queries por segundo (login, movimiento, guardas de trade, logs de PK), y es justamente el IO de disco compartido el que suele ser el cuello de botella — no la CPU. Un servidor dedicado entrega disco (idealmente NVMe) y red exclusivos, eliminando al "vecino ruidoso" que roba rendimiento en horarios pico. Además, los dedicados suelen tener un enlace de red mayor y un enrutamiento más estable, reduciendo los picos de latencia que los jugadores sienten como "ping spike".

Evaluando si el momento es el correcto

Antes de gastar en un dedicado, mide los síntomas reales. Un top/htop mostrando IO wait alto durante el horario pico, junto con queries lentas en el slow_query_log de MySQL, es el principal indicador de que el cuello de botella es la VPS, no tu base de datos mal indexada. Vale la pena confirmar esto antes, porque migrar a un dedicado no resuelve queries mal escritas — solo da más margen de hardware.

Eligiendo el hardware del dedicado

Para un servidor de MU Online con cientos de jugadores simultáneos, el cuello de botella real casi siempre es el IO de disco y la RAM disponible para que MySQL haga cache, no la CPU en bruto. Prioriza disco NVMe en RAID 1 (redundancia), al menos 32 GB de RAM (para que el buffer pool de InnoDB crezca cómodamente) y una CPU con buen clock por núcleo (el GameServer y MySQL escalan mejor con clock alto que con muchos núcleos débiles).

Planificando la ventana de mantenimiento

Comunica la fecha y el horario con al menos 3-5 días de anticipación, en todos los canales (Discord, sitio web, launcher). Elige el horario de menor movimiento (generalmente la madrugada) y estima la duración real basándote en un dry-run — no solo en una suposición optimista. Un error común es anunciar "30 minutos" y que la migración real termine tomando 3 horas porque el dump de la base de datos no fue probado antes.

Preparando el servidor dedicado antes del cutover

Todo el trabajo pesado debe ocurrir antes de sacar de línea al servidor antiguo. Esto incluye: instalar el sistema operativo, configurar MySQL/MariaDB con las mismas versiones (o compatibles) que el origen, instalar el MuServer/emulador, copiar los archivos estáticos del juego (Data/, configs, mapas) y ejecutar una prueba completa de arranque del GameServer y ConnectServer apuntando a una base de datos de prueba. Solo después de que esa prueba pase debes agendar la ventana real.

# En el dedicado nuevo, probar si MySQL arranca correctamente
sudo systemctl status mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'version';"

# Validar el espacio en disco disponible antes de la migración
df -h

Migrando la base de datos MySQL sin pérdida de datos

El paso más crítico. Después de poner el servidor en mantenimiento real (ConnectServer rechazando nuevos logins), genera el dump completo:

# En la VPS de origen, después de bloquear nuevos logins
mysqldump -u root -p --single-transaction --routines --triggers MuOnline > mu_dump_final.sql

# Validar tamaño e integridad antes de transferir
ls -lh mu_dump_final.sql
md5sum mu_dump_final.sql

Transfiere el dump vía rsync o scp al dedicado (nunca por correo o subiéndolo a un servicio de terceros, por el volumen y la sensibilidad de los datos de cuenta). En el destino, restaura y verifica el md5sum del archivo recibido antes de importarlo:

scp mu_dump_final.sql usuario@ip-del-dedicado:/backup/
mysql -u root -p MuOnline < mu_dump_final.sql

Después de la importación, ejecuta una revisión de sanidad: el conteo de personajes, el conteo de cuentas y la fecha del último login registrado deben coincidir con lo que existía en el origen al momento del dump.

Migrando archivos estáticos y configuraciones

Además de la base de datos, copia la carpeta completa del servidor (ejecutables de GameServer/ConnectServer/JoinServer, archivos .txt/.xml de configuración, mapas y cualquier script de eventos personalizado). Usa rsync -avz para preservar permisos y evitar corrupción silenciosa en archivos binarios grandes. Revisa las cadenas de conexión con MySQL en cada configuración — el dedicado tendrá una IP local (o socket) diferente a la de la VPS.

Ajustando DNS e IP fija del cliente

Actualiza el registro A de tu dominio hacia la nueva IP del dedicado, y reduce el TTL del DNS a algo bajo (300 segundos) unos días antes de la migración, para que la propagación sea rápida en el momento del cutover. Si el cliente del juego usa una IP fija hardcodeada en lugar de un dominio (común en muchos launchers), necesitarás distribuir una actualización del cliente o del launcher con la IP nueva — en ese caso planifícalo con margen, porque la propagación de DNS no resuelve ese caso.

Ejecutando el cutover

1. Anuncia el inicio del mantenimiento y bloquea nuevos logins en la VPS antigua.
2. Genera el dump final de MySQL y valida el checksum.
3. Transfiere el dump y los archivos al dedicado.
4. Restaura la base de datos y confirma los conteos de sanidad.
5. Levanta GameServer, ConnectServer y JoinServer en el dedicado y prueba el login con una cuenta de GM.
6. Actualiza el DNS (o distribuye la IP nueva por el launcher).
7. Mantén la VPS antigua encendida, sin aceptar logins, por 24-48h como fallback.
8. Anuncia la conclusión y monitorea el dedicado en las primeras horas de pico.

Manteniendo la VPS antigua como fallback temporal

No apagues ni canceles la VPS de inmediato. Mantenla activa (sin recibir tráfico de juego) por al menos 24 a 48 horas después del cutover, con el dump más reciente guardado también en ella. Si algo crítico falla en el dedicado, puedes revertir el DNS rápidamente mientras investigas, en lugar de perder por completo a la base de jugadores.

Errores comunes y soluciones

Lista de verificación de migración

• Síntomas de cuello de botella confirmados (IO wait, CPU, queries lentas).
• Hardware del dedicado dimensionado y aprovisionado.
• Dry-run completo realizado antes de la ventana real.
• Ventana de mantenimiento anunciada con anticipación.
• Dump de MySQL generado después del bloqueo de login, con checksum validado.
• Archivos estáticos y configs migrados vía rsync.
• DNS/IP actualizado y probado.
• VPS antigua mantenida como fallback por 24-48h.

Con el servidor corriendo estable en el dedicado, el próximo paso es revisitar tu estrategia de backup y monitoreo ahora que tienes control total del hardware — y, si todavía no tienes un proceso documentado desde cero, vale la pena revisar el tutorial de creación de servidor de MU Online para verificar si algo quedó pendiente en la nueva infraestructura.

Preguntas frecuentes