Fecha de la Actividad | |
Versión | 1.0 |
Responsable | |
Participantes | |
Duración Estimada | 3-4 horas total |
Entorno de Prueba |
|
Estado de la Actividad | PROGRAMADA |
Simulación de Caída y Recuperación de Base de Datos
Realizar una prueba de seguridad en la que se simule la caída de la base de datos principal y se lleve a cabo un proceso de restauración a partir de una copia de seguridad.
Objetivo
Evaluar la capacidad de recuperación de un clúster RDS Aurora MySQL ante tres escenarios de fallo: una caída del servicio en la región, un borrado accidental de tablas y un error en el código que dañe la conexión a la base de datos. Se busca validar los procedimientos de restauración desde copias de seguridad y la continuidad del servicio utilizando réplicas en dos zonas de disponibilidad (AZ).
Recursos Necesarios
Acceso a la consola de AWS (RDS, Aurora)
Snapshots recientes de Aurora y configuración de réplicas en dos AZ
Credenciales y permisos para ejecutar comandos SQL y modificar código
Equipo técnico con experiencia en AWS y MySQL
Acceso a la base de datos mediante la conexión con el Bastion
Escenarios
La práctica se divide en tres simulaciones independientes:
Caída del servicio en la región: Se forzará offline el clúster primario de Aurora en la región principal para simular un fallo completo del servicio, activando la réplica en otra AZ o restaurando desde un snapshot si es necesario.
Borrado accidental de tablas o base de datos: Se ejecutarán comandos SQL (DROP TABLE) en la base de datos para simular una eliminación no intencionada, seguida de la recuperación desde un punto en el tiempo o snapshot.
Error en el código afectando la conexión: Se introducirá un fallo en la aplicación (por ejemplo, credenciales incorrectas o bucle infinito de conexiones) para simular un daño en la conectividad, requiriendo ajustes y restauración del acceso.
Pasos en cada Escenario
Preparación: Confirmar la existencia de snapshots recientes y la configuración de réplicas en las AZ
Simulación de fallos: Ejecutar cada escenario de forma secuencial y controlada
Verificación de la notificación: Esperar la notificación de caída del servicio vía slack
Restauración: Aplicar failover a la réplica (si aplica), restaurar desde snapshot o corregir configuraciones según el caso
Validación: Verificar la integridad de datos y la disponibilidad del servicio tras cada recuperación
Documentación: Registrar resultados y observaciones
Entregables
Riesgos Potenciales Esperados
Interrupción temporal del servicio, fallo en la promoción de réplicas, inconsistencias en datos restaurados.