Redis Sentinel Mode

Redis master-replica replication alone cannot automatically perform a master/replica switch. Sentinel mode exists to solve exactly this problem. Sentinel continuously monitors the health of the Redis master and replicas; when the master fails, it automatically picks the best replica and promotes it to master. When a client connects to the cluster, it first connects to Sentinel to look up the master address, then connects to the master for data access. When the master fails, the client queries Sentinel again for the master address, and Sentinel returns the latest master address.

Sentinel mode cannot guarantee no data loss, because Redis master-replica uses asynchronous replication; when the master goes down, there is no guarantee the replicas have received all synced messages.

Sentinel provides the following features:

Monitoring: continuously checks whether master and replica nodes work as expected.
Notification: can notify the system administrator or other programs via an API that a monitored Redis instance has a problem.
Automatic failover: if the master is not working as expected, Sentinel can start the failover process, promoting a replica to master; the other replicas are reconfigured to use the new master, and applications using the Redis server are told the new address to connect to.
Configuration provider: acts as the authoritative source for client service discovery.

Configuring sentinel.conf

bind 127.0.0.1 192.168.1.1 specifies the network interfaces the redis sentinel listens on; by default it only listens on localhost.

protected-mode no is the safe protection mode; no allows connections from any host, yes enables protected mode and only allows designated connections.

port 26379 is the sentinel listening port.

daemonize no controls whether sentinel runs as a background daemon. no runs it in the foreground, yes runs it as a background daemon. In containerized environments no is recommended — running in the foreground lets docker manage the process lifecycle correctly.

pidfile /var/run/redis-sentinel.pid specifies the PID file path for the daemon.

logfile "" specifies the log file path. If empty, logs go to stdout.

sentinel announce-ip <ip> configures the IP that sentinel advertises externally. When set, sentinel declares this IP in its HELLO messages instead of auto-detecting the local address. sentinel announce-port <port> configures the port that sentinel advertises externally.

dir /tmp is the working directory. Every long-running process should have a clear working directory; for sentinel the simplest approach is to switch the working directory to /tmp at startup, avoiding interference with management tasks such as unmounting filesystems.

sentinel monitor <master-name> <ip> <redis-port> <quorum> tells sentinel to monitor this master, and only considers it O_DOWN (objectively down) when at least <quorum> sentinels agree. Regardless of the objective-down quorum, a Sentinel must be elected by a majority of the known sentinels to start a failover, so a failover cannot be triggered from a minority partition. Sentinel auto-discovers the master’s replicas — they are discovered automatically, so replicas need not be specified in any way. Sentinel itself rewrites this config file using other options to add replicas. Also, when a replica is promoted to master, the config file is rewritten.

sentinel auth-pass <master-name> <password> sets the password sentinels use to authenticate to the master and replicas.

sentinel auth-user <master-name> <username> configures the username the sentinel uses when connecting to monitored redis masters and replicas, usually used together with the ACL access-control system.

The sentinel auth-pass and sentinel auth-user options are the username and password the sentinel uses as a client when connecting to masters and replicas.

sentinel down-after-milliseconds mymaster 30000 is the number of milliseconds a master (or any connected replica or sentinel) must be continuously unreachable (i.e. no valid reply to PING) before it is considered in S_DOWN (subjectively down) state. Default is 30 seconds.

Subjective down (S_DOWN): a single sentinel instance considers a node unavailable Objective down (O_DOWN): multiple sentinel instances reach consensus that a node is unavailable

user <username> ... acl rules ... configures ACL, defining a user’s state, permissions, password, etc.

acllog-max-len 128 configures the maximum length of the ACL log; when the log reaches the limit, new records overwrite the oldest. The ACL log records ACL-related failed commands and authentication events; it is stored in memory and lost on restart, and can be reclaimed with the ACL LOG RESET command.

aclfile /etc/redis/sentinel-users.acl enables an external ACL file, allowing user ACL configuration to be separated into an independent file.

requirepass <password> sets the authentication password for the Sentinel instance, used for mutual authentication between Sentinel instances; all Sentinel instances must set the same password. ACL is now the recommended mechanism; requirepass uses the default user by default.

sentinel sentinel-user <username> configures the username used for mutual authentication between sentinel instances. sentinel sentinel-pass <password> configures the password used for mutual authentication between sentinel instances.

sentinel parallel-syncs <master-name> <numreplicas> controls how many replicas can be reconfigured to point to the new master simultaneously during a failover. If replicas also serve read requests, a lower value is recommended to avoid all replicas being unavailable at once and preserve read capacity. If replicas do not serve reads and you want all replicas synced as quickly as possible, a larger value can be used.

sentinel failover-timeout <master-name> <milliseconds> specifies the failover timeout:

The interval before the same Sentinel starts another failover for the same master is twice the failover timeout. That is, after the first failover fails, it must wait 2x the time before retrying.
The time needed to forcibly switch a replica that is replicating the wrong master to the correct master, per the current Sentinel config, is exactly the failover timeout.
The time to abort an in-progress failover that produced no config change (it already executed SLAVEOF NO ONE but the promoted replica has not confirmed). Failover starts but gets stuck with no progress -> wait milliseconds -> abort failover.
The maximum time an in-progress failover waits for all replicas to be reconfigured as replicas of the new master. Start reconfiguring all replicas -> wait milliseconds -> force continue (ignoring parallel-syncs).

sentinel notification-script <master-name> <script-path> is a notification script, triggered when Sentinel detects a warning-level event, used to notify the administrator (email, SMS, etc.).

sentinel client-reconfig-script <master-name> <script-path> is a client-reconfiguration script, triggered after a failover completes, used to tell the client the master has changed (e.g. update client connection config). Parameters passed: <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>, where from-ip:from-port is the old master address and <to-ip:to-port> is the new master address. <state> is failover, role is leader or observer.

sentinel deny-scripts-reconfig yes is a safety setting that forbids dynamically modifying script paths via the sentinel set command, preventing malicious users from triggering arbitrary code execution by tampering with the script path. Once enabled, the script path can only be updated by editing sentinel.conf directly and restarting sentinel.

SENTINEL rename-command mymaster CONFIG GUESSME renames a command. In cloud or managed environments, sensitive Redis commands (such as CONFIG, SLAVEOF) may be renamed to prevent unauthorized operations. Sentinel relies on these commands to manage Redis nodes, so you must tell Sentinel the new command names via sentinel rename-command, otherwise Sentinel will not work properly. It only takes effect for the specified node and must be configured identically on all relevant sentinel instances. Sentinel depends on the following commands:

CONFIG
SLAVEOF
INFO
ROLE
PING

These commands must all be correctly renamed.

SENTINEL resolve-hostnames no toggles hostname resolution. When set to yes, sentinel allows hostnames in the config. Hostnames support configuration resolution; by default sentinel only supports IP addresses for node monitoring and communication. In dynamic network environments (containers, cloud services) node IPs may change frequently, and using hostnames instead of IPs improves config flexibility. By enabling resolve-hostnames and announce-hostnames, sentinel can support hostname resolution and advertisement, but DNS must be reliable.

SENTINEL announce-hostnames no toggles whether hostnames are advertised in communication and logs; only takes effect when resolve-hostnames is yes.

Sentinel Example

A sentinel can be started with the redis-sentinel command: redis-sentinel /path/to/sentinel.conf. Or with redis-server /path/to/sentinel.conf --sentinel.

Configuration example:

# bind 127.0.0.1 192.168.1.1
# protected-mode no
port 26379
daemonize no
pidfile "/home/sl/redis/redis-sentinel.pid"
logfile ""
# sentinel announce-ip <ip>
# sentinel announce-port <port>
dir "/tmp"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
# sentinel auth-pass <master-name> <password>
# sentinel auth-user <master-name> <username>
# sentinel down-after-milliseconds <master-name> <milliseconds>
acllog-max-len 128
sentinel deny-scripts-reconfig yes
sentinel resolve-hostnames no
sentinel announce-hostnames no

After setting up one master and one replica, start the sentinel cluster:

# Start the first sentinel
postgres@slpc:~/redis$ redis-sentinel sentinel.conf 
5748:X 22 Oct 2025 13:53:27.472 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5748:X 22 Oct 2025 13:53:27.472 # Redis version=6.2.18, bits=64, commit=ee4d13ab, modified=0, pid=5748, just started
5748:X 22 Oct 2025 13:53:27.472 # Configuration loaded
5748:X 22 Oct 2025 13:53:27.474 * Increased maximum number of open files to 10032 (it was originally set to 1024).
5748:X 22 Oct 2025 13:53:27.474 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.18 (ee4d13ab/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 5748
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

5748:X 22 Oct 2025 13:53:27.489 # Sentinel ID is 835b43912bcb0a5dd08d833aef340e97aa9237a8
5748:X 22 Oct 2025 13:53:27.489 # +monitor master mymaster 127.0.0.1 6379 quorum 2
5748:X 22 Oct 2025 13:53:27.490 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

# Start the second sentinel
postgres@slpc:~/redis$ redis-server sentinel2.conf --sentinel
5944:X 22 Oct 2025 14:03:31.297 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5944:X 22 Oct 2025 14:03:31.297 # Redis version=6.2.18, bits=64, commit=ee4d13ab, modified=0, pid=5944, just started
5944:X 22 Oct 2025 14:03:31.297 # Configuration loaded
5944:X 22 Oct 2025 14:03:31.299 * Increased maximum number of open files to 10032 (it was originally set to 1024).
5944:X 22 Oct 2025 14:03:31.299 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.18 (ee4d13ab/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26380
 |    `-._   `._    /     _.-'    |     PID: 5944
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

5944:X 22 Oct 2025 14:03:31.302 # Sentinel ID is 8a0fe5db2c44b9f2f2dbb316439940e48cfdbe82
5944:X 22 Oct 2025 14:03:31.302 # +monitor master mymaster 127.0.0.1 6379 quorum 2
5944:X 22 Oct 2025 14:03:31.303 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
5944:X 22 Oct 2025 14:03:32.809 * +sentinel sentinel 835b43912bcb0a5dd08d833aef340e97aa9237a8 127.0.0.1 26379 @ mymaster 127.0.0.1 6379

# Start the third sentinel
postgres@slpc:~/redis$ redis-sentinel sentinel3.conf 
6112:X 22 Oct 2025 14:06:51.641 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
6112:X 22 Oct 2025 14:06:51.641 # Redis version=6.2.18, bits=64, commit=ee4d13ab, modified=0, pid=6112, just started
6112:X 22 Oct 2025 14:06:51.641 # Configuration loaded
6112:X 22 Oct 2025 14:06:51.644 * Increased maximum number of open files to 10032 (it was originally set to 1024).
6112:X 22 Oct 2025 14:06:51.644 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.18 (ee4d13ab/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26381
 |    `-._   `._    /     _.-'    |     PID: 6112
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

6112:X 22 Oct 2025 14:06:51.649 # Sentinel ID is 689e2740152a2cd47744ebe6f78efe50c2a9005a
6112:X 22 Oct 2025 14:06:51.649 # +monitor master mymaster 127.0.0.1 6379 quorum 2
6112:X 22 Oct 2025 14:06:51.650 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
6112:X 22 Oct 2025 14:06:52.841 * +sentinel sentinel 835b43912bcb0a5dd08d833aef340e97aa9237a8 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
6112:X 22 Oct 2025 14:06:53.107 * +sentinel sentinel 8a0fe5db2c44b9f2f2dbb316439940e48cfdbe82 127.0.0.1 26380 @ mymaster 127.0.0.1 6379

After starting the sentinel cluster, inspect the sentinel config file:

# Generated by CONFIG REWRITE
protected-mode no
user default on nopass ~* &* +@all
sentinel myid 835b43912bcb0a5dd08d833aef340e97aa9237a8
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel current-epoch 0
sentinel known-replica mymaster 127.0.0.1 6380
sentinel known-sentinel mymaster 127.0.0.1 26381 689e2740152a2cd47744ebe6f78efe50c2a9005a
sentinel known-sentinel mymaster 127.0.0.1 26380 8a0fe5db2c44b9f2f2dbb316439940e48cfdbe82

When the master goes down, sentinel picks a replica and promotes it to master.

5272:S 22 Oct 2025 14:31:05.932 # Connection with master lost.
5272:S 22 Oct 2025 14:31:05.932 * Caching the disconnected master state.   # master disconnection detected
5272:S 22 Oct 2025 14:31:05.932 * Reconnecting to MASTER 127.0.0.1:6379   # trying to reconnect to master
5272:S 22 Oct 2025 14:31:05.932 * MASTER <-> REPLICA sync started
5272:S 22 Oct 2025 14:31:05.932 # Error condition on socket for SYNC: Connection refused
5272:S 22 Oct 2025 14:31:06.920 * Connecting to MASTER 127.0.0.1:6379
# ...
5272:S 22 Oct 2025 14:31:35.338 * MASTER <-> REPLICA sync started
5272:S 22 Oct 2025 14:31:35.338 # Error condition on socket for SYNC: Connection refused
5272:M 22 Oct 2025 14:31:36.294 * Discarding previously cached master state.
5272:M 22 Oct 2025 14:31:36.295 # Setting secondary replication ID to 14cb2814458f612a68f5d793131341893af1e20f, valid up to offset: 355634. New replication ID is 1a6ec8c82c1cf3d041aca7f21caa32a4d4d49565
# promote the replica to master
5272:M 22 Oct 2025 14:31:36.295 * MASTER MODE enabled (user request from 'id=7 addr=127.0.0.1:37586 laddr=127.0.0.1:6380 fd=11 name=sentinel-8a0fe5db-cmd age=1685 idle=0 flags=x db=0 sub=0 psub=0 multi=4 qbuf=188 qbuf-free=40766 argv-mem=4 obl=45 oll=0 omem=0 tot-mem=61468 events=r cmd=exec user=default redir=-1')
5272:M 22 Oct 2025 14:31:36.300 # CONFIG REWRITE executed with success.

The sentinel node logs at this point:

5748:X 22 Oct 2025 14:31:35.992 # +sdown master mymaster 127.0.0.1 6379
5748:X 22 Oct 2025 14:31:36.079 # +new-epoch 1
5748:X 22 Oct 2025 14:31:36.081 # +vote-for-leader 8a0fe5db2c44b9f2f2dbb316439940e48cfdbe82 1
5748:X 22 Oct 2025 14:31:36.092 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
5748:X 22 Oct 2025 14:31:36.092 # Next failover delay: I will not start a failover before Wed Oct 22 14:37:36 2025
5748:X 22 Oct 2025 14:31:36.933 # +config-update-from sentinel 8a0fe5db2c44b9f2f2dbb316439940e48cfdbe82 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
5748:X 22 Oct 2025 14:31:36.933 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
5748:X 22 Oct 2025 14:31:36.933 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
5748:X 22 Oct 2025 14:32:06.974 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

Now query the master through sentinel:

127.0.0.1:26379> sentinel get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6380"

Deployment Recommendations

In production, deploy at least 3 sentinels across 3 different servers.

         +----+
         | M1 |
         | S1 | <- C1 (writes will be lost)
         +----+
            |
            /
            /
+------+    |    +----+
| [M2] |----+----| R3 |
| S2   |         | S3 |
+------+         +----+

Considering network partitions: with a 3-node deployment, if a partition isolates the old master and a client is in the same partition as the old master, the client keeps writing to the old master. When the partition heals, the old master is reconfigured as a replica of the new master and discards its dataset. To mitigate this (note: not solve it), Redis can be configured as follows — this feature lets the master stop accepting writes when it detects it cannot ship its writes to the specified number of replicas.

min-replicas-to-write 1   # a redis instance stops accepting writes if it cannot write to at least 1 replica
min-replicas-max-lag 10 # because replication is asynchronous, "cannot write" actually means the replica is either disconnected or hasn't sent us an async ack within the specified max-lag seconds. This is also why it only mitigates, not solves, the problem.

The downside of this approach is that without enough replicas, the master cannot accept writes, sacrificing availability.

To simulate a master failure and test the failover:

redis-cli -p 6379 debug sleep 30

Sentinel Commands

SENTINEL CONFIG GET <name> (>= 6.2) gets the current value of a global Sentinel config parameter. The name can be a wildcard, similar to Redis’s CONFIG GET command. SENTINEL CONFIG SET <name> <value> (>= 6.2) sets the value of a global Sentinel config parameter. SENTINEL CKQUORUM <master name> checks whether the current Sentinel configuration can reach the quorum required to fail over the master, as well as the majority required to authorize a failover. This command should be used in monitoring systems to check the Sentinel deployment is healthy.

127.0.0.1:26379> sentinel ckquorum mymaster
OK 3 usable Sentinels. Quorum and failover authorization can be reached

SENTINEL FLUSHCONFIG forces Sentinel to rewrite its config (including current Sentinel state) to disk. Normally Sentinel rewrites its config when its state changes (the subset persisted across restarts). However, sometimes due to operator error, disk failure, package-upgrade scripts, or a config manager, the config file can be lost. In that case, the ability to force a rewrite is very convenient. This command works even if the previous config file was completely lost. SENTINEL FAILOVER <master name> forces a failover as if the master were unreachable, without asking the other sentinels for agreement (but a new config version is published so other sentinels update their configs). SENTINEL GET-MASTER-ADDR-BY-NAME <master name> returns the IP and port of the master with that name. If the master is in the middle of a failover or has completed one, it returns the address and port of the replica promoted to master.

127.0.0.1:26379> sentinel get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6380"

SENTINEL INFO-CACHE (>= 3.2) returns the cached INFO output of masters and replicas. SENTINEL IS-MASTER-DOWN-BY-ADDR checks from this Sentinel’s perspective whether the master at the given IP:Port is down. Mainly for internal use. SENTINEL MASTER <master name> shows the state and info of the given master. SENTINEL MASTERS shows the list of monitored masters and their states. SENTINEL MONITOR starts Sentinel monitoring. See the “Reconfiguring Sentinel at runtime” section for details. SENTINEL MYID (>= 6.2) returns the Sentinel instance ID.

127.0.0.1:26380> sentinel myid
"8a0fe5db2c44b9f2f2dbb316439940e48cfdbe82"

SENTINEL PENDING-SCRIPTS returns information about pending scripts. SENTINEL REMOVE stops Sentinel monitoring. See the “Reconfiguring Sentinel at runtime” section for details. SENTINEL REPLICAS <master name> (>= 5.0) shows the list of replicas of this master and their states. SENTINEL SENTINELS <master name> shows the list of Sentinel instances of this master and their states. SENTINEL SET sets the Sentinel monitoring config. See the “Reconfiguring Sentinel at runtime” section for details. SENTINEL SIMULATE-FAILURE (crash-after-election|crash-after-promotion|help) (>= 3.2) simulates different Sentinel crash scenarios. SENTINEL RESET <pattern> resets all masters whose names match. The pattern argument is a glob-style pattern. The reset clears any previous state of the master (including an in-progress failover) and removes all replicas and sentinels discovered and associated with that master.

The sentinel hello command replies with the current server and connection attribute list, e.g. version, loaded modules, client id, etc.

127.0.0.1:26380> hello 3
1# "server" => "redis"
2# "version" => "6.2.18"
3# "proto" => (integer) 3
4# "id" => (integer) 5
5# "mode" => "sentinel"
6# "modules" => (empty array)

Reconfiguring Sentinel at runtime:

SENTINEL MONITOR <name> <ip> <port> <quorum> tells Sentinel to start monitoring a new master, specifying its name, IP, port, and quorum. It is the same as the sentinel monitor directive in sentinel.conf, except you cannot use a hostname as the ip — you must provide an IPv4 or IPv6 address.
SENTINEL REMOVE <name> removes the given master: it is no longer monitored and is fully removed from Sentinel’s internal state, so it will no longer be listed by commands such as SENTINEL masters.
SENTINEL SET <name> [<option> <value> ...] the SET command is very similar to Redis’s CONFIG SET, and changes the config parameters of a specific master. Multiple option/value pairs can be given (or none). All parameters configurable via sentinel.conf can also be configured via the SET command.

# change a config parameter
127.0.0.1:26380> sentinel set mymaster down-after-milliseconds 1000
OK
# change the master's quorum
127.0.0.1:26380> sentinel set mymaster quorum 2
OK

Removing or Adding Sentinels

Sentinel has a self-discovery mechanism, so adding a new sentinel to a deployment is simple: just start a new Sentinel configured to monitor the current active master. Within 10 seconds the new Sentinel will learn the list of other sentinels and the set of replicas connected to the master. If you need to add multiple sentinels at once, add them one at a time, waiting until all other sentinels know the first one before adding the next; this helps ensure that if a failure happens during the addition, a majority can still only form on one side of a partition. Without a network partition, wait 30 seconds between adding each new sentinel instance.

Removing a Sentinel instance: Sentinel never forgets a Sentinel it has seen, even if it is unreachable for a long time. Therefore, without a network partition, perform the following steps to remove a Sentinel:

Stop the Sentinel instance to be removed.
Send the sentinel reset <mastername> command to all other Sentinel instances (use the exact master name instead of * if you only want to reset a single master). Send them one at a time, waiting at least 30 seconds between instances.
Check the output of each Sentinel’s sentinel master mastername command to confirm all sentinels agree on the number of currently active sentinels.

Sentinel Implementation Details

SDOWN and ODOWN States

Sentinel has two different “down” concepts. One is the Subjective Down state SDOWN, which is a down state local to a single Sentinel instance. The other is the Objective Down state ODOWN, reached when enough (at least the number specified by the quorum parameter configured for the monitored master) Sentinels are in SDOWN and have obtained feedback from other Sentinels via the SENTINEL is-master-down-by-addr command.

From a single Sentinel’s perspective, the SDOWN state is reached when it has not received a valid reply to PING within the time (seconds) specified by the is-master-down-after-milliseconds parameter in its config.

VIP Switching

In the Redis Sentinel high-availability architecture, VIP (virtual IP) switching is normally triggered by an external script. When Sentinel detects a master failure and completes the failover, it notifies the external system via the sentinel notification-script or sentinel client-reconfig-script, and the script binds the VIP to the new master.

Client → VIP (192.168.1.100)
                ↓
        [Current master: redis-node1 or redis-node2]
                
Sentinel cluster monitors master/replica state
  ↓
Master down → Sentinel elects new master → triggers script → new master binds VIP / old master unbinds VIP

role indicates the role of the Sentinel node executing the script in this failover; it can be one of three values:

Role value	Meaning	Does it run the script?
leader	This Sentinel is the leader of this failover → responsible for initiating and completing the failover	✅ runs
observer	This Sentinel is an observer → only monitors, does not participate in the election, but knows the result	✅ runs
sentinel	A normal Sentinel (may appear in old versions; new versions are usually observer)	✅ runs

✅ Conclusion: all Sentinel nodes execute client-reconfig-script after a failover completes! Note that

Redis Sentinel is a decentralized cluster; every Sentinel node runs independently and synchronizes state via the gossip protocol.

When the failover completes, all Sentinel nodes update their internal view of the master
To notify external systems (proxies, clients, VIP managers), every Sentinel triggers a callback
This design provides high availability and redundancy: even if one Sentinel goes down, the others can still notify

All sentinel nodes execute this VIP script, but a sentinel node is not necessarily on the same host as the Redis master/replica nodes.

Option	Description
✅ Client connects directly to Sentinel	The app gets the master address via Sentinel (e.g. Jedis, Lettuce), no VIP needed
✅ Keepalived + custom health check	Keepalived monitors whether the local Redis is master and manages the VIP automatically
⚠️ Sentinel + script	Complex, error-prone, only suitable for small controllable environments

Redis Sentinel High Availability