Alta Disponibilidad MySQL¶

Un MySQL solo es un punto único de fallo: un disco, un kernel panic o un mantenimiento no planificado tumban toda la aplicación. Alta disponibilidad (HA) significa mantener más de una copia de la base de datos lista para asumir, con promoción automática y sin intervención manual en mitad de la madrugada.

Esta página trata de HA dentro del mismo centro de datos — la topología más común y la que resuelve la mayor parte de los fallos reales (hardware, host, rack, mantenimiento). Para distribución entre regiones y reducción de latencia entre países, consulte MySQL Multi-Región.

InteSys implementa esta arquitectura de las dos formas: en Kubernetes, con un operador a cargo del ciclo de vida de la base de datos, o en máquinas virtuales, con replicación clásica y un gestor de clúster. Ambas se ejecutan en br-sp-1 (Cirion SAO1) y br-sp-2 (Equinix SP3).

Qué resuelve la HA — y qué no¶

Los dos números que definen el proyecto:

• RPO (Recovery Point Objective) — cuántos datos es aceptable perder. Replicación asíncrona: segundos. Semisíncrona: prácticamente cero.
• RTO (Recovery Time Objective) — cuánto tiempo hasta volver. Failover automatizado: decenas de segundos. Manual: el tiempo que alguien tarde en despertarse.

Topología en Kubernetes¶

Para clientes que ya ejecutan sus aplicaciones en Kubernetes, MySQL vive en el propio clúster, gestionado por un operador MySQL que trata el aprovisionamiento, la replicación, el failover y el backup como estado declarativo.

El operador reconcilia la topología deseada; la aplicación usa un único service y el backup sale del clúster hacia almacenamiento de objetos.

• Topología declarativa — número de réplicas, versión de MySQL y política de backup en un manifiesto, versionado en Git junto a la aplicación.
• StatefulSet con volúmenes persistentes — cada instancia tiene su volumen, con snapshot de volumen cifrado y retención definida.
• Anti-affinity obligatoria — un pod de base de datos por nodo físico. Tres réplicas en el mismo hipervisor no son alta disponibilidad.
• Endpoint único con read/write split — escrituras en el primario, lecturas distribuidas entre las réplicas.
• Failover conducido por el operador — detección, promoción y reconfiguración de los demás nodos sin intervención.
• Backup y PITR fuera del clúster, en almacenamiento de objetos.

Topología en máquinas virtuales¶

Cuando la aplicación no está contenerizada — o cuando la base de datos debe quedar fuera del clúster por decisión de riesgo — la misma garantía se entrega con VMs dedicadas.

Un par de ProxySQL responde por una VIP y oculta la topología a la aplicación; el gestor de clúster observa la salud de los nodos y conduce la promoción.

• Tres nodos de base de datos — un primario y dos réplicas, en hosts físicos distintos.
• Replicación con GTID — reposicionamiento automático de la réplica tras el cambio de primario, sin cálculo manual de coordenadas del binlog.
• Capa de proxy en par — ProxySQL con VIP/keepalived, para que la aplicación nunca necesite saber cuál es el primario.
• Gestor de clúster — health check, quórum de decisión, promoción y fencing del nodo antiguo.
• Backup y binlog fuera de los nodos de base de datos.

¿Kubernetes o máquinas virtuales?¶

No hay una respuesta única: InteSys opera ambas topologías y la elección suele seguir dónde ya vive la aplicación.

Cómo funciona el failover¶

1. Detección — pérdida de contacto con el primario confirmada por más de un observador, para no reaccionar ante un fallo de red momentáneo.
2. Fencing — el primario antiguo se aísla antes de cualquier promoción. Sin eso, dos nodos aceptan escritura y el split-brain corrompe los datos.
3. Promoción — la réplica más avanzada asume, tras verificar el replication lag.
4. Redirección — el proxy pasa a apuntar al nuevo primario; la aplicación sigue usando la misma dirección.
5. Reconstrucción — el nodo antiguo vuelve al clúster como réplica, de forma automática o tras inspección, según la política acordada.

Modos de replicación¶

La combinación habitual: una réplica semisíncrona para garantizar el dato y una réplica asíncrona para atender lectura y backup sin impactar el tiempo de respuesta de las escrituras.

Monitorización que acompaña al clúster¶

Alta disponibilidad sin observabilidad es una apuesta. Todo clúster entregado incluye:

• replication lag por réplica, con alerta antes de que el retraso sea un problema;
• estado del gestor de clúster e histórico de promociones;
• saturación de conexiones y cola en el proxy;
• tasa de error y latencia de commit;
• éxito del backup y de la restauración de prueba — un backup nunca restaurado es una hipótesis, no una garantía.

Soberanía de datos¶

Todo el dato de este clúster permanece en Brasil. Las dos regiones de InteSys son brasileñas — br-sp-1 (Cirion SAO1), en Cotia/SP, y br-sp-2 (Equinix SP3), en el área metropolitana de São Paulo — y el dato solo sale del país si el cliente lo pide.

• Residencia de datos en Brasil — nodos primarios, réplicas, archivos de log de transacciones y backups permanecen en datacenter brasileño, sobre infraestructura operada por InteSys.
• LGPD sin transferencia internacional — en la configuración estándar no existe transferencia internacional de datos personales que documentar, ni base legal adicional que construir.
• Jurisdicción única — infraestructura brasileña, contrato brasileño y operación por equipo brasileño, sin la exposición a legislación extranjera de acceso a datos que alcanza a proveedores con sede fuera del país.
• Latencia como consecuencia — mantener el dato cerca del usuario brasileño es, a la vez, requisito de cumplimiento y ganancia de rendimiento.
• Sacar datos del país es una decisión explícita del cliente — cualquier copia fuera de Brasil existe solo cuando se solicita, y solo en volumen cifrado.

Snapshot de volumen cifrado¶

Además del backup completo con binlog para point-in-time recovery, el clúster en Kubernetes puede usar snapshots de volumen (VolumeSnapshot vía CSI): una copia del volumen entero, tomada en segundos, sin recorrer la base.

• Snapshot consistente — el operador coordina el flush y congela la escritura antes de disparar el snapshot, para que la restauración no dependa de recuperación tras fallo.
• Siempre en volumen cifrado — el dato está cifrado en reposo y el snapshot hereda ese cifrado; la clave la gestiona InteSys o la aporta el cliente.
• Copia cifrada en tránsito — la replicación del snapshot hacia otro destino viaja cifrada y se almacena cifrada en el destino.
• Retención y restauración probada — política de retención definida y restauración ejercitada periódicamente; un snapshot que nunca se restauró es una hipótesis, no un backup.
• Recuperación rápida — el snapshot devuelve el volumen entero en minutos; el backup completo más binlog sigue siendo lo que permite volver al instante anterior al DROP TABLE.

Cómo lo implementa InteSys¶

1. Dimensionamiento — volumen de datos, perfil de escritura, requisitos de RPO/RTO y ventana de mantenimiento.
2. Topología — decisión entre Kubernetes y VMs, número de réplicas y modo de replicación.
3. Aprovisionamiento — nodos distribuidos entre hosts físicos distintos, con anti-affinity y almacenamiento dedicado.
4. Capa de acceso — ProxySQL o service con read/write split, endpoint único para la aplicación.
5. Backup y PITR — backup completo más binlog en almacenamiento de objetos, fuera de los nodos de base de datos.
6. Prueba de fallo — tumbamos el primario en un entorno controlado y medimos el RTO real antes de entrar en producción.
7. Observabilidad y alertas — métricas, paneles y alertas conectados al equipo de operación.
8. Runbook — procedimiento documentado para los casos en que la automatización necesita decisión humana.

Próximos Pasos¶

• Alta Disponibilidad PostgreSQL — La misma arquitectura aplicada a PostgreSQL
• Alta Disponibilidad ClickHouse — Réplicas y shards para cargas analíticas
• MySQL Multi-Región — Latencia, réplicas de lectura y distribución geográfica
• Kubernetes — Clústeres gestionados donde operar la base de datos
• Centros de Datos InteSys — Detalles de las regiones br-sp-1 y br-sp-2