Cómo corregir el desync de horario entre servidores de MU Online

Respuesta rápida

Un servidor de MU Online normalmente distribuye sus responsabilidades entre múltiples procesos — GameServer, ConnectServer, JoinServer, DataServer y la base de datos MySQL/MariaDB — que pueden correr en la misma máquina o en máquinas/VMs diferentes. Cuando el reloj de cualquiera de estos componentes se desincroniza, aunque sea por pocos segundos, aparecen síntomas confusos: eventos automáticos disparándose en el horario incorrecto, sesiones de autenticación expirando antes de lo esperado, y logs con timestamps fuera de orden que dificultan cualquier investigación de un problema. Este tutorial explica cómo diagnosticar la causa raíz del desync y corregirla de forma permanente, con sincronización automática vía NTP y ajustes de zona horaria en cada capa del servidor.

Síntomas comunes de desync de horario

El desync rara vez se presenta como un error explícito — aparece como un comportamiento extraño e intermitente. Las señales más frecuentes incluyen: Blood Castle o Devil Square abriendo minutos antes o después del horario configurado, jugadores siendo desconectados con "sesión expirada" poco después de iniciar sesión, ítems con cooldown basado en tiempo (por ejemplo, el uso de ciertos consumibles) liberándose antes de lo esperado, y discrepancia entre el reloj mostrado en el cliente del juego y el horario real del sistema.

Dónde se usa el horario dentro de la arquitectura del servidor

Componente	Uso de horario/timestamp	Impacto de un desync
Base de datos (MySQL/MariaDB)	Timestamps de login, creación de personaje, logs de transacción	Registros fuera de orden cronológico, auditoría comprometida
GameServer	Programación de eventos automáticos, cooldowns de ítems/habilidades	Eventos en el horario incorrecto, cooldowns liberándose antes/después
JoinServer/ConnectServer	Validación de sesión y tokens de autenticación	Sesiones expirando prematuramente o no expirando
Sistema operativo (host)	Reloj de referencia para todos los procesos anteriores	Propaga el error a todas las capas superiores

Diagnosticando la causa raíz

El primer paso es aislar dónde exactamente está el desvío. Ejecuta el comando de horario en cada máquina/servicio involucrado y compáralo con una fuente confiable de tiempo (un servidor NTP público, como pool.ntp.org):

# Linux - verificar el horario actual del sistema
date
timedatectl status

# Verificar si el servicio de sincronización está activo
systemctl status systemd-timesyncd
# o, si usas chrony
chronyc tracking

En Windows (común en servidores de MU basados en MuEmu/IGCN):

w32tm /query /status
w32tm /query /peers

Si el desvío (offset) reportado es mayor que unos segundos, o si el servicio de sincronización está inactivo, encontraste la causa probable.

Corrigiendo con NTP en Linux

# Instalar chrony (recomendado, más preciso que el ntpd tradicional)
sudo apt install chrony -y

# Configurar servidores NTP confiables en /etc/chrony/chrony.conf
# pool pool.ntp.org iburst
# pool a.ntp.br iburst
# pool b.ntp.br iburst

sudo systemctl enable chrony
sudo systemctl restart chrony

# Forzar sincronización inmediata
sudo chronyc makestep

Usar servidores NTP brasileños (a.ntp.br, b.ntp.br, mantenidos por el Observatorio Nacional) reduce la latencia de sincronización para servidores hospedados en Brasil, comparado con depender solo de pools genéricos internacionales.

Corrigiendo en Windows Server

# Configurar el servicio de horario de Windows para usar NTP
w32tm /config /manualpeerlist:"a.ntp.br,b.ntp.br,pool.ntp.org" /syncfromflags:manual /reliable:YES /update

# Reiniciar el servicio
net stop w32time
net start w32time

# Forzar resincronización
w32tm /resync /force

En entornos con múltiples VMs Windows en el mismo host físico (común en configuraciones de MU con GameServer, ConnectServer y JoinServer separados), configura todas para sincronizarse con la misma fuente NTP — mezclar fuentes diferentes entre VMs del mismo clúster reintroduce desvíos pequeños, pero suficientes para causar los síntomas descritos.

Ajustando la zona horaria de la aplicación

Además del reloj del sistema, verifica la zona horaria configurada en cada aplicación. Es común que el GameServer tenga una zona horaria hardcodeada en la configuración (frecuentemente UTC o GMT-3 para servidores brasileños) que necesita coincidir con la zona del sistema operativo y de la base de datos:

[Config]
TimeZone = America/Sao_Paulo

-- Verificar y ajustar la zona horaria de MySQL
SELECT @@global.time_zone, @@session.time_zone;
SET GLOBAL time_zone = '-03:00';

Si el sistema operativo está en America/Sao_Paulo pero MySQL está configurado en UTC (+00:00), todos los timestamps grabados en la base de datos tendrán un desplazamiento de 3 horas respecto al horario local, generando exactamente los síntomas de "evento en el horario incorrecto".

Validando la corrección con una prueba controlada

Después de configurar el NTP y la zona horaria en todos los componentes, reinicia GameServer, ConnectServer, JoinServer y el servicio de base de datos.
Compara el horario mostrado en date/w32tm /query /status en cada máquina — la diferencia entre ellas debe ser inferior a 1 segundo.
Configura un evento automático de prueba (Devil Square, por ejemplo) para abrir en 5 minutos y confirma que se dispara en el horario exacto.
Verifica un nuevo registro de login en la base de datos y confirma que el timestamp coincide con el horario real del momento de la prueba.

Monitoreo continuo para evitar la recurrencia

El desync de horario tiende a volver gradualmente (drift) incluso después de corregido, especialmente en VMs con reloj de hardware inestable. Configura una alerta simple (script cron o monitoreo de infraestructura) que compare periódicamente el horario del sistema con una fuente NTP confiable y notifique al equipo si el desvío supera un límite (por ejemplo, 2 segundos), antes de que el problema vuelva a afectar a los jugadores.

Errores comunes y soluciones

Síntoma	Causa probable	Solución
El evento abre en un horario diferente al anunciado	Zona horaria divergente entre el GameServer y el sistema	Alinea el `TimeZone` de la aplicación con la zona del SO
Sesiones expirando poco después del login	Desvío de horario entre JoinServer y ConnectServer	Sincroniza ambos con la misma fuente NTP
Logs de la base de datos fuera de orden cronológico	MySQL con zona horaria diferente a la del sistema	Ajusta `time_zone` de MySQL para que coincida con el SO
El desvío reaparece tras semanas	Servicio de sincronización (NTP/chrony) inactivo o no persistente	Habilita el servicio para que inicie automáticamente al arrancar
VMs del mismo clúster con horarios diferentes	Cada VM sincronizándose con una fuente NTP distinta	Estandariza todas las VMs a la misma fuente de sincronización

Lista de verificación de sincronización de horario

Horario de cada componente comparado con una fuente NTP confiable.
Servicio de sincronización (chrony/NTP en Linux, w32time en Windows) activo y configurado para iniciar al arrancar.
Zona horaria alineada entre el sistema operativo, la aplicación (GameServer) y la base de datos.
Prueba controlada de evento automático confirmando el horario correcto.
Todas las VMs/máquinas del clúster sincronizándose con la misma fuente NTP.
Monitoreo continuo del desvío de horario configurado.

Con el horario sincronizado de forma confiable entre todos los componentes, vale la pena revisar la arquitectura general del servidor para identificar otros puntos de fragilidad antes de que se conviertan en incidentes visibles para los jugadores. Consulta el tutorial de creación de servidor de MU Online para revisar los fundamentos de la infraestructura completa.

Preguntas frecuentes

¿El desync de horario afecta el juego incluso si todos los servidores están en la misma máquina física?

Puede afectar si los procesos corren en contenedores o VMs con relojes independientes, o si algún servicio usa una zona horaria diferente en la configuración de la aplicación aunque compartan el mismo hardware. Verifica tanto el reloj del sistema operativo como la zona horaria configurada en cada aplicación (GameServer, base de datos).

¿Cómo sé si el problema es desync de horario y no otra falla de red?

Los síntomas típicos de desync incluyen eventos automáticos (Blood Castle, Devil Square) abriendo en un horario diferente al anunciado, tokens de autenticación expirando prematuramente, y discrepancia entre el horario mostrado en el juego y el horario real. Compara el horario del sistema en cada máquina/servicio con una fuente de horario confiable (NTP público) para confirmarlo.

¿NTP es obligatorio o se puede sincronizar manualmente?

Se puede ajustar manualmente una vez, pero el reloj de cualquier máquina sufre drift (desvío gradual) a lo largo del tiempo, aunque sean pocos segundos por día. Sin un servicio de sincronización automática como NTP, el desync vuelve a aparecer en semanas o meses, exigiendo corrección manual recurrente.

¿El desync de horario puede corromper datos de la base de datos?

Directamente no corrompe los datos, pero puede causar inconsistencias lógicas: timestamps de login, cooldowns de ítems y registros de eventos pueden quedar fuera de orden cronológico, dificultando la auditoría y, en casos extremos, permitiendo exploits (repetir una acción que debería tener cooldown, por ejemplo, si el sistema depende solo de la comparación de timestamp).

¿Correr servidores en regiones/data centers diferentes aumenta el riesgo de desync?

Sí, de forma significativa. Cada máquina en una región diferente tiene su propio reloj de hardware y, si cada una se sincroniza con un servidor NTP diferente o con frecuencias distintas, el desvío entre ellas tiende a ser mayor que en máquinas en la misma red local sincronizando con la misma fuente.

Rodrigo

Fundador y editor jefe

Rodrigo mantiene ViciadosMU desde los inicios del portal. Especialista en creación y administración de servidores de MU Online, historia del juego y la evolución de las seasons — escribió buena parte del archivo antes de 2024.