--- title: "Redis Sentinel en Ubuntu 24.04: alta disponibilidad" description: "Monta un primario Redis con dos réplicas y tres Sentinel en Ubuntu 24.04, prueba un failover automático real y conecta tu aplicación a través de Sentinel." category: "Base de Datos Avanzada" language: es source: https://cubepath.com/es/docs/base-de-datos-avanzada/redis-sentinel-alta-disponibilidad updated: 2026-09-25 --- # Redis Sentinel en Ubuntu 24.04: alta disponibilidad 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: | Servidor | IP privada | Papel inicial | |----------|------------|---------------| | redis1 | `10.0.0.11` | Primario + Sentinel | | redis2 | `10.0.0.12` | Réplica + Sentinel | | redis3 | `10.0.0.13` | Ré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: ```bash sudo apt update sudo apt install redis-server redis-sentinel ``` Comprueba la versión instalada y que ambos servicios están activos: ```bash redis-server --version systemctl is-active redis-server redis-sentinel ``` ```output 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: ```bash openssl rand -base64 32 ``` En **redis1**, abre la configuración de Redis: ```bash 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: ```ini 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: ```bash sudo systemctl restart redis-server redis-cli -h 10.0.0.11 -a 'your_strong_password' --no-auth-warning ping ``` ```output PONG ``` ## Paso 3: Configurar las réplicas En **redis2** y **redis3**, edita el mismo archivo: ```bash 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: ```ini 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: ```bash 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: ```bash 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 ``` ```output 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**: ```bash redis-cli -a 'your_strong_password' --no-auth-warning info replication ``` ```output # 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. ```bash 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 ``` ```output 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: ```bash 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: ```ini 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. > Importante: Sentinel reescribe `sentinel.conf` mientras funciona (añade su `sentinel myid` y el estado descubierto). Si clonas un servidor ya configurado para crear otro, borra las líneas `sentinel myid` y `sentinel known-*` del clon antes de arrancarlo, o los dos Sentinel tendrán el mismo identificador. Reinicia Sentinel en los tres servidores: ```bash sudo systemctl restart redis-sentinel ``` ## Paso 6: Verificar el estado de Sentinel Consulta a cualquier Sentinel qué primario conoce: ```bash redis-cli -p 26379 sentinel get-master-addr-by-name mymaster ``` ```output 1) "10.0.0.11" 2) "6379" ``` Comprueba que cada Sentinel ve a los otros dos y a las dos réplicas: ```bash redis-cli -p 26379 sentinel master mymaster | grep -A1 -E 'num-slaves|num-other-sentinels|quorum' ``` ```output num-slaves 2 num-other-sentinels 2 quorum 2 ``` Por último, confirma que hay suficientes Sentinel para autorizar un failover: ```bash redis-cli -p 26379 sentinel ckquorum mymaster ``` ```output 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: ```bash sudo tail -f /var/log/redis/redis-sentinel.log ``` En **redis1**, detén Redis para simular una caída del primario: ```bash 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: ```output +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: ```bash redis-cli -p 26379 sentinel get-master-addr-by-name mymaster ``` ```output 1) "10.0.0.12" 2) "6379" ``` Vuelve a arrancar Redis en **redis1**: ```bash 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: ```bash redis-cli -a 'your_strong_password' --no-auth-warning info replication | head -3 ``` ```output # 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: ```bash sudo apt install python3-redis ``` Crea un script de prueba: ```bash nano sentinel_test.py ``` ```python 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: ```bash python3 sentinel_test.py ``` ```output 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.