Guía de Redis Sentinel: Alta Disponibilidad y Failover Automático

23 de marzo de 2026

12 min de lectura

Reciente

TL;DR — Resumen Rápido

Despliega Redis Sentinel para failover automático y alta disponibilidad. Configura quórum, topología master-réplica, clientes y seguridad en producción.

Redis Sentinel es la solución de alta disponibilidad integrada en Redis, que proporciona failover automático, monitoreo de topología y descubrimiento de servicios sin la complejidad de Redis Cluster. Esta guía cubre la arquitectura completa, un despliegue de tres nodos listo para producción, la configuración de clientes compatibles con Sentinel, los conceptos de quórum y los controles de seguridad necesarios antes de pasar a producción.

Requisitos Previos

Tres servidores Linux (físicos o virtuales) con conectividad entre sí en los puertos 6379 (Redis) y 26379 (Sentinel).
Redis 7.0 o superior instalado en todos los nodos.
Acceso root o sudo en cada servidor.
Familiaridad básica con archivos de configuración de Redis y redis-cli.

Arquitectura de Sentinel

Redis Sentinel se ejecuta como un proceso separado junto a las instancias de Redis. Cada Sentinel cumple cuatro funciones:

Monitoreo: Comprueba la salud del master y las réplicas cada segundo mediante PING/INFO.
Notificación: Publica alertas en canales como +switch-master y +slave mediante pub/sub.
Failover automático: Al alcanzar el quórum, Sentinel elige un líder, promueve la mejor réplica y reconfigura las demás.
Proveedor de configuración: Los clientes consultan Sentinel con SENTINEL get-master-addr-by-name para descubrir la dirección del master actual.

¿Por Qué Tres Sentinels?

Un único Sentinel es un punto único de fallo. Con dos Sentinels puede producirse un empate en la votación. Tres Sentinels con quórum 2 garantizan:

Un Sentinel puede fallar y el failover sigue funcionando.
Dos Sentinels cualesquiera pueden acordar promover un nuevo master.
La minoría no puede desencadenar una promoción que provoque split-brain.

Siempre despliegue un número impar de Sentinels (3, 5 o 7).

Paso 1 — Configurar el Master de Redis

En el Servidor 1 (192.168.1.101), edite /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no

requirepass "ContraseñaFuerteRedis123"
masterauth "ContraseñaFuerteRedis123"

# Persistencia (AOF recomendado para despliegues con Sentinel)
appendonly yes
appendfsync everysec

# Protección split-brain: rechaza escrituras si ninguna réplica ha sincronizado en 10s
min-replicas-to-write 1
min-replicas-max-lag 10

Inicie y habilite Redis:

sudo systemctl start redis-server
sudo systemctl enable redis-server

Paso 2 — Configurar las Réplicas de Redis

En el Servidor 2 (192.168.1.102) y el Servidor 3 (192.168.1.103), edite /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no

requirepass "ContraseñaFuerteRedis123"
masterauth "ContraseñaFuerteRedis123"

# Apuntar al master inicial
replicaof 192.168.1.101 6379

# Las réplicas rechazan comandos de escritura de clientes (predeterminado seguro)
replica-read-only yes

# Persistencia
appendonly yes
appendfsync everysec

# Prioridad de promoción de réplica (menor = preferida; 0 = nunca promover)
replica-priority 100

Verifique la replicación desde el master:

redis-cli -a "ContraseñaFuerteRedis123" INFO replication

Debería ver role:master y dos entradas slave con state:online.

Paso 3 — Configurar Redis Sentinel

Cree /etc/redis/sentinel.conf en los tres servidores:

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
dir /var/lib/redis

# Monitorear el master llamado "mymaster" con quórum 2
sentinel monitor mymaster 192.168.1.101 6379 2

# Contraseña para autenticarse con el master (y réplicas tras el failover)
sentinel auth-pass mymaster ContraseñaFuerteRedis123

# Marcar el master como SDOWN tras 5 segundos sin respuesta
sentinel down-after-milliseconds mymaster 5000

# Tiempo máximo para el proceso completo de failover (ms)
sentinel failover-timeout mymaster 60000

# Solo una réplica sincroniza del nuevo master a la vez
sentinel parallel-syncs mymaster 1

Inicie Sentinel en los tres servidores:

sudo redis-sentinel /etc/redis/sentinel.conf

Verifique el descubrimiento de topología:

redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster
redis-cli -p 26379 SENTINEL ckquorum mymaster

El Proceso de Failover Paso a Paso

SDOWN (Subjetivamente Caído): Un Sentinel deja de recibir PONG del master dentro del tiempo down-after-milliseconds y lo marca como SDOWN.
ODOWN (Objetivamente Caído): El Sentinel difunde SENTINEL is-master-down-by-addr a sus pares. Cuando el número de quórum responde afirmativamente, el estado pasa a ODOWN.
Elección de líder: Los Sentinels que están de acuerdo sobre ODOWN votan por un líder usando el algoritmo similar a Raft integrado en Sentinel.
Selección de réplica: El líder clasifica las réplicas por: tiempo de desconexión del master → replica-priority (menor gana) → offset de replicación (más datos gana) → run ID léxico.
Promoción: El líder envía REPLICAOF NO ONE a la réplica elegida, convirtiéndola en el nuevo master.
Reconfiguración: Las demás réplicas reciben REPLICAOF <nueva-ip-master> 6379. Los Sentinels actualizan sus archivos sentinel.conf. Los clientes que consulten Sentinel recibirán la nueva dirección del master.

El proceso completo suele terminar en 10–30 segundos con la configuración predeterminada.

Conexión de Clientes a Través de Sentinel

Nunca codifique en duro la IP del master de Redis en su aplicación. Use un cliente compatible con Sentinel que consulte Sentinel para obtener el master actual.

Python (redis-py)

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [
        ("192.168.1.101", 26379),
        ("192.168.1.102", 26379),
        ("192.168.1.103", 26379),
    ],
    socket_timeout=0.5,
    password="ContraseñaFuerteRedis123",
)

master = sentinel.master_for("mymaster", socket_timeout=0.5)
replica = sentinel.slave_for("mymaster", socket_timeout=0.5)

master.set("sesion:abc", "datos-usuario")
valor = replica.get("sesion:abc")

Node.js (ioredis)

const Redis = require("ioredis");

const redis = new Redis({
  sentinels: [
    { host: "192.168.1.101", port: 26379 },
    { host: "192.168.1.102", port: 26379 },
    { host: "192.168.1.103", port: 26379 },
  ],
  name: "mymaster",
  password: "ContraseñaFuerteRedis123",
  sentinelPassword: "ContraseñaFuerteRedis123",
});

await redis.set("clave", "valor");

Seguridad en Producción

Proteger Sentinel

Añada requirepass a Sentinel para que solo los clientes autorizados puedan emitir comandos de Sentinel:

requirepass "ContraseñaAdminSentinel"
sentinel sentinel-pass ContraseñaAdminSentinel

Habilitar TLS

Redis 6.0+ admite TLS para conexiones de Redis y Sentinel:

tls-port 26380
port 0
tls-cert-file /etc/redis/tls/sentinel.crt
tls-key-file /etc/redis/tls/sentinel.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-replication yes

Usar ACLs (Redis 6.0+)

# En redis.conf
aclfile /etc/redis/users.acl

# users.acl
user default off
user sentinel on >SentinelPass ~* &* +@all
user app on >AppPass ~sesion:* ~cache:* +GET +SET +DEL +EXPIRE

Comparativa: Sentinel vs Alternativas

Característica	Sentinel	Redis Cluster	KeyDB	Dragonfly	Redis Gestionado
Failover automático	Sí	Sí	Sí	Sí	Sí
Particionamiento	No	Sí	Sí	No	Varía
Complejidad de configuración	Media	Alta	Baja	Baja	Ninguna
Requisito de cliente	Compatible Sentinel	Compatible Cluster	Estándar	Estándar	Estándar
Tamaño máximo del dataset	RAM de un nodo	RAM × shards	RAM de un nodo	RAM de un nodo	Limitado por plan
Coste	Gratis	Gratis	Gratis	Gratis	$$/mes
Ideal para	HA sin fragmentación	Datasets grandes	HA drop-in de Redis	Alto rendimiento	Sin gestión de infra

Problemas Comunes y Advertencias

Sentinel reescribe su archivo de configuración. Nunca edite sentinel.conf manualmente mientras Sentinel está en ejecución — Sentinel actualiza continuamente el archivo con la topología descubierta.

DNS vs direcciones IP. Sentinel almacena las direcciones de master y réplica por IP en el momento del descubrimiento. Si cambia la IP de un servidor, Sentinel no seguirá los cambios de DNS — debe actualizar sentinel.conf manualmente y reiniciar Sentinel.

Lecturas obsoletas durante el failover. En los 10–30 segundos entre el fallo del master y la promoción de la réplica, las lecturas pueden devolver datos obsoletos. Diseñe la aplicación para tolerar lecturas brevemente obsoletas o para reintentar con un tiempo de espera.

requirepass sin masterauth. Si establece requirepass en el master pero olvida masterauth en las réplicas, la autenticación de replicación falla y las réplicas se desconectan silenciosamente.

Resumen

Redis Sentinel proporciona monitoreo, failover automático y descubrimiento de servicios para Redis sin requerir Cluster.
Despliegue al menos 3 instancias de Sentinel en hosts separados; configure quórum en 2 para un setup de 3 nodos.
La secuencia de failover avanza de SDOWN → ODOWN → elección de líder → promoción de réplica → reconfiguración.
Use min-replicas-to-write y min-replicas-max-lag en el master para prevenir la pérdida de datos por split-brain.
Siempre use un cliente compatible con Sentinel — nunca codifique en duro la IP del master.
Proteja Sentinel con requirepass, ACLs y TLS en entornos de producción.

Guide & Instructions

Estimated Time: 30m

Tools Needed:

Redis
Redis Sentinel
systemctl

Instalar Redis en los tres nodos

Instale Redis 7.0 o superior en el servidor master y en los dos servidores réplica. Asegúrese de que los puertos 6379 y 26379 estén abiertos entre todos los nodos en las reglas del firewall.

Configurar el master de Redis

Edite /etc/redis/redis.conf en el nodo master. Configure bind en 0.0.0.0, requirepass, masterauth y opciones de persistencia. Añada min-replicas-to-write 1 y min-replicas-max-lag 10 para proteger contra el split-brain.

Configurar las réplicas de Redis

En cada nodo réplica, edite redis.conf para añadir la directiva replicaof apuntando a la IP y puerto del master. Configure replica-read-only yes y use los mismos valores de requirepass y masterauth que el master.

Crear y desplegar sentinel.conf en cada nodo

Cree /etc/redis/sentinel.conf en cada uno de los tres servidores con sentinel monitor mymaster apuntando al master, quórum 2, down-after-milliseconds 5000, failover-timeout 60000 y sentinel auth-pass con la contraseña del master.

Iniciar Sentinel y verificar el descubrimiento de topología

Inicie Redis Sentinel con 'sudo redis-sentinel /etc/redis/sentinel.conf' en todos los nodos. Ejecute 'redis-cli -p 26379 SENTINEL masters' para confirmar que los tres Sentinels ven el mismo master y se han descubierto entre sí.

Probar el failover automático y actualizar los clientes

Detenga el proceso master de Redis y observe los logs de Sentinel. Confirme que una réplica se promueve en segundos. Actualice la aplicación para usar un cliente compatible con Sentinel apuntando a las tres direcciones Sentinel.

Frequently Asked Questions

¿Cómo detecta Redis Sentinel un fallo del master?

Cada Sentinel hace ping al master cada segundo. Si no recibe respuesta en down-after-milliseconds, marca el master como SDOWN. Cuando el quórum de Sentinels coincide, el estado pasa a ODOWN y comienza el failover.

¿Cuántas instancias de Sentinel se necesitan como mínimo?

Se necesitan al menos 3 instancias con quórum de 2. Un número impar evita empates en la elección de líder, y perder un Sentinel aún deja suficientes instancias para alcanzar el quórum y ejecutar el failover.

¿Redis Sentinel actúa como proxy para las conexiones de clientes?

No. Sentinel solo es una capa de descubrimiento de servicios. Los clientes consultan Sentinel para obtener la dirección del master actual y luego se conectan directamente a Redis. Es obligatorio usar una librería cliente compatible con Sentinel.

¿Cómo evito la pérdida de datos por split-brain en Redis Sentinel?

Configure min-replicas-to-write y min-replicas-max-lag en el master. El master rechazará escrituras si menos réplicas de las requeridas han confirmado datos recientemente, evitando que un master aislado acepte escrituras que se perderán tras el failover.