MySQL Multi-Región¶

Las aplicaciones que se ejecutan en una región y acceden a una base de datos MySQL en otra pueden degradarse de forma severa incluso cuando el servidor de base de datos tiene CPU, memoria y disco de sobra. El cuello de botella rara vez es MySQL: es la red entre la aplicación y la base de datos.

Cada operación SQL exige al menos una ida y vuelta (round trip) por la WAN. Una transacción con cinco comandos paga cinco veces la latencia del enlace, y cualquier pérdida de paquetes añade retransmisiones TCP, picos de tiempo de respuesta y, en el límite, timeouts en la aplicación.

InteSys actúa en todas las capas de este problema, desde optimizaciones transparentes para sistemas heredados hasta arquitecturas regionales completas con replicación, caché y distribución geográfica de los datos — operando desde las dos regiones brasileñas Tier III: br-sp-1 (Cirion SAO1, Cotia/SP) y br-sp-2 (Equinix SP3, Tamboré/SP).

El problema¶

En una aplicación tradicional, una sola transacción ejecuta una secuencia como:

BEGIN → SELECT → UPDATE → INSERT → COMMIT

Con la base de datos en otra región, el tiempo de la transacción lo dicta la red: cinco comandos, cinco RTT, más las retransmisiones causadas por la pérdida de paquetes.

Entre br-sp-1 y br-sp-2 la latencia es de pocos milisegundos — ambas regiones están en el área metropolitana de São Paulo y se interconectan mediante enlaces Lan2Lan o túneles cifrados. Un enlace Brasil ↔ Estados Unidos opera en otro orden de magnitud, por encima de cien milisegundos de RTT. Esa diferencia define qué consultas pueden cruzar la WAN y cuáles deben responderse localmente.

Los objetivos de una arquitectura regional son:

• reducir la cantidad de accesos SQL que cruzan la WAN;
• acercar las lecturas y los datos de alta frecuencia a la aplicación;
• mantener las escrituras consistentes y controladas;
• aumentar la tolerancia a la inestabilidad de red;
• preservar la compatibilidad con aplicaciones heredadas siempre que sea posible;
• permitir una evolución gradual, sin reescribir el sistema.

Catálogo de arquitecturas¶

1. Conectividad resiliente entre regiones¶

Antes de tocar la base de datos, estabilizamos el transporte: caminos redundantes, VPN, enrutamiento alternativo y observabilidad continua de RTT, jitter y pérdida de paquetes.

Indicado para: entornos con pérdida de paquetes, rutas inestables o dependencia de un único camino WAN. Beneficio: estabilidad y previsibilidad. Limitación: no elimina la latencia física entre regiones.

2. ProxySQL junto a la aplicación¶

ProxySQL se instala en la misma región que la aplicación, entre ella y el MySQL remoto. Centraliza conexiones, mantiene pools persistentes y permite aplicar reglas de enrutamiento y caché de consultas.

Indicado para: aplicaciones heredadas, alto volumen de conexiones o necesidad de una capa de control sin cambiar el código. Beneficios: pooling de conexiones, control centralizado de queries, observabilidad por query digest, base para evolucionar a réplicas locales y posibilidad de caché selectiva. Limitación: las consultas no cacheadas siguen accediendo a la región remota.

3. Réplica de lectura en Brasil¶

El primario permanece donde está y se mantiene una réplica asíncrona en br-sp-1 o br-sp-2. ProxySQL dirige las lecturas adecuadas a la réplica local y mantiene las escrituras en el primario.

Indicado para: aplicaciones con volumen relevante de lectura y tolerancia a consistencia eventual en parte de las consultas. Beneficios: SELECT locales con baja latencia, menor uso de la WAN y reducción significativa del tiempo medio de respuesta — sin convertir la réplica en escribible. Punto de atención: las lecturas inmediatamente posteriores a una escritura pueden necesitar ir al primario para garantizar consistencia.

4. Enrutamiento selectivo por query¶

En lugar de enviar todo SELECT a la réplica, mapeamos qué consultas toleran consistencia eventual y creamos reglas específicas en ProxySQL, por digest, tabla o usuario.

Catálogos, informes y datos de referencia van a la réplica local; saldo, checkout, SELECT ... FOR UPDATE y lectura tras escritura permanecen en el primario.

Beneficio: adopción segura y progresiva, consulta a consulta, sin apostarlo todo de una vez.

5. Caché regional con Valkey/Redis¶

Los datos repetitivos se almacenan en un Valkey o Redis en la región de la aplicación, reduciendo drásticamente el número de consultas a la base remota. Buenos candidatos: configuraciones, perfiles, permisos, catálogos, sesiones, resultados de consultas costosas y datos derivados.

Indicado para: datos con alta tasa de lectura y una estrategia de invalidación bien definida. Beneficio: las consultas más frecuentes se responden localmente, sin importar la distancia hasta MySQL.

6. Arquitectura combinada — ProxySQL + réplica + caché¶

Es la arquitectura con la mejor relación entre ganancia, riesgo y complejidad para sistemas ya en producción, y la recomendación estándar de InteSys.

La aplicación habla con un endpoint local. ProxySQL decide el destino de cada consulta; la caché atiende los datos de alta frecuencia; la réplica atiende las lecturas seleccionadas; el primario sigue siendo la única autoridad de escritura.

Indicado para: sistemas críticos que deben evolucionar sin una reescritura profunda.

7. Replicación parcial¶

No toda la base de datos necesita traerse a Brasil. Es posible replicar solo los databases o conjuntos de datos que la aplicación brasileña realmente consume.

Indicado para: bases muy grandes, dominios bien separados o escenarios en los que solo una fracción de los datos debe estar cerca de la aplicación. Beneficios: menor volumen de replicación, menor costo de infraestructura y segmentación por dominio funcional.

8. Capa regional de API / servicio de datos¶

En sistemas nuevos o en modernización, la aplicación deja de ejecutar decenas de comandos SQL por la WAN y pasa a llamar a una API regional. Ese servicio ejecuta la transacción junto al primario o combina caché y réplica local.

Indicado para: modernización, microservicios y flujos transaccionales con muchos round trips. Beneficio: cambia varios round trips SQL por una única llamada de negocio.

9. Sharding geográfico / ownership regional¶

Para sistemas que necesitan escribir localmente en más de una región, los datos se particionan por cliente, tenant, país o dominio funcional: los tenants brasileños escriben en Brasil, los estadounidenses en EE. UU., y cada región replica lo que la otra necesita solo para lectura.

Indicado para: plataformas globales y SaaS multi-tenant. Complejidad: alta — exige reglas claras de ownership, consistencia y enrutamiento.

Alta disponibilidad entre br-sp-1 y br-sp-2¶

Reducir la latencia resuelve el rendimiento, no la disponibilidad. Cuando la base de datos es crítica, InteSys distribuye la solución entre las dos regiones brasileñas, independientes en energía, refrigeración y operador, y separadas por pocos milisegundos.

Primario en una región, standby en la otra, ProxySQL en alta disponibilidad en ambas y promoción controlada en caso de falla.

Cómo funciona en la práctica:

• Primario en br-sp-1, standby en br-sp-2 (o al revés) — la proximidad permite replicación semisíncrona, con una ventana de pérdida de datos cercana a cero, inviable en enlaces intercontinentales.
• ProxySQL en alta disponibilidad en ambas regiones, con VIP/keepalived y el mismo conjunto de reglas, para que la aplicación siga usando un único endpoint.
• Failover controlado: promoción de la réplica con verificación de replication lag y fencing del primario anterior, evitando split-brain.
• Backups y PITR en almacenamiento separado de ambas regiones, con pruebas periódicas de restauración.
• Las lecturas aprovechan el standby: la región secundaria no queda ociosa — atiende consultas de lectura mientras sigue al primario.

MySQL gestionado en Kubernetes¶

Para clientes que ya ejecutan sus aplicaciones en Kubernetes, InteSys también opera MySQL dentro del clúster, con un operador MySQL a cargo del ciclo de vida de la base de datos.

El operador reconcilia el estado deseado del clúster de base de datos; la aplicación accede a un único service, y el backup sale del clúster hacia almacenamiento de objetos.

Lo que entrega este enfoque:

• Topología declarativa — número de réplicas, versión de MySQL y política de backup descritos como manifiesto, versionados en Git junto a la aplicación.
• StatefulSet con almacenamiento persistente — cada instancia tiene su volumen, con snapshots y política de retención.
• Failover automatizado por el operador — promoción de réplica y reconfiguración de la topología sin intervención manual.
• Endpoint único con read/write split — las escrituras van al primario, las lecturas se distribuyen entre las réplicas, igual que hace ProxySQL fuera del clúster.
• Distribución entre br-sp-1 y br-sp-2 — reglas de anti-affinity reparten los pods entre regiones, de modo que perder una región no derriba el quórum.
• Backup y PITR fuera del clúster, en almacenamiento de objetos, porque un backup dentro del mismo clúster no es un backup.

Matriz de decisión¶

Por escenario¶

Lo que no debe ir a la réplica¶

La regionalización de lectura solo es segura si las consultas sensibles a la consistencia permanecen en el primario:

Monitorear el replication lag es parte de la solución, no un extra: las reglas de enrutamiento deben reaccionar al retraso y sacar la réplica de operación cuando se queda atrás.

Cómo lo implementa InteSys¶

1. Diagnóstico — medición de RTT, jitter, pérdida de paquetes, volumen de conexiones y comportamiento transaccional.
2. Observabilidad — identificación de las queries más frecuentes, más lentas y más sensibles a la WAN, por digest.
3. ProxySQL — introducción de la capa de acceso centralizada y medible.
4. Regionalización de la lectura — réplica MySQL brasileña, cuando aplique.
5. Caché — selección de los datos adecuados para Valkey/Redis y definición de la estrategia de invalidación.
6. Reglas de consistencia — lecturas críticas en el primario, consultas seguras en la región local.
7. Alta disponibilidad — eliminación de puntos únicos de falla en ProxySQL, caché y base de datos, con distribución entre br-sp-1 y br-sp-2.
8. Evolución arquitectónica — API regional, replicación parcial, Kubernetes o sharding geográfico, según la necesidad.

Cada etapa se mide antes de avanzar a la siguiente, lo que permite detenerse en el punto en que la ganancia ya cumple el objetivo.

Próximos Pasos¶

• Kubernetes — Clústeres gestionados donde se puede operar MySQL
• Datacenters InteSys — Detalles de las regiones br-sp-1 y br-sp-2
• Visión General de DevOps — Catálogo completo de servicios