Como migrar o site do servidor de MU para outra hospedagem sem downtime

Migrar o site do servidor de MU Online para uma nova hospedagem é uma daquelas tarefas que assustam à primeira vista, porque o medo é sempre o mesmo: os jogadores caírem numa página fora do ar, cadastros se perderem ou o site voltar quebrado num horário de pico. A boa notícia é que, com planejamento, uma migração pode ser feita com zero downtime perceptível — o jogador continua entrando, cadastrando e votando enquanto você troca o chão embaixo dos pés. O segredo não é velocidade, é paralelismo: você prepara e valida o site inteiro no novo host antes de mandar qualquer visitante para lá, e só então redireciona o tráfego de forma controlada, mantendo o ambiente antigo de prontidão até a poeira baixar. Este tutorial percorre esse método passo a passo, do inventário inicial à troca de DNS e ao desligamento seguro do host antigo. Os exemplos assumem um site PHP com banco de dados, o padrão dos servidores de MU, mas o método vale para qualquer stack. Caminhos, painéis e nomes de serviço variam por hospedagem, então adapte ao seu provedor.

Pré-requisitos

Migração é uma operação sobre algo que já funciona. Se o seu site ainda não está no ar ou você está montando o servidor, comece pelo guia de como criar servidor de MU Online e volte aqui quando precisar mudar de hospedagem.

• Acesso completo ao host antigo (arquivos, banco e configuração).
• Uma nova hospedagem contratada e acessível (VPS ou hospedagem compartilhada com PHP compatível).
• Acesso ao painel de DNS do domínio (onde você edita registros A/CNAME).
• Acesso ao firewall do SQL Server do jogo, para liberar o IP do novo host.
• Ferramenta de transferência (rsync, SFTP ou o gerenciador de arquivos do painel).
• Um período de baixo movimento planejado para a troca final (madrugada, por exemplo).

O conceito: paralelismo, não substituição

O erro clássico é tratar a migração como uma troca instantânea: desligar o velho, ligar o novo. Isso garante downtime e pânico se algo falhar. O método sem downtime funciona ao contrário — os dois ambientes coexistem:

1. Você monta o site completo no novo host, apontando-o para o mesmo banco do jogo.
2. Testa o novo host acessando-o por IP direto, sem tocar no DNS.
3. Só quando o novo ambiente está 100% validado, aponta o DNS para ele.
4. Mantém o host antigo ligado durante toda a propagação do DNS.
5. Desliga o antigo apenas quando confirma que todo o tráfego já vai para o novo.

Como o banco de dados do jogo permanece único e no lugar, não há risco de perder cadastros — os dois hosts leem e escrevem no mesmo lugar.

Passo 1 — Inventário completo

Antes de copiar qualquer coisa, mapeie tudo que o site precisa. Um item esquecido é o que quebra a migração:

Passo 2 — Reduzir o TTL do DNS com antecedência

Este é o passo mais negligenciado e o mais importante para o "sem downtime". O TTL (time to live) define por quanto tempo os provedores guardam em cache o IP do seu domínio. Se ele estiver em 86400 (24h), a troca de IP pode levar um dia inteiro para propagar. Com 24 a 48 horas de antecedência, reduza o TTL do registro A para 300 segundos (5 minutos):

; Antes (padrão)
servidorx.com.   86400   IN   A   200.100.50.10

; Ajuste 48h antes da migração
servidorx.com.   300     IN   A   200.100.50.10

Fazendo isso com antecedência, quando você finalmente trocar o IP, a mudança propaga em minutos.

Passo 3 — Preparar o novo host em paralelo

Com o inventário em mãos, monte o novo ambiente sem tocar no DNS:

1. Instale a mesma versão de PHP e todas as extensões listadas no inventário.
2. Copie todos os arquivos do site. Com acesso SSH nos dois lados, o rsync é o mais confiável:

rsync -avz --progress \
  -e ssh usuario@host_antigo:/var/www/site/ \
  /var/www/site/

1. Ajuste o arquivo de configuração do site no novo host. As credenciais do banco continuam apontando para o SQL Server do jogo — que não se move —, então confirme que o novo host consegue alcançá-lo pela rede.

1. Libere o IP do novo host no firewall do SQL Server do jogo:

New-NetFirewallRule -DisplayName "SQL Site Novo Host" `
  -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress 203.0.113.25 -Action Allow

1. Reemita o certificado SSL para o novo host (com Let's Encrypt, gere já apontando para o domínio, validando por DNS se necessário para não depender ainda da troca de IP).

Passo 4 — Testar o novo host antes da troca

Nunca migre no escuro. Force sua própria máquina a enxergar o domínio no novo IP editando o arquivo hosts local, sem alterar o DNS público:

# Windows: C:\Windows\System32\drivers\etc\hosts
# Linux/Mac: /etc/hosts
203.0.113.25   servidorx.com www.servidorx.com

Agora, no seu navegador, servidorx.com resolve para o novo host, mas apenas para você. Teste tudo:

• Home carrega e mostra dados do jogo (rankings, online).
• Cadastro cria conta de fato no banco.
• Login funciona.
• Página de download e votos operam.
• Cron jobs rodam no novo host.
• HTTPS válido, sem alerta de certificado.

Só avance quando todos os fluxos passarem. Depois, remova a linha do hosts para voltar ao estado normal.

Passo 5 — A troca de DNS

Com o novo host validado e o TTL já baixo, faça a troca no horário de menor movimento. No painel de DNS, altere o registro A para o novo IP:

; Troca final
servidorx.com.   300   IN   A   203.0.113.25

A partir daqui, novos visitantes começam a cair no novo host à medida que o cache de 300s expira. Como o banco é o mesmo, quem ainda cai no host antigo durante a propagação também funciona normalmente — nada se perde.

Passo 6 — Monitorar a propagação

Acompanhe a propagação consultando o registro de vários pontos. Localmente:

nslookup servidorx.com 8.8.8.8
nslookup servidorx.com 1.1.1.1

Use também um verificador de DNS global para checar múltiplas regiões. Quando todos retornarem o novo IP, a propagação terminou. Enquanto isso, monitore os logs dos dois hosts para confirmar que o tráfego está migrando e que nenhum erro aparece no novo.

Passo 7 — Desligar o host antigo com segurança

Não desligue o host antigo assim que trocar o DNS. Espere a propagação completa mais uma margem de segurança (24 horas é prudente, cobrindo provedores que ignoram TTL). Antes de desligar de vez:

1. Confirme que os logs do host antigo pararam de receber tráfego relevante.
2. Faça um último backup completo dos arquivos e do banco antigos.
3. Remova a regra de firewall do SQL Server que liberava o IP do host antigo (se ele não for mais usado).
4. Só então cancele ou desligue o serviço antigo.

Depois de tudo estabilizado, restaure o TTL do DNS para um valor normal (3600 ou 86400) para reduzir consultas e aliviar os resolvers.

Erros comuns e soluções

Caso especial: migrar o banco também

Este tutorial assume que o banco do jogo permanece no lugar — o cenário mais comum e o mais seguro. Se você precisar mover o banco também, o zero downtime fica muito mais difícil, porque você não pode ter escritas simultâneas em dois bancos divergindo. Nesse caso, planeje uma janela de manutenção anunciada: coloque o site em modo manutenção, faça o dump final, restaure no novo banco, aponte o site e reabra. Não tente migrar banco em produção sem congelar as escritas.

Checklist de lançamento

• Inventário completo (PHP, extensões, credenciais, uploads, crons, SSL, .htaccess)
• TTL do DNS reduzido para 300s com 24–48h de antecedência
• Novo host montado com mesma versão de PHP e extensões
• Arquivos sincronizados via rsync/SFTP
• IP do novo host liberado no firewall do SQL Server do jogo
• SSL reemitido e válido no novo host
• Teste completo via arquivo hosts local (cadastro, login, votos, crons)
• Troca de DNS feita em horário de baixo movimento
• Propagação monitorada com nslookup e verificador global
• Host antigo mantido no ar até a propagação completa + margem
• Backup final e desligamento seguro do host antigo
• TTL restaurado para valor normal após estabilizar

Perguntas frequentes