Como corrigir desync de horário entre servidores de MU Online

Resposta rápida

Um servidor de MU Online normalmente distribui suas responsabilidades entre múltiplos processos — GameServer, ConnectServer, JoinServer, DataServer e o banco de dados MySQL/MariaDB — que podem rodar na mesma máquina ou em máquinas/VMs diferentes. Quando o relógio de qualquer um desses componentes fica dessincronizado, mesmo por poucos segundos, surgem sintomas confusos: eventos automáticos disparando no horário errado, sessões de autenticação expirando antes do esperado, e logs com timestamps fora de ordem que dificultam qualquer investigação de problema. Este tutorial explica como diagnosticar a causa raiz do desync e corrigi-la de forma permanente, com sincronização automática via NTP e ajustes de fuso horário em cada camada do servidor.

Sintomas comuns de desync de horário

O desync raramente se apresenta como um erro explícito — ele aparece como comportamento estranho e intermitente. Os sinais mais frequentes incluem: Blood Castle ou Devil Square abrindo minutos antes ou depois do horário configurado, jogadores sendo desconectados com "sessão expirada" pouco depois de logar, itens com cooldown baseado em tempo (por exemplo, uso de determinados consumíveis) liberando antes do esperado, e discrepância entre o relógio exibido no cliente do jogo e o horário real do sistema.

Onde o horário é usado dentro da arquitetura do servidor

Componente	Uso de horário/timestamp	Impacto de um desync
Banco de dados (MySQL/MariaDB)	Timestamps de login, criação de personagem, logs de transação	Registros fora de ordem cronológica, auditoria comprometida
GameServer	Agendamento de eventos automáticos, cooldowns de itens/habilidades	Eventos no horário errado, cooldowns liberando cedo/tarde
JoinServer/ConnectServer	Validação de sessão e tokens de autenticação	Sessões expirando prematuramente ou não expirando
Sistema operacional (host)	Relógio de referência para todos os processos acima	Propaga o erro para todas as camadas acima

Diagnosticando a causa raiz

O primeiro passo é isolar onde exatamente está o desvio. Rode o comando de horário em cada máquina/serviço envolvido e compare com uma fonte confiável de tempo (um servidor NTP público, como pool.ntp.org):

# Linux - verificar horário atual do sistema
date
timedatectl status

# Verificar se o serviço de sincronização está ativo
systemctl status systemd-timesyncd
# ou, se usar chrony
chronyc tracking

No Windows (comum em servidores de MU baseados em MuEmu/IGCN):

w32tm /query /status
w32tm /query /peers

Se o desvio (offset) reportado for maior que alguns segundos, ou se o serviço de sincronização estiver inativo, você encontrou a causa provável.

Corrigindo com NTP no Linux

# Instalar chrony (recomendado, mais preciso que ntpd tradicional)
sudo apt install chrony -y

# Configurar servidores NTP confiáveis em /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

# Forçar sincronização imediata
sudo chronyc makestep

Usar servidores NTP brasileiros (a.ntp.br, b.ntp.br, mantidos pelo Observatório Nacional) reduz a latência de sincronização para servidores hospedados no Brasil, comparado a depender apenas de pools genéricos internacionais.

Corrigindo no Windows Server

# Configurar o serviço de horário do Windows para usar NTP
w32tm /config /manualpeerlist:"a.ntp.br,b.ntp.br,pool.ntp.org" /syncfromflags:manual /reliable:YES /update

# Reiniciar o serviço
net stop w32time
net start w32time

# Forçar ressincronização
w32tm /resync /force

Em ambientes com múltiplas VMs Windows no mesmo host físico (comum em setups de MU com GameServer, ConnectServer e JoinServer separados), configure todas para sincronizar com a mesma fonte NTP — misturar fontes diferentes entre VMs do mesmo cluster reintroduz desvios pequenos, mas suficientes para causar os sintomas descritos.

Ajustando o fuso horário da aplicação

Além do relógio do sistema, verifique o fuso horário configurado em cada aplicação. É comum que o GameServer tenha um fuso horário hardcoded na configuração (frequentemente UTC ou GMT-3 para servidores brasileiros) que precisa bater com o fuso do sistema operacional e do banco de dados:

[Config]
TimeZone = America/Sao_Paulo

-- Verificar e ajustar o fuso horário do MySQL
SELECT @@global.time_zone, @@session.time_zone;
SET GLOBAL time_zone = '-03:00';

Se o sistema operacional está em America/Sao_Paulo mas o MySQL está configurado para UTC (+00:00), todos os timestamps gravados no banco terão um deslocamento de 3 horas em relação ao horário local, gerando exatamente os sintomas de "evento no horário errado".

Validando a correção com um teste controlado

Após configurar o NTP e o fuso horário em todos os componentes, reinicie GameServer, ConnectServer, JoinServer e o serviço de banco de dados.
Compare o horário exibido em date/w32tm /query /status em cada máquina — a diferença entre elas deve ser inferior a 1 segundo.
Configure um evento automático de teste (Devil Square, por exemplo) para abrir em 5 minutos e confirme que ele dispara no horário exato.
Verifique um novo registro de login no banco e confirme que o timestamp bate com o horário real do momento do teste.

Monitoramento contínuo para evitar recorrência

Desync de horário tende a voltar gradualmente (drift) mesmo depois de corrigido, especialmente em VMs com relógio de hardware instável. Configure um alerta simples (script cron ou monitoramento de infraestrutura) que compare periodicamente o horário do sistema com uma fonte NTP confiável e notifique a equipe se o desvio ultrapassar um limite (por exemplo, 2 segundos), antes que o problema volte a afetar jogadores.

Erros comuns e soluções

Sintoma	Causa provável	Solução
Evento abre em horário diferente do anunciado	Fuso horário divergente entre GameServer e sistema	Alinhe `TimeZone` da aplicação com o fuso do SO
Sessões expirando logo após login	Desvio de horário entre JoinServer e ConnectServer	Sincronize ambos com a mesma fonte NTP
Logs do banco fora de ordem cronológica	MySQL com fuso horário diferente do sistema	Ajuste `time_zone` do MySQL para bater com o SO
Desvio reaparece após semanas	Serviço de sincronização (NTP/chrony) inativo ou não persistente	Habilite o serviço para iniciar automaticamente no boot
VMs do mesmo cluster com horários diferentes	Cada VM sincronizando com fonte NTP distinta	Padronize todas as VMs para a mesma fonte de sincronização

Checklist de sincronização de horário

Horário de cada componente comparado com fonte NTP confiável.
Serviço de sincronização (chrony/NTP no Linux, w32time no Windows) ativo e configurado para iniciar no boot.
Fuso horário alinhado entre sistema operacional, aplicação (GameServer) e banco de dados.
Teste controlado de evento automático confirmando horário correto.
Todas as VMs/máquinas do cluster sincronizando com a mesma fonte NTP.
Monitoramento contínuo de desvio de horário configurado.

Com o horário sincronizado de forma confiável entre todos os componentes, vale revisar a arquitetura geral do servidor para identificar outros pontos de fragilidade antes que virem incidentes visíveis aos jogadores. Consulte o tutorial de criação de servidor de MU Online para revisar os fundamentos da infraestrutura completa.

Perguntas frequentes

Desync de horário afeta o jogo mesmo se todos os servidores estão na mesma máquina física?

Pode afetar se os processos rodam em containers ou VMs com relógios independentes, ou se algum serviço usa fuso horário diferente na configuração da aplicação mesmo compartilhando o mesmo hardware. Verifique tanto o relógio do sistema operacional quanto o fuso horário configurado em cada aplicação (GameServer, banco de dados).

Como sei se o problema é desync de horário e não outra falha de rede?

Sintomas típicos de desync incluem eventos automáticos (Blood Castle, Devil Square) abrindo em horário diferente do anunciado, tokens de autenticação expirando prematuramente, e discrepância entre o horário exibido no jogo e o horário real. Compare o horário do sistema em cada máquina/serviço com um horário de referência confiável (NTP público) para confirmar.

NTP é obrigatório ou dá para sincronizar manualmente?

Dá para ajustar manualmente uma vez, mas o relógio de qualquer máquina sofre drift (desvio gradual) ao longo do tempo, mesmo poucos segundos por dia. Sem um serviço de sincronização automática como NTP, o desync volta a aparecer em semanas ou meses, exigindo correção manual recorrente.

Desync de horário pode corromper dados do banco?

Diretamente não corrompe os dados, mas pode causar inconsistências lógicas: timestamps de login, cooldowns de itens e registros de eventos podem ficar fora de ordem cronológica, dificultando auditoria e, em casos extremos, permitindo exploits (repetir uma ação que deveria ter cooldown, por exemplo, se o sistema depende só de comparação de timestamp).

Rodar servidores em regiões/data centers diferentes aumenta o risco de desync?

Sim, significativamente. Cada máquina em uma região diferente tem seu próprio relógio de hardware e, se cada uma sincroniza com um servidor NTP diferente ou com frequências diferentes, o desvio entre elas tende a ser maior do que máquinas na mesma rede local sincronizando com a mesma fonte.

Rodrigo

Fundador e editor-chefe

Rodrigo mantém o ViciadosMU desde os primórdios do portal. Especialista em criação e administração de servidores de MU Online, história do jogo e a evolução das seasons — escreveu boa parte do acervo antes de 2024.