MySQL 8.0ProxySQLReplicación
Ilustración editorial de arquitectura MySQL master-slave con ProxySQL al centro distribuyendo lecturas hacia réplicas y escrituras hacia el nodo principal, representando escalabilidad, routing SQL y alta disponibilidad.

MySQL Master–Slave con ProxySQL: sin tocar el código fuente

Si estás en un entorno donde tu base de datos MySQL empieza a sentir la presión de tráfico, una replicación master–slave + ProxySQL es una de las formas más limpias (y menos invasivas) de ganar escalabilidad y robustez sin tocar el código fuente de tu aplicación.

La idea es simple:

  • Master: solo recibe escrituras (INSERT, UPDATE, DELETE).
  • Slaves: sirven lecturas (SELECT) y actúan como respaldo.
  • ProxySQL: vive entre la app y los servidores MySQL, y decide “a quién” manda cada consulta.

Beneficios de integrar ProxySQL

No tocas el código fuente

Tu aplicación se sigue conectando a la misma IP, el mismo puerto y las mismas credenciales. Lo único que cambia detrás es el proxy, que decide si esa query va al master o a uno de los slaves.

  • Línea de conexión: sigue siendo host = proxy_ip, port = 6033.
  • No hace falta modificar DNS, app settings ni variables de entorno cada vez que agregas un slave.

Escalabilidad horizontal “transparente”

ProxySQL puede balancear las lecturas entre varios slaves, y tú puedes ir agregando más réplicas sin que la app lo sepa.

  • Balanceo circular, por peso, por latencia, etc.
  • Si un slave cae, el proxy lo saca de la ronda y sigue sirviendo desde los demás.

Failover elegante (sin tocar el front‑end)

Si el master muere y levantas un plan de failover (por ejemplo, un slave que se convierte en master), ProxySQL puede redirigir automáticamente las escrituras al nuevo master, siempre que lo configures a nivel de hostgroup y monitoreo.

  • Desde el punto de vista de la app, “la base sigue funcionando”.
  • No necesitas cambiar manuales ni scripts de despliegue.

Caché y reescribir de queries

ProxySQL puede cachear consultas de lectura repetitivas y, en algunos casos, reescribirlas para apuntar a índices o esquemas más eficientes.

  • Ideal para dashboards, reportes, y APIs que consultan siempre lo mismo.
  • Reduce carga directa sobre los servidores MySQL.

Monitoreo y visibilidad

Uno de los grandes valores de ProxySQL es que te da visibilidad en tiempo real del tráfico SQL:

  • Quién se conecta, desde qué IP, qué consultas se ejecutan.
  • Métricas de latencia, errores, y cuántas queries van a master vs slaves.

Con esto puedes:

  • Detectar queries lentas o “gallos” antes de que rompan producción.
  • Ajustar reglas de routing y prioridades según el tipo de carga.

Buenas prácticas para que todo vaya más rápido

1. Separar claramente read/write

  • Define reglas en ProxySQL que envíen todo INSERT/UPDATE/DELETE al hostgroup del master.
  • Envía la mayoría de los SELECT a los slaves, excepto donde necesites coherencia absoluta.

2. Monitoreo activo de los servidores

  • Habilita el monitor de ProxySQL para que pingue periódicamente a los MySQL.
  • Si un slave se cae, el proxy debe dejar de enviarle tráfico; si el master se cae, activa el failover hacia el nuevo master.

3. Conexiones y pools bien dimensionados

  • Ajusta max_connections por host para no sobrecargar el master.
  • Reutiliza conexiones con el backend (connection multiplexing) para que el overhead de abrir/cerrar conexiones no te coma recursos.

4. Evitar queries que maten el master

  • Usa las reglas de ProxySQL para filtrar o redirigir consultas que sabes que son pesadas (reportes grandes, exports) hacia slaves dedicados.
  • Si alguna consulta necesita master, marca el hostgroup explícito o usa un usuario de tipo adm de ProxySQL.

5. Réplica lo suficientemente sana

  • Asegúrate de que los slaves no estén en modo read_only solo por “protocolo”, sino porque el diseño lo exige.
  • Usa herramientas como pt‑heartbeat o similares para medir latencia de replicación y evitar que el proxy envíe lecturas a slaves muy atrasados.

6. Backups y tests de failover

  • Automatiza backups desde el master, pero también prueba periódicamente que el failover a un slave funciona sin romper la app.
  • Documenta el procedimiento: qué IPs cambian, qué reglas se editan en ProxySQL, qué pasa con las conexiones activas.

Pequeño resumen en una frase

Con MySQL master–slave + ProxySQL estás agregando un “director de tráfico” que maneja escrituras y lecturas, caching, balanceo y monitoreo, mientras tu código fuente sigue pensando que habla con un solo servidor.