Balanceo de carga y alta disponibilidad con MySQL: explicación paso a paso

PARA ENTENDER EL ESQUEMA

Sobre esta infografía

Cuando muchas personas entran a una web, cada una consulta información, pulsa botones o confirma compras. Por detrás se coordinan aplicaciones, conexiones y servidores con responsabilidades distintas.

La animación que acompaña esta entrada muestra esa coordinación mediante una arquitectura concreta: HAProxy distribuye las peticiones web, MySQL Router encamina las conexiones SQL e InnoDB Cluster mantiene los datos replicados y permite elegir otro principal si falla el actual.

Vamos a seguir tres situaciones: registrar un pedido, consultar un catálogo y continuar el servicio después de la caída del servidor principal.

1. Las piezas de la arquitectura

El ejemplo utiliza tres instancias de aplicación, cada una con su pool de conexiones y su Router local, y tres servidores MySQL dentro del mismo clúster.

Elemento

Función en la animación

Navegador

Envía peticiones HTTPS y recibe las respuestas de la web.

HAProxy

Selecciona una aplicación disponible: APP-A, APP-B o APP-C.

Aplicaciones

Validan la operación, ejecutan la lógica del negocio y solicitan acceso a los datos.

Pool de conexiones

Presta y reutiliza conexiones SQL dentro de cada aplicación.

MySQL Router

Encauza las conexiones hacia el servidor adecuado según la ruta y el estado del clúster.

MySQL A, B y C

Almacenan copias de los datos y participan en Group Replication.

InnoDB Cluster integra MySQL Server con Group Replication, la administración mediante MySQL Shell y el acceso mediante MySQL Router. En esta arquitectura se utiliza el modo single-primary: A es inicialmente el principal y B y C son secundarios.

Los Router dibujados junto a las aplicaciones representan procesos de software. Pueden ejecutarse en el mismo servidor que su aplicación, una disposición habitual que evita concentrar todas las conexiones en un único Router central.

2. Dos decisiones distintas: aplicación y servidor de datos

Al llegar una petición, HAProxy decide qué aplicación la atiende.

Puede utilizar, por ejemplo, una estrategia de reparto por turnos —round robin— junto con comprobaciones de salud. Los servidores que no superan los controles salen de la rotación según los umbrales configurados.

Después, cuando la aplicación necesita la base de datos, MySQL Router determina el destino de la conexión SQL.

La animación utiliza estas rutas del protocolo clásico de MySQL:

Tramo

Puerto del ejemplo

Uso

Navegador → entrada web

443

HTTPS.

Aplicación → Router local

6446

Ruta de lectura y escritura hacia el principal.

Aplicación → Router local

6447

Ruta de lectura hacia los secundarios, según la configuración.

Router → servidor MySQL

3306

Acceso al servidor de base de datos seleccionado.

Los puertos son configurables. 6446 y 6447 son entradas del Router; 3306 corresponde al servidor MySQL en este ejemplo.

En el dibujo, la entrada pública es HTTPS. Las aplicaciones, sus Router y el clúster pertenecen al entorno privado. El navegador se comunica con la aplicación web; esta realiza el acceso SQL con sus propias conexiones y credenciales.

Aquí se representa el enrutamiento básico por conexión. Una conexión destinada a B mantiene ese destino mientras se utiliza. La aplicación escoge la ruta de lectura o escritura; este esquema no representa un análisis automático de cada sentencia para enviarla a otro servidor.

3. Cómo interpretar las flechas y las pausas

La animación contiene 21 etapas, agrupadas en tres escenas. El color diferencia peticiones y control, escrituras, replicación, respuestas y fallos.

Unas etapas representan comunicación por la red y otras representan trabajo local. Obtener una conexión del pool o ejecutar una transacción dentro de InnoDB son operaciones distintas de enviar paquetes entre máquinas.

Las flechas verdes representan la distribución y confirmación lógica de la replicación. El protocolo real incluye más mensajes de coordinación de los que resulta útil dibujar.

Las pausas permiten leer los globos explicativos. No representan el tiempo real de una compra ni el tiempo de recuperación ante un fallo.

4. Primera escena: registrar un pedido, en diez pasos

Paso 1. El navegador envía la petición

El usuario confirma una compra. Su navegador envía una petición HTTPS a la entrada pública de la web.

Todavía no ha enviado una consulta SQL ni conoce qué servidor MySQL guardará el pedido.

Paso 2. HAProxy selecciona APP-A

El balanceador entrega esta petición a APP-A. APP-B y APP-C quedan disponibles para otras peticiones.

Durante este recorrido seguimos una sola operación. La respuesta la prepara la misma instancia que la está atendiendo.

Paso 3. APP-A pide una conexión al pool

La aplicación valida la solicitud y solicita una conexión de escritura. El pool puede prestarle una ya abierta o crear una si su configuración lo permite.

Mientras está prestada, la conexión se utiliza de forma exclusiva para ese trabajo. Al terminar, vuelve al pool y puede atender otra operación.

Si todas están ocupadas y se ha alcanzado el máximo, la soli