Réplicas de Banco de Dados: Lendo sem Sobrecarregar o Servidor Principal

Réplicas de banco de dados são um daqueles tópicos de infraestrutura que geram muita curiosidade e pouca necessidade real pra maioria dos OTServers. Vale entender o conceito — e, principalmente, saber quando ele realmente se aplica ao seu caso.

O conceito básico

Numa configuração master-replica, você tem um banco principal (master) que recebe todas as escritas (INSERT, UPDATE, DELETE), e uma ou mais cópias (réplicas) que recebem automaticamente tudo que acontece no master, mas só são usadas pra leitura (SELECT). Assim, consultas pesadas de leitura — relatórios, rankings complexos — podem ser direcionadas pra réplica, sem competir por recursos com as escritas críticas do jogo em tempo real.

Quando isso realmente faz sentido

Honestamente: pra maioria dos OTServers, mesmo com algumas centenas de jogadores simultâneos, um único banco MySQL bem configurado dá conta tranquilamente. Réplicas de leitura começam a fazer sentido quando:

Você já tentou otimizar queries e índices e o banco principal ainda está no limite de CPU/IO.
Tem relatórios ou dashboards pesados (analytics, admin) rodando com frequência, competindo com o tráfego do jogo.
Seu servidor já tem volume real de milhares de jogadores simultâneos — uma escala que poucos OTServers brasileiros alcançam.

Como funciona na prática

O MySQL usa replicação baseada em log binário: o master grava um log de tudo que muda, e a réplica lê esse log e aplica as mesmas mudanças, com um pequeno atraso (geralmente de milissegundos, mas pode crescer sob carga pesada). Isso significa uma réplica nunca está 100% "ao vivo" — existe uma pequena janela de atraso que precisa ser levada em conta.

# No master: habilita o log binario (my.cnf)
[mysqld]
server-id = 1
log_bin = mysql-bin

# Na replica: aponta pro master
CHANGE MASTER TO
  MASTER_HOST='ip_do_master',
  MASTER_USER='usuario_replicacao',
  MASTER_PASSWORD='senha',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=0;
START SLAVE;

O cuidado com dados "quase em tempo real"

Se um jogador faz uma compra e, um segundo depois, uma consulta bate na réplica (que ainda não recebeu a atualização), ele pode ver dados desatualizados por um instante. Pra informação crítica (saldo, inventário), sempre leia do master. Réplicas são pra leitura que tolera um pequeno atraso — rankings, relatórios, estatísticas públicas.

Antes de configurar réplicas, invista em otimizar índices e revisar queries lentas do seu banco atual — na grande maioria dos casos, isso resolve o problema de performance sem a complexidade operacional extra de manter um segundo servidor sincronizado.