Como rodar dois servidores de MU Online na mesma máquina

Rodar dois servidores de MU Online completamente independentes na mesma máquina é uma necessidade comum: hospedar um servidor "principal" e um de "testes", operar um servidor Season 6 clássico ao lado de um servidor de rates altas, ou simplesmente aproveitar uma VPS robusta para dois projetos distintos. A boa notícia é que MU Online é perfeitamente capaz disso — a arquitetura de processos (DataServer, JoinServer, GameServer, ConnectServer) é modular e cada instância pode ter suas próprias portas, seus próprios arquivos de configuração e seu próprio banco. A má notícia é que qualquer descuido em portas duplicadas, DSN compartilhada por engano ou banco cruzado gera conflitos frustrantes, com processos que não sobem, personagens sumindo ou dois servidores gravando na mesma base. Este guia mostra como montar duas instâncias verdadeiramente isoladas, cobrindo portas distintas, bancos/instâncias de SQL, ConnectServer e GameServer separados, dimensionamento de recursos e como diagnosticar os conflitos mais comuns.

Diferença entre "dois servidores" e "subservers"

Antes de tudo, alinhe o conceito, porque as duas coisas são frequentemente confundidas:

• Subservers / channels (multi-server): vários GameServers que compartilham o mesmo banco e aparecem juntos na tela de seleção. O personagem é o mesmo em qualquer channel. Isso é sobre capacidade e balanceamento de um único projeto.
• Dois servidores independentes (este tutorial): dois projetos separados, cada um com seu próprio banco, suas contas, seus personagens e seu ConnectServer. Um jogador com conta no Servidor A não tem nada no Servidor B.

Se o seu objetivo é aumentar a capacidade de um servidor só, você quer subservers. Se quer dois mundos separados, é isto aqui.

Pré-requisitos

• Uma máquina (VPS ou dedicado) com folga de recursos — rodar dois servidores exige, na prática, quase o dobro de RAM e CPU de um. Trate 4 GB e 2 vCPUs como o mínimo absoluto para dois servidores pequenos; mais é melhor.
• Windows Server (2016/2019/2022 são comuns) com acesso administrativo.
• SQL Server instalado e funcional, com permissão para criar um segundo banco (ou uma segunda instância).
• Dois packs/emuladores já baixados — podem ser da mesma Season ou de Seasons diferentes.
• ODBC Data Source Administrator (32-bit) acessível, pois a maioria dos emuladores usa DSN de 32 bits.
• Backup de qualquer servidor já existente antes de mexer.
• Um bom controle mental (ou em planilha) do mapa de portas, que é o coração deste processo.

> A causa número um de fracasso aqui é reaproveitar arquivos de configuração do Servidor A no Servidor B sem trocar as portas e a DSN. Sempre revise config por config no segundo servidor.

Planejando o mapa de portas

Como os dois servidores vivem no mesmo IP, cada porta em uso precisa ser única entre eles. Planeje isso antes de tocar em qualquer arquivo. As portas exatas variam por emulador, então trate a tabela abaixo como um exemplo de organização — o importante é o princípio de faixas separadas:

Uma boa prática é deslocar o segundo servidor por um bloco fixo (ex.: +10 ou +100) em todas as portas, para ficar fácil de lembrar. Os valores acima são ilustrativos; use o cabeçalho dos arquivos do seu emulador para saber os nomes reais das chaves.

Passo 1 — Estrutura de pastas isolada

Nunca misture os dois servidores na mesma pasta. Crie árvores completamente separadas:

E:\MU\
├── ServidorA\
│   ├── DataServer\
│   ├── JoinServer\
│   ├── GameServer\
│   └── ConnectServer\
└── ServidorB\
    ├── DataServer\
    ├── JoinServer\
    ├── GameServer\
    └── ConnectServer\

Cada pasta tem seu próprio conjunto de binários e configs. Isso evita que uma atualização em um afete o outro e torna o backup trivial (basta copiar a pasta raiz de cada um).

Passo 2 — Bancos de dados separados

Você tem duas opções:

Opção A — Dois bancos na mesma instância (recomendado para a maioria)

Mais simples e leve. Na mesma instância de SQL Server, restaure/crie dois bancos com nomes distintos:

-- Criar os dois bancos (ou restaurar de backups do seu pack)
CREATE DATABASE MuOnlineA;
CREATE DATABASE MuOnlineB;
GO

-- Verifique que ambos existem
SELECT name, database_id, create_date
FROM sys.databases
WHERE name IN ('MuOnlineA', 'MuOnlineB');

Depois configure duas DSNs ODBC 32-bit distintas, uma apontando para cada banco:

ODBC (32-bit):
- DSN "MuOnlineA"  ->  banco MuOnlineA
- DSN "MuOnlineB"  ->  banco MuOnlineB

Opção B — Duas instâncias de SQL Server

Vale a pena se você precisa de isolamento forte de recursos, versões diferentes de SQL Server, ou limites de memória por instância. Cada instância tem sua própria porta (ex.: instância padrão em 1433, instância nomeada SQLEXPRESS2 em outra porta). É mais pesado e mais complexo de manter — só escolha se tiver um motivo concreto.

> Cuidado clássico: apontar as duas DSNs (ou os dois DataServers) para o mesmo banco por engano. Se isso acontecer, os dois servidores gravam personagens na mesma base e você terá corrupção lógica de dados. Confira DSN por DSN.

Passo 3 — Configurar o Servidor A

Ajuste os arquivos do Servidor A com as portas e a DSN dele. Exemplos genéricos (chaves variam por emulador):

; ServidorA\DataServer\DataServer.ini
[DataServer]
DataServerPort=55557
[Database]
DSN=MuOnlineA

; ServidorA\GameServer\GameServer.ini
[Network]
GameServerPort=55901
[JoinServer]
JoinServerIP=127.0.0.1
JoinServerPort=55555
[Database]
DSN=MuOnlineA

; ServidorA\ConnectServer\ConnectServer.ini
[ConnectServer]
Port=44405
[GameServer1]
IP=SEU_IP_PUBLICO
Port=55901

Passo 4 — Configurar o Servidor B (o passo onde todos erram)

Agora repita para o Servidor B, mas trocando todas as portas e a DSN. É aqui que a maioria dos iniciantes falha ao copiar os arquivos do A sem revisar:

; ServidorB\DataServer\DataServer.ini
[DataServer]
DataServerPort=55567         ; <- diferente do A
[Database]
DSN=MuOnlineB                ; <- banco diferente

; ServidorB\GameServer\GameServer.ini
[Network]
GameServerPort=55911         ; <- diferente do A
[JoinServer]
JoinServerIP=127.0.0.1
JoinServerPort=55565         ; <- diferente do A
[Database]
DSN=MuOnlineB

; ServidorB\ConnectServer\ConnectServer.ini
[ConnectServer]
Port=44415                   ; <- diferente do A
[GameServer1]
IP=SEU_IP_PUBLICO
Port=55911

Revise linha por linha: se qualquer porta coincidir com a do Servidor A, o processo do B não vai subir.

Passo 5 — Firewall e portas públicas

Abra no firewall apenas as portas que os jogadores precisam alcançar (ConnectServer e GameServer de cada servidor). As portas de DataServer e JoinServer são internas e devem permanecer fechadas para a internet:

# Servidor A - portas públicas
netsh advfirewall firewall add rule name="MU-A Connect" dir=in action=allow protocol=TCP localport=44405
netsh advfirewall firewall add rule name="MU-A Game"    dir=in action=allow protocol=TCP localport=55901

# Servidor B - portas públicas
netsh advfirewall firewall add rule name="MU-B Connect" dir=in action=allow protocol=TCP localport=44415
netsh advfirewall firewall add rule name="MU-B Game"    dir=in action=allow protocol=TCP localport=55911

# DataServer/JoinServer (55557,55555,55567,55565): NAO abrir para a internet

Passo 6 — Ordem de inicialização

Cada servidor sobe na ordem canônica, e você inicia um servidor completo antes do outro para facilitar o diagnóstico. Um .bat por servidor ajuda:

@echo off
echo Iniciando Servidor A...
start "" "E:\MU\ServidorA\DataServer\DataServer.exe"
timeout /t 3
start "" "E:\MU\ServidorA\JoinServer\JoinServer.exe"
timeout /t 3
start "" "E:\MU\ServidorA\GameServer\GameServer.exe"
timeout /t 5
start "" "E:\MU\ServidorA\ConnectServer\ConnectServer.exe"
echo Servidor A no ar.

Faça um IniciarB.bat equivalente apontando para a pasta ServidorB. Suba o A, confirme que está estável, e só então suba o B.

Dimensionamento de recursos e conflitos

Dois servidores na mesma máquina competem por CPU, RAM, disco e rede. Pontos de atenção:

• RAM: cada GameServer e o SQL Server consomem memória. Configure o max server memory do SQL Server para não engolir toda a RAM e sufocar os GameServers.
• CPU: em VPS com poucas vCPUs, um evento pesado no Servidor A pode causar lag no B. Se possível, use afinidade de CPU para separar cargas.
• Disco: os dois bancos gravam no mesmo disco; um SSD é praticamente obrigatório para dois servidores.
• Portas efêmeras/DSN: revalide que não há sobreposição alguma. Use netstat -ano | findstr LISTENING para conferir o que já está escutando antes de subir o segundo servidor.

Erros comuns e soluções

Checklist de lançamento

• Máquina dimensionada com folga de RAM/CPU/disco para dois servidores
• Backup de qualquer servidor pré-existente feito
• Mapa de portas planejado e documentado (sem sobreposição)
• Pastas totalmente separadas para Servidor A e Servidor B
• Dois bancos criados (ou duas instâncias) e verificados
• Duas DSNs ODBC 32-bit distintas, cada uma no banco certo
• Configs do Servidor A revisadas (portas + DSN A)
• Configs do Servidor B revisadas linha a linha (portas + DSN B)
• Firewall abrindo só ConnectServer e GameServer de cada servidor
• Portas internas (DataServer/JoinServer) fechadas para a internet
• .bat de inicialização para cada servidor, na ordem correta
• Servidor A sobe e estabiliza sozinho antes de subir o B
• Teste de conta: criar personagem no A e confirmar que NÃO aparece no B
• Teste de carga: evento em um sem derrubar o outro
• max server memory do SQL Server limitado para não sufocar os GameServers

Com portas únicas, bancos separados e pastas isoladas, dois servidores de MU Online convivem tranquilamente na mesma máquina. O segredo é disciplina: planeje o mapa de portas antes, revise o segundo servidor arquivo por arquivo e valide o isolamento com testes reais de conta e de carga antes de abrir para os jogadores.

Perguntas frequentes