CASO 06 / Infraestructura

Laboratorio de replicación MySQL y continuidad de datos

Un laboratorio de base de datos para analizar replicación, disponibilidad entre nodos y la diferencia entre continuidad y recuperación.

Contexto
Proyecto académico · Aporte principal en replicación
Mi rol
Implementación de replicación MySQL
Periodo
2025
Estado
Laboratorio académico implementado
Arquitectura general · relaciones simplificadas
  1. API de aplicación
  2. Selección de nodo
  3. Nodos MySQL
  4. Replicación

El problema

¿Qué ocurre con una aplicación cuando un nodo de base de datos deja de estar disponible? Este laboratorio examina replicación y selección de nodos desde la aplicación, con scripts de respaldo y utilidades de generación de carga.

Mi contribución

Implementé la replicación MySQL. La API, los scripts de respaldo y las herramientas de prueba descritas aquí aportan contexto al proyecto académico completo; no todos esos componentes se presentan como contribución individual mía.

Arquitectura técnica

El entorno utiliza nodos MySQL en contenedores. La API en Python usa FastAPI y aiomysql, verifica disponibilidad y sincronización entre nodos, e incorpora lógica de respaldo para elegir un nodo de base de datos.

Los scripts de respaldo trabajan con volcados SQL y registros binarios. Redis aparece en utilidades de eventos de respaldo y Locust permite generar carga de aplicación.

Continuidad y recuperación

La replicación ayuda a mantener datos disponibles entre nodos, pero también puede propagar cambios no deseados. Un respaldo cumple otro objetivo: conservar datos restaurables de forma independiente al estado actual del sistema.

Del mismo modo, poder elegir otro nodo no garantiza que cada failover preserve consistencia. El estado de sincronización y el comportamiento de operaciones en tránsito requieren análisis aparte.

Resultados y limitaciones

La implementación incluye configuración de replicación, verificación de nodos desde la aplicación, lógica de respaldo y scripts de copia. Este portafolio no afirma un RTO o RPO validados ni un procedimiento de restauración completo probado de extremo a extremo.

El etiquetado de respaldos también importa: que un script se llame “diferencial” no demuestra por sí solo una estrategia diferencial completa. Un reclamo de recuperación debe apoyarse en una restauración exitosa, no solo en un archivo exportado.

Lecciones de ingeniería

Este proyecto aporta una base práctica para pensar infraestructura con estado. La diferencia más importante está entre un servicio que sigue aceptando trabajo y un sistema cuyos datos pueden recuperarse correctamente.

SEGUIR EXPLORANDO

Proyectos relacionados.

Todos los proyectos
Infraestructura2025

Ver debajo de los contenedores

Desde métricas de kernel y cgroups hasta un servicio en Rust y Grafana: seguimiento del uso de recursos en toda la pila.

  • C
  • Rust
  • Docker
  • Grafana
Seguridad e investigación2026

Comprender la exposición inalámbrica

Una plataforma portátil Linux que convierte observaciones pasivas de Wi-Fi en investigación estructurada de seguridad.

  • Linux
  • Kismet
  • Python
  • PostgreSQL