How to Manage Multiple MU Online Servers Simultaneously

Overview: Why Manage Multiple Servers?

Running a single MU Online S6 instance already demands constant attention. As a project grows — whether due to player demand, event separation, or configuration testing — operating multiple parallel servers becomes necessary. The good news is that S6's architecture is designed with this scalability in mind: the ConnectServer acts as a central router, the DBServer centralizes all data, and multiple GameServers can register simultaneously.

This guide covers the logical organization of instances, resource monitoring, map distribution across processes, and the most common pitfalls in multi-server environments — all focused on pure S6 mechanics, without referencing features that do not exist in this version.

S6 Base Architecture: Understanding the Processes

Before scaling, it is essential to understand what each process does:

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, event arenas, PvP instances
         │
         └── (all connect to the central DBServer)

The DBServer (sometimes called DataServer) is the single source of truth. It manages accounts, characters, guild data, event results like Crywolf, and the global item state. Each GameServer authenticates with the DBServer and receives permission to process players according to its configured ServerCode.

The ConnectServer routes players based on the list of available servers and the current population of each. It carries no game logic — it is purely a connection balancer.

Map Distribution by Instance

Intelligent distribution of maps across GameServers is the single biggest lever for performance. S6 includes the following maps:

• Starting/social zone: Lorencia, Noria, Devias
• Progressive dungeons: Dungeon (3 floors), Lost Tower (7 floors), Kalima (1-7)
• Ocean zone: Atlans (3 floors)
• Mid-tier zone: Tarkan, Icarus
• Advanced zone: Aida, Karutan, Kanturu (3 floors)
• Endgame zone: Land of Trials, Crywolf Fortress, Raklion, Vulcanus, Acheron

A functional split for a 3-GameServer environment:

GameServer 0  →  Lorencia + Noria + Devias + Dungeon (3F)
              →  (high new-player density, low CPU cost)

GameServer 1  →  Lost Tower (7F) + Atlans (3F) + Tarkan + Icarus
              →  (medium density, Castle Siege events)

GameServer 2  →  Aida + Karutan + Kanturu (3F) + Kalima (1-7)
              →  (low density, high elite mob processing)
              →  + Land of Trials + Crywolf Fortress + Raklion
              →  + Vulcanus + Acheron

Class and Attribute Configuration in a Multi-Server Environment

S6 has six classes with specific progressions that affect server configuration:

Dark Knight     →  Blade Knight     →  Blade Master
Dark Wizard     →  Soul Master      →  Grand Master
Elf             →  Muse Elf         →  High Elf
Magic Gladiator →  Duel Master      (no 1st/2nd quest, no Wing L1)
Dark Lord       →  Lord Emperor     (exclusive CMD attribute)
Summoner        →  Bloody Summoner  →  Dimension Master

Every GameServer that accepts characters must have the class progression tables correctly configured. Pay special attention to:

Magic Gladiator / Duel Master: this class has no first or second quest and cannot equip Level 1 Wings. Poorly configured automatic quest systems can permanently stall the character. Validate the quest flow in each GameServer's configuration file.

Dark Lord / Lord Emperor: the CMD (Command) attribute is exclusive to this class and determines the maximum number of Spirit Sorcerers and other controllable guards. Verify that the CMD formula is active across all GameServers — a server missing this table treats CMD as zero and breaks all Dark Lord control mechanics.

Wings Level 3: the recipe Wing L2 + 3x Loch's Feather + Jewel of Creation depends on the Loch's Feather, which is only obtained as a drop from Balgass when the Crywolf event ends in a defender defeat. The Crywolf result must be persisted in the central DBServer so that Balgass's loot table is updated across all GameServers. If each GameServer manages its own isolated Crywolf logic, players may craft Wing L3 on servers where the flag was never properly set.

Real-Time Monitoring and Diagnostics

With multiple processes running, monitoring must be systematic. Some practical approaches:

Per-process logging: configure each GameServer to write logs to separate directories, with the ServerCode as a prefix in the filename. This eliminates ambiguity about which instance generated a given error.

DBServer connectivity checks: implement a periodic health check that queries the DBServer and validates the response. If an instance loses connection to the DBServer, it should be flagged immediately — players remain connected but inventory changes are not saved.

Critical map monitoring: Crywolf Fortress and Land of Trials have fixed event timers. Monitor the event tick processes of these instances separately to ensure there has been no silent crash in the responsible GameServer.

Monitoring checklist per GameServer:
  → Process active (PID exists)
  → DBServer connection (heartbeat < 5s)
  → Player count within configured limit
  → Event timers synchronized (Crywolf, Blood Castle, Devil Square)
  → No critical errors in logs within the last 60 seconds

Global Event Synchronization

Events such as Blood Castle, Devil Square, and Crywolf require special attention in multi-server environments:

Crywolf Fortress should run on only one GameServer. The result (victory or defeat of the Priests of Arca) is written to the DBServer and read by all other GameServers to determine whether Loch's Feather will be available in Balgass's drop pool. Never replicate the Crywolf map across multiple GameServers without a master-election mechanism — otherwise two servers may write conflicting results.

Blood Castle and Devil Square can be replicated across multiple GameServers, but event entry portals must be bound to the correct instance. Players entering portals on the wrong server will be teleported to a GameServer different from the one they are connected to, causing disconnection or loading loops.

Backup, Recovery, and Safe Maintenance

Running multiple GameServers means a poorly planned maintenance window may affect only a subset of players — which can be either precise (surgical) or problematic (state inconsistency).

Best practices:

• Back up the DBServer before any maintenance, regardless of which GameServer will be affected. All instances share the same database.
• Shut down GameServers in the reverse order of initialization to ensure all sessions are persisted before the DBServer is stopped.
• When updating class configuration (for example, fixing the Dark Lord's CMD table), apply the change to all GameServers before restarting any one of them. Instances running different versions of the attribute table produce characters with inconsistent stats.
• Keep initialization scripts idempotent: running the script twice should not create duplicate processes or erase existing configuration.

Careful administration of multiple MU Online S6 servers requires configuration discipline, active monitoring, and clear internal documentation. With these pillars in place, scaling from one to five GameServer instances becomes a controlled and reversible process.

Perguntas frequentes