Como migrar seu servidor de MU Online de uma VPS para um servidor dedicado
Planeje e execute a migração do seu servidor de MU Online de uma VPS compartilhada para um servidor dedicado, com checklist de hardware, cutover de DNS, migração de banco de dados e janela de manutenção sem perda de dados.
Migrar um servidor privado de MU Online de uma VPS para um servidor dedicado é o passo natural quando a comunidade cresce e os limites de CPU, IO de disco e rede compartilhados começam a gerar lag, timeout de login e travamentos no horário de pico. Diferente de uma simples atualização de plano, essa
Migrar um servidor privado de MU Online de uma VPS para um servidor dedicado é o passo natural quando a comunidade cresce e os limites de CPU, IO de disco e rede compartilhados começam a gerar lag, timeout de login e travamentos no horário de pico. Diferente de uma simples atualização de plano, essa migração envolve trocar de host físico, o que normalmente significa novo IP, nova instalação de sistema operacional e a necessidade de mover um banco de dados MySQL inteiro sem perder um único personagem. Este tutorial cobre o planejamento de hardware, a preparação do ambiente novo, a migração de dados e arquivos, a troca de DNS e o cutover final com o menor tempo de indisponibilidade possível, além dos erros que mais derrubam essa migração na prática.
Por que migrar de VPS para dedicado
Uma VPS compartilha CPU, disco e rede com outras VPS no mesmo host físico, mesmo quando o plano promete recursos "garantidos". Em um servidor de MU com muitos jogadores simultâneos, o MySQL faz um volume alto de queries por segundo (login, movimentação, guardas de trade, logs de PK), e é justamente o IO de disco compartilhado que costuma ser o gargalo — não a CPU. Um servidor dedicado entrega disco (idealmente NVMe) e rede exclusivos, eliminando o "vizinho barulhento" que rouba performance em horários de pico. Além disso, dedicados costumam ter link de rede maior e roteamento mais estável, reduzindo picos de latência que os jogadores sentem como "ping spike".
Avaliando se o momento é certo
Antes de gastar com um dedicado, meça os sintomas reais. Um top/htop mostrando IO wait alto durante o horário de pico, junto com queries lentas no slow_query_log do MySQL, é o principal indicador de que o gargalo é a VPS, não o seu banco mal indexado. Vale confirmar isso antes, porque migrar para dedicado não resolve queries mal escritas — só dá mais fôlego de hardware.
| Sinal | Indica migração necessária? | Como confirmar |
|---|---|---|
| CPU constantemente acima de 80% no pico | Sim, se já otimizou queries | htop / vmstat no horário de pico |
| IO wait alto, disco não é NVMe | Sim, forte indício | iostat -x 1 |
| Banco com índices ausentes | Não ainda — otimize primeiro | EXPLAIN nas queries mais lentas |
| Rede com picos de latência para vários países | Depende do datacenter, não só do host | mtr/traceroute |
| Menos de 100 CCU e sem lag reportado | Não, VPS ainda serve | Feedback da comunidade + métricas |
Escolhendo o hardware do dedicado
Para um servidor de MU Online com centenas de jogadores simultâneos, o gargalo real quase sempre é IO de disco e RAM disponível para o MySQL fazer cache, não CPU bruta. Priorize disco NVMe em RAID 1 (redundância), pelo menos 32 GB de RAM (para o buffer pool do InnoDB crescer confortavelmente) e uma CPU com bom clock por núcleo (o GameServer e o MySQL escalam melhor com clock alto do que com muitos núcleos fracos).
| Item | Mínimo recomendado | Ideal para 300+ CCU |
|---|---|---|
| CPU | 4 núcleos, clock alto | 8 núcleos, clock alto |
| RAM | 16 GB | 32-64 GB |
| Disco | SSD SATA | NVMe em RAID 1 |
| Rede | 100 Mbps dedicados | 1 Gbps dedicados |
| Datacenter | Uptime declarado 99.9% | Redundância de energia e link |
Planejando a janela de manutenção
Comunique a data e horário com pelo menos 3-5 dias de antecedência, em todos os canais (Discord, site, launcher). Escolha o horário de menor movimento (geralmente madrugada) e estime a duração real com base em um dry-run — não apenas em uma suposição otimista. Um erro comum é anunciar "30 minutos" e a migração real levar 3 horas porque o dump do banco não foi testado antes.
Preparando o servidor dedicado antes do cutover
Todo o trabalho pesado deve acontecer antes de tirar o servidor antigo do ar. Isso inclui: instalar o sistema operacional, configurar o MySQL/MariaDB com as mesmas versões (ou compatíveis) da origem, instalar o MuServer/emulador, copiar os arquivos estáticos do jogo (Data/, configs, mapas) e rodar um teste completo de boot do GameServer e ConnectServer apontando para um banco de teste. Só depois desse teste passar é que você agenda a janela real.
# No dedicado novo, testar se o MySQL sobe corretamente
sudo systemctl status mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'version';"
# Validar espaço em disco disponível antes da migração
df -hMigrando o banco de dados MySQL sem perda de dados
O passo mais crítico. Depois de colocar o servidor em manutenção real (ConnectServer recusando novos logins), gere o dump completo:
# Na VPS de origem, após bloquear novos logins
mysqldump -u root -p --single-transaction --routines --triggers MuOnline > mu_dump_final.sql
# Validar tamanho e integridade antes de transferir
ls -lh mu_dump_final.sql
md5sum mu_dump_final.sqlTransfira o dump via rsync ou scp para o dedicado (nunca por e-mail ou upload em serviço de terceiros, pelo volume e pela sensibilidade dos dados de conta). No destino, restaure e confira o md5sum do arquivo recebido antes de importar:
scp mu_dump_final.sql usuario@ip-do-dedicado:/backup/
mysql -u root -p MuOnline < mu_dump_final.sqlDepois da importação, rode uma checagem de sanidade: contagem de personagens, contagem de contas e a data do último login registrado devem bater com o que existia na origem no momento do dump.
Migrando arquivos estáticos e configurações
Além do banco, copie a pasta completa do servidor (executáveis do GameServer/ConnectServer/JoinServer, arquivos .txt/.xml de configuração, mapas, e quaisquer scripts de eventos customizados). Use rsync -avz para preservar permissões e evitar corrupção silenciosa em arquivos binários grandes. Revise strings de conexão com o MySQL em cada configuração — o dedicado terá um IP local (ou socket) diferente da VPS.
Ajustando DNS e IP fixo do cliente
Atualize o registro A do seu domínio para o novo IP do dedicado, e reduza o TTL do DNS para algo baixo (300 segundos) alguns dias antes da migração, para que a propagação seja rápida no momento do cutover. Se o cliente do jogo usa um IP fixo hardcoded em vez de domínio (comum em muitos launchers), você precisará distribuir uma atualização do cliente ou do launcher com o IP novo — nesse caso planeje isso com folga, pois a propagação de DNS não resolve esse caso.
| Item a atualizar | Onde | Prazo recomendado |
|---|---|---|
| Registro A do domínio | Painel do DNS | Reduzir TTL 3-5 dias antes |
| IP fixo no cliente/launcher | Config do launcher | Distribuir antes do cutover |
| Firewall do dedicado | ufw/iptables | Antes de abrir ao público |
| Portas do GameServer/ConnectServer | Firewall e roteador | Testado com dry-run |
Executando o cutover
- Anuncie o início da manutenção e bloqueie novos logins na VPS antiga.
- Gere o dump final do MySQL e valide o checksum.
- Transfira dump e arquivos para o dedicado.
- Restaure o banco e confirme contagens de sanidade.
- Suba GameServer, ConnectServer e JoinServer no dedicado e teste login com uma conta de GM.
- Atualize o DNS (ou distribua o IP novo pelo launcher).
- Mantenha a VPS antiga ligada, sem aceitar logins, por 24-48h como fallback.
- Anuncie a conclusão e monitore o dedicado nas primeiras horas de pico.
Mantendo a VPS antiga como fallback temporário
Não desligue nem cancele a VPS imediatamente. Mantenha-a ativa (sem receber tráfego de jogo) por pelo menos 24 a 48 horas após o cutover, com o dump mais recente guardado nela também. Se algo crítico falhar no dedicado, você consegue reverter o DNS rapidamente enquanto investiga, em vez de perder a base de jogadores por completo.
Erros comuns e soluções
| Sintoma | Causa provável | Solução |
|---|---|---|
| Personagens "sumidos" após migração | Dump feito com servidor ainda aceitando logins | Sempre bloquear login antes do dump final |
| GameServer não conecta ao MySQL no dedicado | String de conexão ainda aponta para IP antigo | Atualizar host/socket na configuração |
| Jogadores não conseguem entrar após o cutover | DNS não propagou ou TTL alto | Reduzir TTL dias antes; testar com nslookup |
| Lag persiste mesmo no dedicado | Configuração do MySQL não migrada/otimizada | Revisar my.cnf/buffer pool no destino |
| Firewall bloqueando portas do jogo | Regras não replicadas no dedicado | Conferir ufw/iptables antes do anúncio |
Checklist de migração
- Sintomas de gargalo confirmados (IO wait, CPU, queries lentas).
- Hardware do dedicado dimensionado e provisionado.
- Dry-run completo feito antes da janela real.
- Janela de manutenção anunciada com antecedência.
- Dump do MySQL gerado após bloqueio de login, com checksum validado.
- Arquivos estáticos e configs migrados via rsync.
- DNS/IP atualizado e testado.
- VPS antiga mantida como fallback por 24-48h.
Com o servidor rodando estável no dedicado, o próximo passo é revisitar sua estratégia de backup e monitoramento agora que você tem controle total do hardware — e, se ainda não tiver um processo documentado do zero, vale revisar o tutorial de criação de servidor de MU Online para conferir se algo ficou para trás na nova infraestrutura.
Perguntas frequentes
Quando faz sentido sair de uma VPS e ir para dedicado?
Quando o servidor passa de forma consistente de 150-200 jogadores simultâneos, ou quando você percebe picos de CPU/IO na VPS em horário de pico mesmo após otimizar o MySQL. Se o custo mensal do dedicado for menor que o de uma VPS de mesma capacidade, também é hora de migrar.
Quanto tempo de indisponibilidade devo esperar na migração?
Com planejamento e um dry-run prévio, a janela de manutenção real fica entre 30 minutos e 2 horas, dependendo do tamanho do banco de dados. A maior parte do trabalho (provisionar o dedicado, instalar dependências, testar) acontece antes, sem tirar o servidor do ar.
Preciso trocar o IP do servidor?
Sim, quase sempre, porque o dedicado tem IP próprio diferente da VPS. Isso exige atualizar o DNS do domínio e, geralmente, o IP fixo dentro do cliente do jogo (arquivo de configuração de conexão), então avise a comunidade com antecedência.
Como evito perder personagens e itens durante a migração?
Faça o dump final do MySQL somente após colocar o servidor em modo de manutenção (sem novas conexões), valide o hash/tamanho do dump, e só então derrube o servidor antigo. Nunca migre com o servidor de origem ainda aceitando logins.
Vale a pena migrar para um dedicado alugado ou montar o meu próprio hardware?
Um dedicado alugado (bare metal em datacenter) tem melhor uptime, redundância de energia e link, e suporte de hardware — geralmente compensa mais que hardware próprio em casa, que sofre com quedas de energia e upload residencial limitado.