redis sentinel sentinel sentinel_conf_eng

Sentinel Configuration file

Redis Sentinel 教育 Redis Sentinel Course	Redis 定期点検/技術支援 Redis Technical Support	Redis エンタープライズサーバ Redis Enterprise Server

---

SENTINEL.CONF

이 문서는 버전 5.0.3를 기준으로 작성되었습니다.

---

Example sentinel.conf
*** IMPORTANT ***
By default Sentinel will not be reachable from interfaces different than localhost, either use the 'bind' directive to bind to a list of network interfaces, or disable protected mode with "protected-mode no" by adding it to this configuration file.
Before doing that MAKE SURE the instance is protected from the outside world via firewalling or other means.

PORT

For example you may use one of the following:
# bind 127.0.0.1 192.168.1.1
# protected-mode no
# port <sentinel-port>
The port that this sentinel instance will run on

port 26379

DAEMONIZE

By default Redis Sentinel does not run as a daemon. Use 'yes' if you need it. Note that Redis will write a pid file in /var/run/redis-sentinel.pid when daemonized.

daemonize no

PIDFILE

When running daemonized, Redis Sentinel writes a pid file in /var/run/redis-sentinel.pid by default. You can specify a custom pid file location here.

pidfile /var/run/redis-sentinel.pid

LOGFILE

Specify the log file name. Also the empty string can be used to force Sentinel to log on the standard output. Note that if you use standard output for logging but daemonize, logs will be sent to /dev/null

logfile ""

ANNOUNCE-IP

# sentinel announce-ip <ip>
# sentinel announce-port <port>
The above two configuration directives are useful in environments where, because of NAT, Sentinel is reachable from outside via a non-local address.
When announce-ip is provided, the Sentinel will claim the specified IP address in HELLO messages used to gossip its presence, instead of auto-detecting the local address as it usually does.
Similarly when announce-port is provided and is valid and non-zero, Sentinel will announce the specified TCP port.
The two options don't need to be used together, if only announce-ip is provided, the Sentinel will announce the specified IP and the server port as specified by the "port" option. If only announce-port is provided, the Sentinel will announce the auto-detected local IP and the specified port.
Example:

# sentinel announce-ip 1.2.3.4

DIR

# dir <working-directory>
Every long running process should have a well-defined working directory. For Redis Sentinel to chdir to /tmp at startup is the simplest thing for the process to don't interfere with administrative tasks such as unmounting filesystems.

dir /tmp

SENTINEL MONITOR

SENTINEL MONITOR

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
Tells Sentinel to monitor this master, and to consider it in O_DOWN (Objectively Down) state only if at least <quorum> sentinels agree.
Note that whatever is the ODOWN quorum, a Sentinel will require to be elected by the majority of the known Sentinels in order to start a failover, so no failover can be performed in minority.
Replicas are auto-discovered, so you don't need to specify replicas in any way. Sentinel itself will rewrite this configuration file adding the replicas using additional configuration options.
Also note that the configuration file is rewritten when a replica is promoted to master.
Note: master name should not include special characters or spaces. The valid charset is A-z 0-9 and the three characters ".-_".

sentinel monitor mymaster 127.0.0.1 6379 2

SENTINEL AUTH-PASS

# sentinel auth-pass <master-name> <password>
Set the password to use to authenticate with the master and replicas. Useful if there is a password set in the Redis instances to monitor.
Note that the master password is also used for replicas, so it is not possible to set a different password in masters and replicas instances if you want to be able to monitor these instances with Sentinel.
However you can have Redis instances without the authentication enabled mixed with Redis instances requiring the authentication (as long as the password set is the same for all the instances requiring the password) as the AUTH command will have no effect in Redis instances with authentication switched off.
Example:

# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

SENTINEL DOWN-AFTER-MILLISECONDS

# sentinel down-after-milliseconds <master-name> <milliseconds>
Number of milliseconds the master (or any attached replica or sentinel) should be unreachable (as in, not acceptable reply to PING, continuously, for the specified period) in order to consider it in S_DOWN state (Subjectively Down).
Default is 30 seconds.

sentinel down-after-milliseconds mymaster 30000

SENTINEL PARALLEL-SYNCS

sentinel parallel-syncs <master-name> <numreplicas>
How many replicas we can reconfigure to point to the new replica simultaneously during the failover. Use a low number if you use the replicas to serve query to avoid that all the replicas will be unreachable at about the same time while performing the synchronization with the master.

sentinel parallel-syncs mymaster 1

SENTINEL FAILOVER-TIMEOUT

# sentinel failover-timeout <master-name> <milliseconds>
Specifies the failover timeout in milliseconds. It is used in many ways:
- The time needed to re-start a failover after a previous failover was already tried against the same master by a given Sentinel, is two times the failover timeout.
- The time needed for a replica replicating to a wrong master according to a Sentinel current configuration, to be forced to replicate with the right master, is exactly the failover timeout (counting since the moment a Sentinel detected the misconfiguration).
- The time needed to cancel a failover that is already in progress but did not produced any configuration change (SLAVEOF NO ONE yet not acknowledged by the promoted replica).
- The maximum time a failover in progress waits for all the replicas to be reconfigured as replicas of the new master. However even after this time the replicas will be reconfigured by the Sentinels anyway, but not with the exact parallel-syncs progression as specified.
Default is 3 minutes.

sentinel failover-timeout mymaster 180000

SCRIPTS EXECUTION

sentinel notification-script and sentinel reconfig-script are used in order to configure scripts that are called to notify the system administrator or to reconfigure clients after a failover. The scripts are executed with the following rules for error handling:
If script exits with "1" the execution is retried later (up to a maximum number of times currently set to 10).
If script exits with "2" (or an higher value) the script execution is not retried.
If script terminates because it receives a signal the behavior is the same as exit code 1.
A script has a maximum running time of 60 seconds. After this limit is reached the script is terminated with a SIGKILL and the execution retried.

NOTIFICATION-SCRIPT

sentinel notification-script <master-name> <script-path>
Call the specified notification script for any sentinel event that is generated in the WARNING level (for instance -sdown, -odown, and so forth). This script should notify the system administrator via email, SMS, or any other messaging system, that there is something wrong with the monitored Redis systems.
The script is called with just two arguments: the first is the event type and the second the event description.
The script must exist and be executable in order for sentinel to start if this option is provided.
Example:

# sentinel notification-script mymaster /var/redis/notify.sh

CLIENT-RECONFIG-SCRIPT

sentinel client-reconfig-script <master-name> <script-path>
When the master changed because of a failover a script can be called in order to perform application-specific tasks to notify the clients that the configuration has changed and the master is at a different address.
The following arguments are passed to the script:
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
<state> is currently always "failover"
<role> is either "leader" or "observer"
The arguments from-ip, from-port, to-ip, to-port are used to communicate the old address of the master and the new address of the elected replica (now a master).
This script should be resistant to multiple invocations.
Example:

# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

DENY-SCRIPTS-RECONFIG

SECURITY
By default SENTINEL SET will not be able to change the notification-script and client-reconfig-script at runtime. This avoids a trivial security issue where clients can set the script to anything and trigger a failover in order to get the program executed.

sentinel deny-scripts-reconfig yes

REDIS COMMANDS RENAMING

SENTINEL RENAME-COMMAND

Sometimes the Redis server has certain commands, that are needed for Sentinel to work correctly, renamed to unguessable strings. This is often the case of CONFIG and SLAVEOF in the context of providers that provide Redis as a service, and don't want the customers to reconfigure the instances outside of the administration console.
In such case it is possible to tell Sentinel to use different command names instead of the normal ones. For example if the master "mymaster", and the associated replicas, have "CONFIG" all renamed to "GUESSME", I could use:
SENTINEL rename-command mymaster CONFIG GUESSME
After such configuration is set, every time Sentinel would use CONFIG it will use GUESSME instead. Note that there is no actual need to respect the command case, so writing "config guessme" is the same in the example above.
SENTINEL SET can also be used in order to perform this configuration at runtime.
In order to set a command back to its original name (undo the renaming), it is possible to just rename a command to itsef:

# SENTINEL rename-command mymaster CONFIG CONFIG

---

<< Server Data Structure	Redis.conf eng >>

조회수 :