]> git.saurik.com Git - redis.git/blob - sentinel.conf
Test for SRANDMEMBER with <count>.
[redis.git] / sentinel.conf
1 # Example sentinel.conf
2
3 # port <sentinel-port>
4 # The port that this sentinel instance will run on
5 port 26379
6
7 # sentinel monitor <master-name> <ip> <redis-port> <quorum>
8 #
9 # Tells Sentinel to monitor this slave, and to consider it in O_DOWN
10 # (Objectively Down) state only if at least <quorum> sentinels agree.
11 #
12 # Note: master name should not include special characters or spaces.
13 # The valid charset is A-z 0-9 and the three characters ".-_".
14 sentinel monitor mymaster 127.0.0.1 6379 2
15
16 # sentinel down-after-milliseconds <master-name> <milliseconds>
17 #
18 # Number of milliseconds the master (or any attached slave or sentinel) should
19 # be unreachable (as in, not acceptable reply to PING, continuously, for the
20 # specified period) in order to consider it in S_DOWN state (Subjectively
21 # Down).
22 #
23 # Default is 30 seconds.
24 sentinel down-after-milliseconds mymaster 30000
25
26 # sentinel can-failover <master-name> <yes|no>
27 #
28 # Specify if this Sentinel can start the failover for this master.
29 sentinel can-failover mymaster yes
30
31 # sentinel parallel-syncs <master-name> <numslaves>
32 #
33 # How many slaves we can reconfigure to point to the new slave simultaneously
34 # during the failover. Use a low number if you use the slaves to serve query
35 # to avoid that all the slaves will be unreachable at about the same
36 # time while performing the synchronization with the master.
37 sentinel parallel-syncs mymaster 1
38
39 # sentinel failover-timeout <master-name> <milliseconds>
40 #
41 # Specifies the failover timeout in milliseconds. When this time has elapsed
42 # without any progress in the failover process, it is considered concluded by
43 # the sentinel even if not all the attached slaves were correctly configured
44 # to replicate with the new master (however a "best effort" SLAVEOF command
45 # is sent to all the slaves before).
46 #
47 # Also when 25% of this time has elapsed without any advancement, and there
48 # is a leader switch (the sentinel did not started the failover but is now
49 # elected as leader), the sentinel will continue the failover doing a
50 # "takeover".
51 #
52 # Default is 15 minutes.
53 sentinel failover-timeout mymaster 900000
54
55 # SCRIPTS EXECTION
56 #
57 # sentinel notification-script and sentinel reconfig-script are used in order
58 # to configure scripts that are called to notify the system administrator
59 # or to reconfigure clients after a failover. The scripts are executed
60 # with the following rules for error handling:
61 #
62 # If script exists with "1" the execution is retried later (up to a maximum
63 # number of times currently set to 10).
64 #
65 # If script exists with "2" (or an higher value) the script execution is
66 # not retried.
67 #
68 # If script terminates because it receives a signal the behavior is the same
69 # as exit code 1.
70 #
71 # A script has a maximum running time of 60 seconds. After this limit is
72 # reached the script is terminated with a SIGKILL and the execution retried.
73
74 # NOTIFICATION SCRIPT
75 #
76 # sentinel notification-script <master-name> <script-path>
77 #
78 # Call the specified notification script for any sentienl event that is
79 # generated in the WARNING level (for instance -sdown, -odown, and so forth).
80 # This script should notify the system administrator via email, SMS, or any
81 # other messaging system, that there is something wrong with the monitored
82 # Redis systems.
83 #
84 # The script is called with just two arguments: the first is the event type
85 # and the second the event description.
86 #
87 # The script must exist and be executable in order for sentinel to start if
88 # this option is provided.
89 #
90 # Example:
91 #
92 # sentinel notification-script mymaster /var/redis/notify.sh
93
94 # CLIENTS RECONFIGURATION SCRIPT
95 #
96 # sentinel client-reconfig-script <master-name> <script-path>
97 #
98 # When the failover starts, ends, or is aborted, a script can be called in
99 # order to perform application-specific tasks to notify the clients that the
100 # configuration has changed and the master is at a different address.
101 #
102 # The script is called in the following cases:
103 #
104 # Failover started (a slave is already promoted)
105 # Failover finished (all the additional slaves already reconfigured)
106 # Failover aborted (in that case the script was previously called when the
107 # failover started, and now gets called again with swapped
108 # addresses).
109 #
110 # The following arguments are passed to the script:
111 #
112 # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
113 #
114 # <state> is "start", "end" or "abort"
115 # <role> is either "leader" or "observer"
116 #
117 # The arguments from-ip, from-port, to-ip, to-port are used to communicate
118 # the old address of the master and the new address of the elected slave
119 # (now a master) in the case state is "start" or "end".
120 #
121 # For abort instead the "from" is the address of the promoted slave and
122 # "to" is the address of the original master address, since the failover
123 # was aborted.
124 #
125 # This script should be resistant to multiple invocations.
126 #
127 # Example:
128 #
129 # sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
130
131