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