Cuántos segundos tarda el failover de RDS - Mecanismo de conmutación Multi-AZ y propagación DNS
Analizamos en detalle el mecanismo de failover de RDS Multi-AZ: el tiempo de conmutación, la propagación DNS, el impacto en las conexiones de aplicación y las mejores prácticas para minimizar la interrupción.
Mecanismo de failover Multi-AZ
Cuando RDS detecta un fallo en la instancia primaria (fallo de hardware, pérdida de conectividad de red, fallo del sistema operativo o mantenimiento planificado), inicia automáticamente el proceso de failover. La instancia standby, que mantiene una réplica síncrona de los datos, se promueve a primaria. El registro DNS del endpoint se actualiza para apuntar a la nueva primaria. El tiempo total de failover varía según el motor y la carga de trabajo, pero típicamente se completa en 60-120 segundos para instancias Single-AZ a Multi-AZ, y en menos de 35 segundos para Multi-AZ Cluster.
Propagación DNS y reconexión de aplicaciones
El endpoint de RDS es un registro CNAME con TTL de 5 segundos. Tras el failover, el CNAME se actualiza para apuntar a la IP de la nueva instancia primaria. Las aplicaciones que respetan el TTL DNS resolverán la nueva IP en 5 segundos. Sin embargo, muchos drivers de base de datos y connection pools cachean conexiones TCP, por lo que las conexiones existentes fallarán y necesitarán reconectarse. La mejor práctica es configurar el connection pool con validación de conexión (testOnBorrow), timeouts agresivos y lógica de reintento. Los SDK de AWS y drivers modernos incluyen lógica de failover-aware que detecta el failover y reconecta automáticamente.
Factores que afectan el tiempo de failover
Varios factores influyen en el tiempo total de interrupción percibido por la aplicación. El tamaño de la base de datos y las transacciones en vuelo afectan el tiempo de recuperación del crash recovery. Las transacciones no confirmadas deben deshacerse (rollback) en la nueva primaria. Bases de datos con muchas transacciones largas en vuelo experimentarán tiempos de recuperación más largos. El tipo de almacenamiento también influye: io1/io2 con IOPS provisionados proporcionan recuperación más rápida que gp2/gp3. La configuración de DNS del cliente (TTL cacheado, resolvers intermedios) puede añadir latencia adicional a la resolución del nuevo endpoint. Para profundizar en alta disponibilidad de bases de datos, consulte libros relacionados en Amazon.
Mejores prácticas para minimizar la interrupción
Para minimizar el impacto del failover: configurar connection pools con validación de conexión y timeouts cortos (connectTimeout 5s, socketTimeout 30s), implementar lógica de reintento con backoff exponencial, usar el endpoint de lectura para Read Replicas y distribuir lecturas, monitorizar el evento RDS-EVENT-0049 (failover completado) con EventBridge, y realizar failovers planificados durante ventanas de mantenimiento para validar el comportamiento de la aplicación. Para Multi-AZ Cluster, el failover es significativamente más rápido (menos de 35 segundos) gracias al uso de réplicas de lectura como candidatas a failover.
Resumen
El failover de RDS Multi-AZ se completa típicamente en 60-120 segundos (35 segundos para Multi-AZ Cluster). El mecanismo involucra la promoción de la instancia standby, actualización del CNAME DNS con TTL de 5 segundos y crash recovery de transacciones en vuelo. Las aplicaciones deben implementar validación de conexión, timeouts agresivos y lógica de reintento para minimizar el impacto percibido por los usuarios.