Replicación MySQL Master-Slave para servidores de MU Online

La replicación MySQL Master-Slave es la técnica más usada para dar redundancia y distribuir la carga de lectura en servidores de MU Online que ya superaron la etapa inicial y necesitan más confiabilidad. A diferencia de un backup estático, la réplica se mantiene constantemente sincronizada con la base principal, permitiendo tanto contingencia contra fallas como alivio de carga en consultas pesadas. Este tutorial detalla la configuración completa usando GTID (el método recomendado actualmente), el monitoreo de lag y el procedimiento de promoción del slave.

Qué es la replicación Master-Slave y cuándo tiene sentido implementarla

En la replicación Master-Slave, el servidor master recibe todas las escrituras (todo lo que el GameServer registra: inicio de sesión, creación de personaje, movimiento de objetos, subida de nivel) y registra cada transacción en un log binario (binlog). El servidor slave lee ese binlog continuamente y aplica los mismos cambios en su propia copia de la base de datos. Tiene sentido implementarla cuando el servidor ya tiene una población estable, cuando las consultas administrativas/informes empiezan a impactar el rendimiento de la base principal, o como base para un plan de contingencia más serio que solo backups periódicos.

Requisitos técnicos previos

• Dos instancias de MySQL/MariaDB en la misma versión mayor (evita incompatibilidades de replicación).
• Red confiable entre los dos servidores, idealmente privada/VPN.
• Espacio en disco en el slave equivalente o mayor al del master.
• Acceso root a ambas instancias para la configuración inicial.
• Ventana de mantenimiento de bajo movimiento para el volcado inicial.

Habilitando GTID en el servidor master

GTID (Global Transaction Identifier) simplifica drásticamente la configuración y la recuperación de la replicación, eliminando la necesidad de rastrear manualmente el archivo y la posición del binlog. En el my.cnf del master:

[mysqld]
server-id = 1
log_bin = mysql-bin
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_format = ROW

Reinicia el servicio MySQL después del cambio.

Creando el usuario de replicación

CREATE USER 'repl_mu'@'%' IDENTIFIED BY 'SenhaForteReplicacao456';
GRANT REPLICATION SLAVE ON *.* TO 'repl_mu'@'%';
FLUSH PRIVILEGES;

Restringe el % a la IP específica del slave siempre que sea posible, reduciendo la superficie de ataque de este usuario privilegiado.

Haciendo el volcado inicial de la base de datos

Con el master aún en funcionamiento, genera un volcado consistente incluyendo la posición de GTID:

mysqldump --all-databases --single-transaction --gtid --master-data=2 \
  -u root -p > dump_inicial_mu.sql

La bandera --single-transaction evita un bloqueo prolongado en tablas InnoDB (el motor predeterminado de las tablas de cuentas en la mayoría de los emuladores), reduciendo el impacto en el GameServer durante la exportación.

Restaurando el volcado en el slave

Transfiere el archivo al servidor slave e impórtalo:

scp dump_inicial_mu.sql usuario@ip_do_slave:/tmp/
mysql -u root -p < /tmp/dump_inicial_mu.sql

Configurando el slave con GTID

En el my.cnf del slave:

[mysqld]
server-id = 2
log_bin = mysql-bin
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON

Reinicia el MySQL del slave y configura la conexión con el master:

CHANGE MASTER TO
  MASTER_HOST='ip_do_master',
  MASTER_USER='repl_mu',
  MASTER_PASSWORD='SenhaForteReplicacao456',
  MASTER_AUTO_POSITION = 1;
START SLAVE;

Validando el funcionamiento de la replicación

SHOW SLAVE STATUS\G

Confirma Slave_IO_Running: Yes, Slave_SQL_Running: Yes y observa Seconds_Behind_Master. Una prueba práctica adicional es crear un personaje de prueba en el GameServer conectado al master y verificar, pocos segundos después, si el registro aparece en el slave mediante una consulta directa.

Tabla de parámetros importantes de configuración

Monitoreando el lag de replicación continuamente

Configura un script simple que se ejecute cada minuto y alerte si Seconds_Behind_Master supera un límite aceptable (recomendación: 5-10 segundos para servidores de MU, donde la experiencia del jugador depende de datos actualizados rápidamente):

#!/bin/bash
LAG=$(mysql -u root -p"senha" -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master | awk '{print $2}')
if [ "$LAG" -gt 10 ]; then
  echo "ALERTA: lag de replicación en ${LAG}s" | ./notify_discord.sh
fi

Usando el slave para aliviar la carga de lectura

Después de validar la replicación, redirige las consultas de lectura no críticas al slave: informes administrativos del panel web, rankings, consultas de auditoría y estadísticas. Mantén todas las escrituras y lecturas críticas en tiempo real (inicio de sesión, verificación de objeto durante un intercambio) apuntando al master, ya que el slave puede tener algunos segundos de atraso.

Procedimiento de promoción del slave en caso de falla del master

Cuando el master falla, el slave debe promoverse manualmente (sin una herramienta de orquestación automatizada):

1. Confirma que el master realmente está indisponible (no es solo lentitud de red).
2. En el slave, ejecuta STOP SLAVE; y luego RESET SLAVE ALL; para sacarlo del modo réplica.
3. Desactiva read_only (SET GLOBAL read_only = OFF;).
4. Reapunta la connection string del GameServer y del panel web a la IP del (ahora ex-)slave.
5. En cuanto el antiguo master vuelva, reconfigúralo como slave del nuevo master antes de reintroducirlo, nunca al revés.

Errores comunes y soluciones

Lista de verificación de replicación MySQL Master-Slave

• GTID habilitado en master y slave (gtid_mode = ON).
• Usuario de replicación creado con el permiso mínimo necesario.
• Volcado inicial hecho con --single-transaction --gtid y restaurado en el slave.
• SHOW SLAVE STATUS confirmando que los threads IO y SQL están funcionando.
• read_only activado en el slave para prevenir escritura accidental.
• Monitoreo de lag configurado con alerta automática.
• Procedimiento de promoción del slave documentado y probado.
• Parte de las lecturas administrativas redirigidas al slave.

Con la replicación funcionando, el siguiente paso es integrar esto a un plan general de contingencia de infraestructura, cubriendo también el GameServer y el ConnectServer — el tutorial de creación de servidor de MU Online trae la base completa para quien esté estructurando o revisando este entorno.

Preguntas frecuentes