1# Example sentinel.conf 2 3# port <sentinel-port> 4# The port that this sentinel instance will run on 5port 26379 6 7# sentinel announce-ip <ip> 8# sentinel announce-port <port> 9# 10# The above two configuration directives are useful in environments where, 11# because of NAT, Sentinel is reachable from outside via a non-local address. 12# 13# When announce-ip is provided, the Sentinel will claim the specified IP address 14# in HELLO messages used to gossip its presence, instead of auto-detecting the 15# local address as it usually does. 16# 17# Similarly when announce-port is provided and is valid and non-zero, Sentinel 18# will announce the specified TCP port. 19# 20# The two options don't need to be used together, if only announce-ip is 21# provided, the Sentinel will announce the specified IP and the server port 22# as specified by the "port" option. If only announce-port is provided, the 23# Sentinel will announce the auto-detected local IP and the specified port. 24# 25# Example: 26# 27# sentinel announce-ip 1.2.3.4 28 29# dir <working-directory> 30# Every long running process should have a well-defined working directory. 31# For Redis Sentinel to chdir to /tmp at startup is the simplest thing 32# for the process to don't interfere with administrative tasks such as 33# unmounting filesystems. 34dir /tmp 35 36# sentinel monitor <master-name> <ip> <redis-port> <quorum> 37# 38# Tells Sentinel to monitor this master, and to consider it in O_DOWN 39# (Objectively Down) state only if at least <quorum> sentinels agree. 40# 41# Note that whatever is the ODOWN quorum, a Sentinel will require to 42# be elected by the majority of the known Sentinels in order to 43# start a failover, so no failover can be performed in minority. 44# 45# Slaves are auto-discovered, so you don't need to specify slaves in 46# any way. Sentinel itself will rewrite this configuration file adding 47# the slaves using additional configuration options. 48# Also note that the configuration file is rewritten when a 49# slave is promoted to master. 50# 51# Note: master name should not include special characters or spaces. 52# The valid charset is A-z 0-9 and the three characters ".-_". 53sentinel monitor mymaster 127.0.0.1 6379 2 54 55# sentinel auth-pass <master-name> <password> 56# 57# Set the password to use to authenticate with the master and slaves. 58# Useful if there is a password set in the Redis instances to monitor. 59# 60# Note that the master password is also used for slaves, so it is not 61# possible to set a different password in masters and slaves instances 62# if you want to be able to monitor these instances with Sentinel. 63# 64# However you can have Redis instances without the authentication enabled 65# mixed with Redis instances requiring the authentication (as long as the 66# password set is the same for all the instances requiring the password) as 67# the AUTH command will have no effect in Redis instances with authentication 68# switched off. 69# 70# Example: 71# 72# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd 73 74# sentinel down-after-milliseconds <master-name> <milliseconds> 75# 76# Number of milliseconds the master (or any attached slave or sentinel) should 77# be unreachable (as in, not acceptable reply to PING, continuously, for the 78# specified period) in order to consider it in S_DOWN state (Subjectively 79# Down). 80# 81# Default is 30 seconds. 82sentinel down-after-milliseconds mymaster 30000 83 84# sentinel parallel-syncs <master-name> <numslaves> 85# 86# How many slaves we can reconfigure to point to the new slave simultaneously 87# during the failover. Use a low number if you use the slaves to serve query 88# to avoid that all the slaves will be unreachable at about the same 89# time while performing the synchronization with the master. 90sentinel parallel-syncs mymaster 1 91 92# sentinel failover-timeout <master-name> <milliseconds> 93# 94# Specifies the failover timeout in milliseconds. It is used in many ways: 95# 96# - The time needed to re-start a failover after a previous failover was 97# already tried against the same master by a given Sentinel, is two 98# times the failover timeout. 99# 100# - The time needed for a slave replicating to a wrong master according 101# to a Sentinel current configuration, to be forced to replicate 102# with the right master, is exactly the failover timeout (counting since 103# the moment a Sentinel detected the misconfiguration). 104# 105# - The time needed to cancel a failover that is already in progress but 106# did not produced any configuration change (SLAVEOF NO ONE yet not 107# acknowledged by the promoted slave). 108# 109# - The maximum time a failover in progress waits for all the slaves to be 110# reconfigured as slaves of the new master. However even after this time 111# the slaves will be reconfigured by the Sentinels anyway, but not with 112# the exact parallel-syncs progression as specified. 113# 114# Default is 3 minutes. 115sentinel failover-timeout mymaster 180000 116 117# SCRIPTS EXECUTION 118# 119# sentinel notification-script and sentinel reconfig-script are used in order 120# to configure scripts that are called to notify the system administrator 121# or to reconfigure clients after a failover. The scripts are executed 122# with the following rules for error handling: 123# 124# If script exits with "1" the execution is retried later (up to a maximum 125# number of times currently set to 10). 126# 127# If script exits with "2" (or an higher value) the script execution is 128# not retried. 129# 130# If script terminates because it receives a signal the behavior is the same 131# as exit code 1. 132# 133# A script has a maximum running time of 60 seconds. After this limit is 134# reached the script is terminated with a SIGKILL and the execution retried. 135 136# NOTIFICATION SCRIPT 137# 138# sentinel notification-script <master-name> <script-path> 139# 140# Call the specified notification script for any sentinel event that is 141# generated in the WARNING level (for instance -sdown, -odown, and so forth). 142# This script should notify the system administrator via email, SMS, or any 143# other messaging system, that there is something wrong with the monitored 144# Redis systems. 145# 146# The script is called with just two arguments: the first is the event type 147# and the second the event description. 148# 149# The script must exist and be executable in order for sentinel to start if 150# this option is provided. 151# 152# Example: 153# 154# sentinel notification-script mymaster /var/redis/notify.sh 155 156# CLIENTS RECONFIGURATION SCRIPT 157# 158# sentinel client-reconfig-script <master-name> <script-path> 159# 160# When the master changed because of a failover a script can be called in 161# order to perform application-specific tasks to notify the clients that the 162# configuration has changed and the master is at a different address. 163# 164# The following arguments are passed to the script: 165# 166# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> 167# 168# <state> is currently always "failover" 169# <role> is either "leader" or "observer" 170# 171# The arguments from-ip, from-port, to-ip, to-port are used to communicate 172# the old address of the master and the new address of the elected slave 173# (now a master). 174# 175# This script should be resistant to multiple invocations. 176# 177# Example: 178# 179# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh 180 181 182