Redis Sentinel vigila un grupo de servidores Redis (un primario y sus réplicas) y, si el primario deja de responder, promociona una réplica y avisa a los clientes de la nueva dirección. Es la forma más sencilla de dar alta disponibilidad a Redis cuando los datos caben en un solo nodo y no necesitas repartirlos entre varios, que es lo que hace Redis Cluster. En este tutorial montarás en Ubuntu 24.04 un primario, dos réplicas y tres procesos Sentinel, provocarás un failover real y conectarás una aplicación Python a través de Sentinel.

Requisitos previos

Para seguir esta guía necesitas:

  • Tres servidores con Ubuntu 24.04 LTS, por ejemplo tres VPS de CubePath, conectados por una red privada. En los ejemplos se usan estas direcciones:
ServidorIP privadaPapel inicial
redis110.0.0.11Primario + Sentinel
redis210.0.0.12Réplica + Sentinel
redis310.0.0.13Réplica + Sentinel
  • Un usuario no root con privilegios sudo en cada servidor.
  • Al menos 1 GB de RAM por servidor (más si tu conjunto de datos es grande: cada réplica guarda una copia completa).

Sustituye las IP por las tuyas. Usa tres servidores como mínimo: con solo dos Sentinel no se puede alcanzar mayoría si cae uno de los nodos, y el failover no ocurre.

Paso 1: Instalar Redis y Sentinel

Ubuntu 24.04 incluye Redis 7.0 en sus repositorios. El paquete redis-sentinel añade el servicio de Sentinel con su propio archivo de configuración. Ejecuta en los tres servidores:

sudo apt update
sudo apt install redis-server redis-sentinel

Comprueba la versión instalada y que ambos servicios están activos:

redis-server --version
systemctl is-active redis-server redis-sentinel

Redis server v=7.0.15 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=...
active
active

Por defecto los dos servicios escuchan solo en 127.0.0.1. En los siguientes pasos los abrirás a la red privada.

Paso 2: Configurar el primario

Genera una contraseña larga para Redis y guárdala en tu gestor de contraseñas. La usarás en los tres servidores:

openssl rand -base64 32

En redis1, abre la configuración de Redis:

sudo nano /etc/redis/redis.conf

Localiza y modifica estas directivas (usa Ctrl+W en nano para buscarlas). Sustituye your_strong_password por la contraseña que acabas de generar:

bind 127.0.0.1 -::1 10.0.0.11
requirepass your_strong_password
masterauth your_strong_password
  • bind añade la IP privada para que las réplicas y Sentinel puedan conectarse.
  • requirepass exige contraseña a los clientes.
  • masterauth es la contraseña que usará este nodo para autenticarse contra un primario. Aunque ahora es primario, la necesitará cuando Sentinel lo convierta en réplica tras un failover.

Reinicia Redis y comprueba que responde con contraseña:

sudo systemctl restart redis-server
redis-cli -h 10.0.0.11 -a 'your_strong_password' --no-auth-warning ping

PONG

Paso 3: Configurar las réplicas

En redis2 y redis3, edita el mismo archivo:

sudo nano /etc/redis/redis.conf

Aplica los mismos cambios, con la IP privada de cada servidor en bind, y añade la directiva replicaof apuntando al primario. Ejemplo para redis2:

bind 127.0.0.1 -::1 10.0.0.12
requirepass your_strong_password
masterauth your_strong_password
replicaof 10.0.0.11 6379

Todas las instancias deben compartir la misma contraseña: tras un failover cualquiera de ellas puede ser el primario.

Reinicia Redis en ambas réplicas:

sudo systemctl restart redis-server

Antes de comprobar la replicación, abre el cortafuegos en el paso siguiente; si UFW está activo, las réplicas todavía no pueden alcanzar al primario.

Paso 4: Abrir los puertos en la red privada

Redis usa el puerto 6379 y Sentinel el 26379. Permite ambos solo desde la red privada, nunca desde Internet. En los tres servidores:

sudo ufw allow from 10.0.0.0/24 to any port 6379 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 26379 proto tcp
sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
6379/tcp                   ALLOW       10.0.0.0/24
26379/tcp                  ALLOW       10.0.0.0/24

Si UFW no estaba activo, asegúrate de permitir SSH (sudo ufw allow OpenSSH) antes de activarlo con sudo ufw enable.

Ahora comprueba la replicación desde redis1:

redis-cli -a 'your_strong_password' --no-auth-warning info replication

# Replication
role:master
connected_slaves:2
slave0:ip=10.0.0.12,port=6379,state=online,offset=1204,lag=0
slave1:ip=10.0.0.13,port=6379,state=online,offset=1204,lag=0
...

Haz una prueba rápida: escribe una clave en el primario y léela en una réplica.

redis-cli -a 'your_strong_password' --no-auth-warning set prueba "hola"
redis-cli -h 10.0.0.12 -a 'your_strong_password' --no-auth-warning get prueba

OK
"hola"

Las réplicas son de solo lectura por defecto (replica-read-only yes), así que un SET contra ellas devolverá un error READONLY.

Paso 5: Configurar Sentinel

Sentinel se configura igual en los tres servidores, salvo la IP de bind. Abre su archivo:

sudo nano /etc/redis/sentinel.conf

El archivo del paquete ya trae una línea sentinel monitor mymaster 127.0.0.1 6379 2 y valores por defecto para los temporizadores. Modifica esas líneas (no las dupliques) para que queden así. Ejemplo para redis1:

bind 127.0.0.1 10.0.0.11
sentinel monitor mymaster 10.0.0.11 6379 2
sentinel auth-pass mymaster your_strong_password
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Qué hace cada directiva:

  • sentinel monitor mymaster 10.0.0.11 6379 2: vigila el primario con el nombre lógico mymaster. El 2 es el quórum, el número de Sentinel que deben coincidir en que el primario ha caído. Con tres Sentinel, 2 es el valor correcto.
  • sentinel auth-pass: contraseña para conectarse a las instancias Redis.
  • down-after-milliseconds: tiempo sin respuesta antes de considerar caído el primario (5 segundos aquí; el valor por defecto es 30).
  • failover-timeout: tiempo máximo para completar un failover antes de reintentarlo.
  • parallel-syncs: cuántas réplicas se resincronizan a la vez con el nuevo primario. Con 1 siempre queda alguna réplica sirviendo lecturas.

Solo configuras el primario: Sentinel descubre las réplicas y los otros Sentinel automáticamente a través de Redis.

Reinicia Sentinel en los tres servidores:

sudo systemctl restart redis-sentinel

Paso 6: Verificar el estado de Sentinel

Consulta a cualquier Sentinel qué primario conoce:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

1) "10.0.0.11"
2) "6379"

Comprueba que cada Sentinel ve a los otros dos y a las dos réplicas:

redis-cli -p 26379 sentinel master mymaster | grep -A1 -E 'num-slaves|num-other-sentinels|quorum'

num-slaves
2
num-other-sentinels
2
quorum
2

Por último, confirma que hay suficientes Sentinel para autorizar un failover:

redis-cli -p 26379 sentinel ckquorum mymaster

OK 3 usable Sentinels. Quorum and failover authorization can be reached

Si num-other-sentinels es 0, los Sentinel no se ven entre sí. Revisa el cortafuegos y la sección de solución de problemas.

Paso 7: Probar un failover automático

La única forma de confiar en la alta disponibilidad es probarla. En redis2, sigue el log de Sentinel:

sudo tail -f /var/log/redis/redis-sentinel.log

En redis1, detén Redis para simular una caída del primario:

sudo systemctl stop redis-server

Tras unos 5 segundos verás en el log de redis2 cómo los Sentinel marcan el primario como caído (+sdown, luego +odown al alcanzar el quórum), eligen un líder y promocionan una réplica:

+sdown master mymaster 10.0.0.11 6379
+odown master mymaster 10.0.0.11 6379 #quorum 3/2
+try-failover master mymaster 10.0.0.11 6379
+selected-slave slave 10.0.0.12:6379 10.0.0.12 6379 @ mymaster 10.0.0.11 6379
+promoted-slave slave 10.0.0.12:6379 10.0.0.12 6379 @ mymaster 10.0.0.11 6379
+switch-master mymaster 10.0.0.11 6379 10.0.0.12 6379

Pulsa Ctrl+C y confirma el nuevo primario:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

1) "10.0.0.12"
2) "6379"

Vuelve a arrancar Redis en redis1:

sudo systemctl start redis-server

Sentinel detecta que el antiguo primario ha vuelto y lo reconfigura como réplica del nuevo (evento +convert-to-slave en el log). Compruébalo:

redis-cli -a 'your_strong_password' --no-auth-warning info replication | head -3

# Replication
role:slave
master_host:10.0.0.12

El primario no vuelve a redis1 por sí solo. Si quieres devolverlo, lanza un failover manual desde cualquier Sentinel con redis-cli -p 26379 sentinel failover mymaster; sin quórum ni caída, promociona una réplica de forma ordenada.

Paso 8: Conectar una aplicación a través de Sentinel

Las aplicaciones no deben conectarse a una IP fija de Redis, porque el primario cambia. Deben preguntar a Sentinel dónde está el primario y reconectar cuando cambie. La mayoría de clientes (redis-py, Jedis, Lettuce, ioredis, go-redis) lo soportan. Como ejemplo, instala redis-py en el servidor de tu aplicación:

sudo apt install python3-redis

Crea un script de prueba:

nano sentinel_test.py

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [("10.0.0.11", 26379), ("10.0.0.12", 26379), ("10.0.0.13", 26379)],
    socket_timeout=0.5,
)

# Conexión de escritura: siempre apunta al primario actual
master = sentinel.master_for("mymaster", password="your_strong_password", socket_timeout=0.5)
# Conexión de lectura: reparte entre réplicas
replica = sentinel.slave_for("mymaster", password="your_strong_password", socket_timeout=0.5)

print("Primario actual:", sentinel.discover_master("mymaster"))
master.set("app:estado", "ok")
print("Leído desde réplica:", replica.get("app:estado"))

Ejecútalo:

python3 sentinel_test.py

Primario actual: ('10.0.0.12', 6379)
Leído desde réplica: b'ok'

Ten en cuenta que la replicación de Redis es asíncrona: justo después de escribir, una réplica puede no tener todavía el dato. Lee del primario lo que necesites leer inmediatamente después de escribirlo. El servidor de la aplicación también necesita acceso a los puertos 6379 y 26379 por la red privada.

Solución de problemas

num-other-sentinels es 0 o ckquorum falla. Los Sentinel se descubren publicando mensajes en el primario. Comprueba que el puerto 26379 está abierto entre los tres servidores (nc -zv 10.0.0.12 26379) y que cada sentinel.conf usa la IP privada en bind y apunta al mismo primario con el mismo nombre mymaster.

El log muestra -failover-abort-no-good-slave. Ninguna réplica es válida para la promoción, normalmente porque están desconectadas del primario o no se pueden autenticar. Revisa info replication en cada réplica y que masterauth coincida con requirepass en todas.

Errores NOAUTH o WRONGPASS en el log de Sentinel. Falta sentinel auth-pass mymaster o la contraseña no coincide con la de Redis.

El antiguo primario vuelve como primario y hay dos primarios. Ocurre si Sentinel no puede reconfigurarlo al volver, por ejemplo porque el cortafuegos del nodo bloquea a Sentinel. Revisa sudo journalctl -u redis-server en ese nodo y la conectividad desde los Sentinel.

Conclusión

Tienes un grupo Redis con un primario, dos réplicas y tres Sentinel que detectan caídas y promocionan una réplica en segundos, y has comprobado el failover de punta a punta. Como siguientes pasos, activa la persistencia AOF (appendonly yes) si no puedes perder escrituras recientes, añade alertas sobre los eventos +switch-master del log de Sentinel y, si tus datos dejan de caber en un solo nodo, valora pasar a Redis Cluster para repartirlos entre varios primarios.