Configuring Redis servers for failover operation

Attention!

Cache Redis.Cluster is not used in ELMA!

Configure Redis Master and several Redis Slave servers as described here.

Also configure Redis sentinel architectother according to the documentation: https://redis.io/topics/sentinel.

Configuring Redis.sentinel

If Redis.sentinel is configured and the master server is down, then one of the slave servers will be reconfigured as the master. This decision is made by all the started Redis.sentinel servers, having reached a quorum (the sentinel monitor parameter in the configuration). Once the master server is up again, it will be reconfigured as a slave.

To configure, create a file /etc/redis/redis.sentinel.conf on each server:

# *** 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.
 
#
 
# For example you may use one of the following:
 
#
 
# bind 0.0.0.0
 
protected-mode no
 
  
 
# port <sentinel-port>
 
# The port that this sentinel instance will run on
 
port 16379
 
  
 
# By default Redis does not run as a daemon. Use ’yes’ if you need it.
 
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
 
daemonize yes
 
  
 
# Specify the log file name. Also the empty string can be used to force
 
# Redis 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 /var/log/redis/redis-sentinel.log
 
  
 
# 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.
 
#
 
# Slaves are auto-discovered, so you don’t need to specify slaves in
 
# any way. Sentinel itself will rewrite this configuration file adding
 
# the slaves using additional configuration options.
 
# Also note that the configuration file is rewritten when a
 
# slave 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 elma-redis your_redis_master_ip  6379 2
 
  
 
# sentinel auth-pass <master-name> <password>
 
#
 
# Set the password to use to authenticate with the master and slaves.
 
# Useful if there is a password set in the Redis instances to monitor.
 
#
 
# Note that the master password is also used for slaves, so it is not
 
# possible to set a different password in masters and slaves 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.
 
sentinel auth-pass elma-redis your_redis_password
 
  
 
# sentinel down-after-milliseconds <master-name> <milliseconds>
 
#
 
# Number of milliseconds the master (or any attached slave 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 elma-redis 30000
 
  
 
# 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 slave 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 slave).
 
#
 
# - The maximum time a failover in progress waits for all the slaves to be
 
#   reconfigured as slaves of the new master. However even after this time
 
#   the slaves will be reconfigured by the Sentinels anyway, but not with
 
#   the exact parallel-syncs progression as specified.
 
#
 
# Default is 3 minutes.
 
sentinel failover-timeout elma-redis 180000

bind 0.0.0.0 makes the Redis.sentinel service available from all external addresses

Specify the Master address and port and the value for reaching a quorum:

sentinel monitor elma-redis your_redis_master_ip 6379 2

Specify a password for accessing the Master:

sentinel auth-pass elma-redis your_redis_password

Create a folder /var/log/redis/ and configure access to it.
Configure bindings to network interfaces. Generally, protected-mode no is used

Attention!

When a sentinel server is operational, configuration files of the server and of each Redis server change, therefore you must grant access to overwriting them.

To configure a sentinel server as a service, create a file /etc/init.d/redis-sentinel on each server and configure access permissions:

#!/bin/bash
 
# Start/Stop/restart script for Redis Sentinel
 
  
 
NAME=`basename ${0}`
 
EXEC=/usr/bin/redis-server
 
PIDFILE="/var/run/redis/${NAME}.pid"
 
CONF="/etc/redis/redis.sentinel.conf"
 
  
 
PID=`cat $PIDFILE 2> /dev/null`
 
case "$1" in
 
     start)
 
         echo "Starting $NAME ..."
 
         touch $PIDFILE
 
         exec $EXEC $CONF --sentinel --pidfile $PIDFILE
 
         ;;
 
     stop)
 
         echo "Stopping $NAME ..."
 
         kill -9 $PID
 
         ;;
 
     restart)
 
         echo "Restarting $NAME ..."
 
         $0 stop
 
         sleep 2
 
         $0 start
 
         ;;
 
     *)
 
         echo "Usage $0 {start|stop|restart}"
 
         ;;
 
esac

EXEC=/usr/bin/redis-server or /usr/local/bin/redis-server (executable redis-server application; you can take it from the file /etc/init.d/redis-server)

Create a folder /var/run/redis, configure access to it.

After that, the sentinel service must be started on each server:

sudo service redis-sentinel start

sudo redis-sentinel /etc/redis/redis.sentinel.conf

where / etc / redis / redis.sentinel.conf is the path to the required sentinel configuration

The system functioning has been tested with Redis 4.0.1.