Como Gerenciar Múltiplos Servidores de MU Online Simultaneamente

Visão Geral: Por Que Gerenciar Múltiplos Servidores?

Administrar uma única instância de MU Online S6 já exige atenção constante. Quando o projeto cresce — seja por demanda de jogadores, separação de eventos ou testes de configuração — a operação de múltiplos servidores paralelos torna-se inevitável. A boa notícia é que a arquitetura do S6 favorece essa escalabilidade: o ConnectServer atua como roteador central, o DBServer centraliza os dados e múltiplos GameServers podem ser registrados simultaneamente.

Este guia abrange a organização lógica das instâncias, o monitoramento de recursos, a divisão de mapas entre processos e as armadilhas mais comuns em ambientes multi-servidor — tudo com foco em S6 puro, sem funcionalidades inexistentes nessa versão.

Arquitetura Base do S6: Entendendo os Processos

Antes de escalar, é essencial compreender o que cada processo faz:

ConnectServer
    │
    ├── GameServer 0  →  Lorencia, Noria, Devias, Dungeon (3F)
    ├── GameServer 1  →  Lost Tower (7F), Atlans (3F), Tarkan, Icarus
    ├── GameServer 2  →  Aida, Karutan, Kanturu (3F), Raklion, Vulcanus
    ├── GameServer 3  →  Kalima (1-7), Land of Trials, Crywolf Fortress
    └── GameServer 4  →  Acheron, arenas de evento, instâncias PvP
         │
         └── (todos conectam ao DBServer central)

O DBServer (às vezes chamado de DataServer) é o ponto único de verdade. Ele gerencia contas, personagens, guild data, resultados de eventos como Crywolf e o estado global de itens. Cada GameServer se autentica no DBServer e recebe permissão para processar jogadores de acordo com seu ServerCode configurado.

O ConnectServer distribui os jogadores baseado na lista de servidores disponíveis e na lotação de cada um. Ele não carrega nenhuma lógica de jogo — é apenas um balanceador de conexões.

Divisão de Mapas por Instância

A divisão inteligente de mapas entre GameServers é o ponto mais impactante na performance. O S6 possui os seguintes mapas:

• Zona inicial/social: Lorencia, Noria, Devias
• Dungeons progressivos: Dungeon (3 andares), Lost Tower (7 andares), Kalima (1-7)
• Zona oceânica: Atlans (3 andares)
• Zona intermediária: Tarkan, Icarus
• Zona avançada: Aida, Karutan, Kanturu (3 andares)
• Zona endgame: Land of Trials, Crywolf Fortress, Raklion, Vulcanus, Acheron

Uma divisão funcional para ambiente com 3 GameServers seria:

GameServer 0  →  Lorencia + Noria + Devias + Dungeon (3F)
              →  (alta densidade de jogadores novos, leve em CPU)

GameServer 1  →  Lost Tower (7F) + Atlans (3F) + Tarkan + Icarus
              →  (densidade média, eventos Castle Siege)

GameServer 2  →  Aida + Karutan + Kanturu (3F) + Kalima (1-7)
              →  (baixa densidade, alto processamento de mobs elite)
              →  + Land of Trials + Crywolf Fortress + Raklion
              →  + Vulcanus + Acheron

Configuração de Classes e Atributos no Ambiente Multi-Servidor

O S6 possui seis classes com progressões específicas que afetam as configurações de servidor:

Dark Knight    →  Blade Knight    →  Blade Master
Dark Wizard    →  Soul Master     →  Grand Master
Elf            →  Muse Elf        →  High Elf
Magic Gladiator → Duel Master     (sem 1ª/2ª quest, sem Wing L1)
Dark Lord      →  Lord Emperor    (atributo CMD exclusivo)
Summoner       →  Bloody Summoner →  Dimension Master

Cada GameServer que aceitar personagens precisa ter as tabelas de progressão de classe corretamente configuradas. Atenção especial para:

Magic Gladiator / Duel Master: essa classe não possui primeira nem segunda quest e não pode equipar Wing de Nível 1. Sistemas de quest automáticos mal configurados podem entravar o personagem indefinidamente. Valide o fluxo de quest no arquivo de configuração de cada GameServer.

Dark Lord / Lord Emperor: o atributo CMD (Command) é exclusivo dessa classe e determina o número máximo de Spirit Sorcerers e outros guardas controlados. Verifique se a fórmula de CMD está ativa em todos os GameServers — um servidor sem essa tabela trata CMD como zero e quebra as mecânicas de controle do DL.

Wings Level 3: a receita Wing L2 + 3x Loch's Feather + Jewel of Creation depende da Loch's Feather, que só é obtida no drop do Balgass quando o evento Crywolf termina em derrota dos defensores. O resultado do Crywolf precisa ser persistido no DBServer central para que o loot table do Balgass seja atualizado em todos os GameServers. Se cada GameServer tiver sua própria lógica de Crywolf isolada, os jogadores poderão craftar Wing L3 em servidores onde a flag não foi setada corretamente.

Monitoramento e Diagnóstico em Tempo Real

Com múltiplos processos rodando, o monitoramento precisa ser sistemático. Algumas abordagens práticas:

Logs por processo: configure cada GameServer para gravar logs em diretórios separados, com prefixo de ServerCode no nome do arquivo. Isso elimina a ambiguidade de qual instância gerou determinado erro.

Verificação de conectividade com DBServer: implemente um health check periódico que consulta o DBServer e valida a resposta. Se uma instância perder conexão com o DBServer, ela deve ser sinalizada imediatamente — jogadores continuam conectados mas alterações de inventário não são salvas.

Monitoramento de mapas críticos: Crywolf Fortress e Land of Trials possuem eventos de timer fixo. Monitore os processos de event tick dessas instâncias separadamente para garantir que não houve crash silencioso no GameServer responsável.

Checklist de monitoramento por GameServer:
  → Processo ativo (PID existente)
  → Conexão com DBServer (heartbeat < 5s)
  → Player count dentro do limite configurado
  → Event timers sincronizados (Crywolf, Blood Castle, Devil Square)
  → Sem erros críticos nos logs dos últimos 60 segundos

Sincronização de Eventos Globais

Eventos como Blood Castle, Devil Square e Crywolf precisam de atenção especial em ambientes multi-servidor:

O Crywolf Fortress deve rodar em apenas um GameServer. O resultado (vitória ou derrota dos Priests of Arca) é gravado no DBServer e lido por todos os outros GameServers para determinar se a Loch's Feather estará disponível no drop do Balgass. Nunca replique o mapa de Crywolf em múltiplos GameServers sem um mecanismo de eleição de mestre — caso contrário, dois servidores podem gravar resultados conflitantes.

Blood Castle e Devil Square podem ser replicados em múltiplos GameServers, mas as entradas de evento (portais) precisam estar vinculadas à instância correta. Jogadores que entrarem em portais do servidor errado serão teletransportados para um GameServer diferente do que estão conectados, causando desconexão ou loop de loading.

Backup, Recuperação e Manutenção Segura

Manter múltiplos GameServers significa que uma manutenção mal planejada pode afetar apenas parte dos jogadores — o que pode ser bom (cirúrgico) ou ruim (inconsistência de estado).

Boas práticas:

• Faça backup do DBServer antes de qualquer manutenção, independentemente de qual GameServer será afetado. Todos dependem do mesmo banco.
• Desligue os GameServers na ordem inversa à inicialização para garantir que todas as sessões sejam persistidas antes do DBServer ser encerrado.
• Ao atualizar configurações de classe (por exemplo, corrigir a tabela de CMD do Dark Lord), aplique a alteração em todos os GameServers antes de reiniciar qualquer um. Instâncias com versões diferentes de tabela de atributo produzem personagens com stats inconsistentes.
• Mantenha scripts de inicialização idempotentes: rodar o script duas vezes não deve criar processos duplicados nem apagar configurações existentes.

A administração cuidadosa de múltiplos servidores de MU Online S6 exige disciplina de configuração, monitoramento ativo e documentação interna clara. Com esses pilares no lugar, escalar de uma para cinco instâncias de GameServer torna-se um processo controlado e reversível.

Perguntas frequentes