Redundância de banco de dados para servidores de MU Online
Implemente redundância de banco de dados no seu servidor de MU Online usando replicação, failover automático e backups em múltiplas camadas, para evitar perda de progresso e downtime prolongado.
Um servidor de MU Online que depende de um único banco de dados sem redundância está a uma falha de disco de perder todo o progresso dos jogadores. Redundância de banco de dados é a prática de manter cópias sincronizadas e mecanismos de contingência para que uma falha de hardware, rede ou serviço nã
Um servidor de MU Online que depende de um único banco de dados sem redundância está a uma falha de disco de perder todo o progresso dos jogadores. Redundância de banco de dados é a prática de manter cópias sincronizadas e mecanismos de contingência para que uma falha de hardware, rede ou serviço não signifique dados perdidos ou horas de downtime. Este tutorial cobre os conceitos, a configuração de replicação master-slave em MySQL, estratégias de failover e como isso se encaixa na operação diária de um servidor privado.
Por que redundância é diferente de backup
Backup é uma foto do banco em um ponto no tempo, útil para recuperação após corrupção ou erro humano, mas exige restauração manual e implica perda dos dados gerados depois do último snapshot. Redundância mantém uma ou mais cópias vivas e atualizadas quase em tempo real, permitindo continuar operando (ou voltar a operar rapidamente) mesmo se o servidor principal cair. Os dois mecanismos são complementares, não substitutos.
Arquiteturas de redundância mais comuns
| Arquitetura | Como funciona | Complexidade | Indicado para |
|---|---|---|---|
| Master-Slave (replicação assíncrona) | Um servidor grava, um ou mais replicam em modo leitura | Média | A maioria dos servidores de MU privado |
| Master-Master | Dois servidores aceitam escrita, replicam entre si | Alta | Servidores grandes com necessidade de alta disponibilidade |
| Cluster (Galera/InnoDB Cluster) | Múltiplos nós sincronizados, failover automático | Alta | Servidores de grande porte, times de infra dedicados |
| Backup incremental frequente | Snapshots a cada poucas horas, sem réplica viva | Baixa | Servidores pequenos, sem orçamento para segunda máquina |
Pré-requisitos para montar redundância
- Duas instâncias MySQL/MariaDB, idealmente em servidores físicos ou VPS diferentes.
- Acesso root a ambos os servidores de banco de dados.
- Conectividade de rede confiável entre master e slave (VPN ou rede privada do provedor, evitando expor a porta 3306 publicamente).
- Espaço em disco suficiente no slave para acomodar o volume total de dados do master.
Configurando replicação master-slave
No servidor master, habilite o binlog no arquivo de configuração (my.cnf ou my.ini):
[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_do_db = mu_onlineCrie um usuário dedicado à replicação:
CREATE USER 'replica_user'@'%' IDENTIFIED BY 'SenhaForteAqui123';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
FLUSH PRIVILEGES;No servidor slave, configure um server-id diferente e aponte para o master:
[mysqld]
server-id = 2CHANGE MASTER TO
MASTER_HOST='ip_do_master',
MASTER_USER='replica_user',
MASTER_PASSWORD='SenhaForteAqui123',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS= 0;
START SLAVE;Verificando o status da replicação
Depois de iniciar, confirme que a réplica está sincronizando corretamente:
SHOW SLAVE STATUS\GOs campos essenciais a observar são Slave_IO_Running e Slave_SQL_Running (ambos devem estar Yes) e Seconds_Behind_Master (idealmente próximo de 0). Um valor alto nesse último campo indica atraso na réplica, que pode ser causado por carga excessiva de escrita no master ou hardware inferior no slave.
Failover: o que fazer quando o master cai
Redundância só tem valor prático se o failover for rápido. Existem dois caminhos:
- Failover manual: um administrador detecta a queda, promove o slave (
STOP SLAVE; RESET MASTER;) e reaponta a connection string do GameServer para o novo endereço. Simples, mas depende de alguém perceber e agir rápido. - Failover automatizado: ferramentas como ProxySQL, Orchestrator ou MHA monitoram o master e promovem o slave automaticamente, redirecionando conexões sem intervenção manual. Mais complexo de configurar, mas reduz o downtime de minutos para segundos.
Comparando failover manual e automatizado
| Critério | Manual | Automatizado (ProxySQL/Orchestrator) |
|---|---|---|
| Tempo de resposta | Minutos a horas (depende de quem detecta) | Segundos a poucos minutos |
| Complexidade de setup | Baixa | Alta, exige ferramentas adicionais |
| Risco de erro humano | Alto sob pressão | Baixo, processo padronizado |
| Custo de manutenção | Baixo | Médio, exige monitoramento da própria ferramenta |
| Indicado para | Servidores pequenos/médios | Servidores com alta base de jogadores ativos |
Redundância não elimina a necessidade de monitoramento
Um slave desatualizado silenciosamente é pior do que não ter redundância, porque cria falsa sensação de segurança. Configure alertas (e-mail, Discord webhook) para quando Seconds_Behind_Master ultrapassar um limite (por exemplo, 30 segundos) ou quando Slave_IO_Running/Slave_SQL_Running pararem, para que o time de infra saiba imediatamente que a redundância está comprometida.
Combinando redundância com backup em camadas
Redundância cobre falha de hardware; backup cobre erro humano e corrupção lógica. Uma estratégia robusta combina os dois:
| Camada | Frequência | Proteção contra |
|---|---|---|
| Réplica slave em tempo real | Contínua | Falha de hardware/rede do master |
| Backup lógico (mysqldump) | A cada 4-6 horas | Erro humano, corrupção pontual |
| Backup físico (snapshot de disco) | Diário | Falha catastrófica, recuperação rápida |
| Backup externo (fora do datacenter) | Diário/semanal | Desastre no datacenter, ransomware |
Testando o plano de redundância periodicamente
Redundância nunca testada é redundância teórica. Agende simulações trimestrais de queda do master (em ambiente de homologação, se possível) para validar que o slave assume corretamente, que o GameServer reconecta sem corrupção de dados, e que a equipe sabe executar o procedimento de failover sem consultar documentação do zero.
Erros comuns e soluções
| Sintoma | Causa provável | Solução |
|---|---|---|
| Slave_IO_Running = No | Problema de rede ou credencial de replicação errada | Revise conectividade e usuário de replicação |
| Seconds_Behind_Master crescendo | Slave com hardware inferior ou carga alta no master | Aumente recursos do slave ou otimize queries do master |
| Dados divergentes entre master e slave | Escrita direta no slave por engano | Configure slave como read-only (read_only = 1) |
| Failover manual demorou demais | Falta de processo documentado e alertas | Documente o passo a passo e configure alertas automáticos |
| Réplica não inicia após reinício do servidor | Posição do binlog não persistida corretamente | Use GTID em vez de posição de log para maior resiliência |
| Downtime longo mesmo com redundância | Ausência de failover automatizado | Avalie ProxySQL/Orchestrator para reduzir tempo de resposta |
Checklist de redundância de banco de dados
- Réplica slave configurada e sincronizando (
Slave_IO/SQL_Running = Yes). - Usuário de replicação com senha forte e permissões mínimas necessárias.
- Slave configurado como read-only para evitar divergência.
- Alertas configurados para atraso de replicação ou falha.
- Processo de failover (manual ou automatizado) documentado.
- Backup lógico e físico configurados em camadas complementares.
- Simulação de failover testada em ambiente controlado.
Com a redundância no ar, o próximo passo natural é revisar a arquitetura geral de servidor para garantir que outros componentes (GameServer, ConnectServer, painel web) também tenham plano de contingência — confira o tutorial de criação de servidor de MU Online para revisar a base da infraestrutura completa.
Perguntas frequentes
Redundância de banco substitui a necessidade de backup?
Não. Redundância protege contra falha de hardware e indisponibilidade momentânea, mas não contra erro humano, corrupção lógica de dados ou um DELETE acidental que se replica instantaneamente para todos os nós. Backup continua sendo indispensável mesmo com redundância ativa.
Preciso de dois servidores físicos separados para ter redundância?
Idealmente sim, ou ao menos duas VPS em provedores/regiões diferentes. Ter réplica na mesma máquina física protege contra corrupção de dados, mas não contra falha de hardware, queda de energia ou problema de rede que afete a máquina inteira.
Qual a diferença entre replicação síncrona e assíncrona no MySQL?
Na replicação assíncrona (a mais comum em MU), o master confirma a transação sem esperar a réplica aplicar, o que é mais rápido mas pode gerar pequeno atraso (lag) na réplica. A síncrona espera confirmação da réplica antes de commitar, mais segura mas com latência maior — raramente usada em MU por causa da performance.
O que acontece com o GameServer durante um failover?
Depende de como o failover é implementado. Com um proxy de banco (como ProxySQL) ou script de failover automatizado, a troca pode ser quase transparente, com poucos segundos de reconexão. Sem automação, o GameServer trava até um administrador apontar manualmente a nova connection string para o slave promovido.
Replicação master-slave impacta a performance do servidor principal?
O impacto é mínimo na maioria dos casos, já que a replicação assíncrona não bloqueia o master esperando a réplica. O maior custo é de I/O e rede para transmitir o binlog, geralmente insignificante comparado à carga normal de um GameServer de MU.