¿En cuántos segundos se completa el failover de RDS? - El mecanismo de conmutación Multi-AZ y lo que hay detrás de la propagación DNS
Desglosa los 60 a 120 segundos que tarda el failover de RDS Multi-AZ en las fases de detección del fallo, actualización del registro DNS y restablecimiento de las conexiones, y explica técnicas prácticas para acortar el tiempo de failover.
Estructura básica de Multi-AZ - Primaria y standby
En una implementación RDS Multi-AZ, la instancia primaria y la instancia standby se ubican en AZ distintas. Las escrituras en la primaria se copian a la standby mediante replicación síncrona. La replicación síncrona es un método en el que se confirma que la transferencia de datos a la standby se ha completado antes de que la primaria confirme (commit) la transacción. Gracias a ello, no se produce pérdida de datos durante el failover. En condiciones normales, la instancia standby no acepta solicitudes de la aplicación. Para distribuir el tráfico de lectura se utilizan réplicas de lectura. La función de la standby es mantenerse en un estado en el que pueda promoverse de inmediato cuando falle la primaria. La aplicación se conecta a la base de datos mediante el endpoint (CNAME) que proporciona RDS. Este endpoint es un registro DNS y, en condiciones normales, se resuelve a la dirección IP de la instancia primaria. Durante el failover, este registro DNS se actualiza a la dirección IP de la instancia standby.
Las 3 fases del failover
El failover de RDS consta de 3 fases. La primera fase es la detección del fallo. El sistema de monitorización de RDS tarda entre unos segundos y varias decenas de segundos en detectar el fallo de la instancia primaria. El tiempo de detección varía según el tipo de fallo. La caída de una instancia se detecta en pocos segundos, pero un fallo parcial de la red (aumento de la pérdida de paquetes) tarda más en detectarse. La segunda fase es la actualización del registro DNS. La instancia standby se promueve a primaria y el registro DNS del endpoint de RDS se actualiza a la dirección IP de la standby. El TTL (Time To Live) del registro DNS suele estar configurado en 5 segundos, pero si la aplicación o el sistema operativo almacenan en caché el DNS, es posible que sigan conectándose a la dirección IP antigua. La tercera fase es el restablecimiento de las conexiones. Es el tiempo que tarda la aplicación en establecer una conexión con la nueva primaria. Si se utiliza un pool de conexiones, las conexiones antiguas del pool han quedado invalidadas, por lo que es necesario crear conexiones nuevas.
El desglose de los 60 a 120 segundos
La documentación oficial de AWS indica que el tiempo de failover de RDS Multi-AZ es «normalmente de 60 a 120 segundos». Si se desglosa este tiempo, la detección del fallo ocupa de 5 a 30 segundos y el proceso de promoción de la standby, de 10 a 30 segundos. La actualización y propagación del registro DNS ocupa de 5 a 30 segundos, y el restablecimiento de las conexiones de la aplicación, de 5 a 30 segundos. El tiempo de failover varía porque depende del tipo de fallo y del estado de la base de datos. Si hay muchas transacciones sin confirmar, la promoción de la standby requiere un proceso de recuperación (rollback) y el tiempo se alarga. Si el failover se produce durante la ejecución de una operación DDL (ALTER TABLE) sobre una tabla grande, la recuperación puede tardar varios minutos. El failover de Aurora es más rápido que el de RDS. Como Aurora comparte la capa de almacenamiento, no necesita recuperar datos al promover la standby. El failover de Aurora suele completarse dentro de 30 segundos, y en Aurora Serverless v2 el tiempo se acorta aún más.
Técnicas para acortar el tiempo de failover
Existen técnicas prácticas para minimizar el impacto del failover. La primera es respetar el TTL de la caché DNS. La JVM de Java almacena en caché el DNS de forma indefinida por defecto (networkaddress.cache.ttl=-1). Con esta configuración, la aplicación sigue conectándose a la dirección IP antigua incluso después del failover. Configure un TTL corto para la caché DNS de la JVM (por ejemplo, de 5 a 30 segundos). La segunda es utilizar RDS Proxy. RDS Proxy es un proxy que se sitúa entre la aplicación y la base de datos, y durante el failover redirige automáticamente las conexiones a la nueva primaria. Como la aplicación se conecta al endpoint de RDS Proxy, no necesita esperar a la propagación DNS. AWS informa de que el uso de RDS Proxy puede reducir el tiempo de inactividad durante el failover hasta en un 66%. La tercera es la lógica de reintento en la aplicación. Implemente reintentos con backoff exponencial para los errores de conexión durante el failover. El intervalo se amplía de forma que el primer reintento se hace al cabo de 1 segundo, el siguiente al cabo de 2 segundos y el siguiente al cabo de 4 segundos.
Pruebas de failover - Para no entrar en pánico en producción
El failover no debe ser algo que se experimente por primera vez en el entorno de producción. RDS ofrece una función para activar el failover manualmente. Para ello, se marca «Reiniciar con failover» en la opción «Reiniciar» de la consola o se ejecuta reboot-db-instance --force-failover en la CLI. Hay 4 aspectos que se deben comprobar en una prueba de failover. Primero, si la aplicación puede volver a conectarse automáticamente a la nueva primaria. Segundo, si la lógica de reintento funciona correctamente cuando las solicitudes durante el failover dan error. Tercero, el tiempo real que se tardó en completar el failover. Cuarto, si se mantiene la integridad de los datos después del failover. Si se configura RDSEventNotification de CloudWatch, se puede notificar por SNS el inicio y la finalización del failover. Los eventos de failover también se registran en CloudTrail, por lo que pueden utilizarse para el análisis posterior.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.