El failover de Redis Sentinel tarda lo que marca down-after más unos dos segundos

Matar el primario de Redis a propósito quince veces y cronometrar cuánto tiempo fallan las escrituras hasta que una réplica toma el relevo. Ese es el experimento: tres valores de down-after-milliseconds, tres motores (Redis 8, Valkey 8 y Dragonfly) y una conclusión que cabe en una línea. La ventana de indisponibilidad equivale a down-after más unos dos segundos de votación de quórum, elección de líder y promoción de la réplica.

Los números, medidos como el hueco entre el kill del primario y la primera escritura que funciona en la réplica promocionada, con media de tres ejecuciones:

• down-after 1.000 ms → 2,5 s de corte
• down-after 5.000 ms, el valor por defecto habitual → 7,3 s
• down-after 10.000 ms → 12,1 s

La relación es casi lineal: outage ≈ down-after + ~2 s. Ese sobrecoste es fijo y corresponde al mecanismo de Sentinel; down-after es la única palanca que se controla, y es justo la que casi nadie toca. Quien deja el valor por defecto está regalando siete segundos de escrituras perdidas sin haberlo decidido nunca.

El motor no cambia nada

Con down-after en 5 s, Redis 8, Valkey 8 y Dragonfly volvieron en 7,3–7,4 s bajo los mismos centinelas. La interrupción pertenece a Sentinel, no al motor que se muere. Cambiar de implementación no compra milisegundos en el failover.

El montaje es un primario, dos réplicas y tres centinelas en Docker, sin puertos expuestos al host y con limpieza completa al terminar. El kill, el script y el barrido que produce la tabla están en el repositorio del laboratorio: un docker compose up y se puede reproducir.

Por qué importa

El escenario típico es una aplicación escalada en varias instancias detrás de un balanceador, todas hablando a un único Redis donde viven caché, sesiones y colas de trabajo. Cuando ese nodo cae, no se cae una instancia: se cae el estado compartido de todas a la vez. La caché se enfría y las peticiones van a la base de datos en tromba, las sesiones desaparecen y el procesamiento en segundo plano se para. Añadir servidores de aplicación no arregla nada de eso; lo que lo arregla es que Redis sobreviva a la pérdida de un nodo, que es para lo que está Sentinel.

Hay una condición que se olvida con frecuencia: el cliente tiene que ser consciente de Sentinel y preguntar quién es el maestro en cada momento. Si apunta a una IP fija, el failover no sirve de nada. En el caso de Laravel, eso pasa por un cliente preparado, como laravel-redis-sentinel para las conexiones de la aplicación.

Queda por ver cómo se ajusta down-after en producción. Bajarlo recorta el corte pero multiplica los falsos positivos ante un hipo de red; subirlo da margen a la detección a cambio de segundos de escrituras rechazadas. Los dos segundos de promoción no se negocian; el dial sí, y ahora hay medidas para elegir con criterio en lugar de heredar el valor por defecto.