Redis Sentinel mode

1. Master/slave replication is highly available

Problems arise when we use master-slave replication

  • Manual failover
  • Write and storage capabilities are limited
  • Master/Slave replication – Handle the fault that the master is down

The method of the master-slave switchover technology is: when the master server is down, you need to manually switch a slave server to the master server, which requires manual intervention, laborious, and will cause service unavailability for a period of time. This is not a recommended approach, and more often than not, we prefer sentinel mode.

~ Sentry mode overview

Sentinel mode is a special mode, first of all Redis provides sentinel command, sentinel is an independent process, as a process, it will run independently. The idea is that sentry monitors multiple instances of Redis running by sending commands and waiting for the Redis server to respond.

The sentry has two main functions

  • The Redis server is sent back to monitor its running status, both primary and secondary, by sending commands.

  • When the sentry detects that the master is down, it automatically switches the slave to master and notifies the other slave servers in public-subscribe mode to modify their configuration files and make them switch hosts.

However, one sentry process monitoring the Redis server can cause problems, so we can use multiple sentries to monitor. Each sentry is also monitored, creating a multi-sentry mode.

The process of failover. If the primary server is down and Sentry 1 detects this result first, the system does not perform a failover immediately, but sentry 1 thinks that the primary server is unavailable, and this phenomenon becomes a subjective offline. When the sentries at the back also detect that the primary server is unavailable and the number reaches a certain value, a vote is conducted between the sentries. The result of the vote is initiated by one sentry and failover is performed. After the switch is successful, each sentinel will switch the host from the secondary server monitored by himself through the publish and subscribe mode, which is called objective offline process. This makes everything transparent to the client.

Ii. Structure description

  1. Multiple Sentinels detected and confirmed problems with master.
  2. A Sentinel was elected as leader
  3. Select a slave as master
  4. Notify the remaining slaves to become the slaves of the new master
  5. Notifies clients of primary/secondary changes
  6. Slave waiting for the old master to be resurrected as the new master

Three, installation and configuration

  1. Configure the primary and secondary nodes
  • The master node
Start command: redis-server redis-7000.conf
Copy the code

configuration

port 7000
daemonize yes
pidfile /var/run/redis-7000.pid
logfile "7000.log"
dir "/opt/soft/redis/data/"
Copy the code
  • Redis slave node
redis-server redis-7001.conf
redis-server redis-7002.conf
Copy the code

slave-1:

port 7002
daemonize yes
pidfile /var/run/redis-7002.pid
logfile "7002.log"
dir "/opt/soft/redis/data/"
slaveof 127.0. 01. 7000
Copy the code

slave-2:

port 7001
daemonize yes
pidfile /var/run/redis-7001.pid
logfile "7001.log"
dir "/opt/soft/redis/data/"
slaveof 127.0. 01. 7000


Copy the code
  1. Enable sentinel to monitor the primary node
  • Sentine main configuration edit sentinel.conf
port ${port}
dir "/opt/soft/redis/data/"
logfile "${port}.log"
192.168.11.128 represents the monitored primary server. 6379 represents the port. 2 represents the time when only two or more sentinels consider the primary server to be unavailable. A failover is performed.
sentinel monitor mymaster 127.0. 01. 7000 2   
sentinel down-after-millseseconds mymaster 30000 // Determine the time of the primary node
sentinel parallel-syncs mymaster 1    
sentinel failover-timeout mymaster 180000

Copy the code

Start the

redis-sentinel sentinel.conf
Copy the code

You can use the ps – ef | grep redis – sentinel command to check the process,

Four, implementation principle

  • Failover – Java implementation
/** * Test Redis Sentinel mode *@author liu
 */
public class TestSentinels {
    @SuppressWarnings("resource")
    @Test
    public void testSentinel(a) {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(10);
        jedisPoolConfig.setMaxIdle(5);
        jedisPoolConfig.setMinIdle(5);
        // Sentry information
        Set<String> sentinels = new HashSet<>(Arrays.asList("127.0.0.1:26379"."1127.0.0.1:26379"."127.0.0.1:26379"));
        // Create a connection pool
        JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels,jedisPoolConfig,"123456");
        // Get the client
        Jedis jedis = pool.getResource();
        // Execute two commands
        jedis.set("mykey"."myvalue");
        String value = jedis.get("mykey"); System.out.println(value); }}Copy the code

If we take the primary server down, the Redis cluster will recover after a period of error reporting

  • Subjective and objective logoff

    • Subjective offline: The current Sentintel node considers a Redis node unavailable.

    • Objective offline: All Sentinel nodes consider a redis node unavailable.

  • Three scheduled Tasks

  1. Info is executed for master and slave every 10 seconds per sentinel

    - Discover the slave node. - Confirm the master/slave relationshipCopy the code

  2. Every 2 seconds each Sentinel exchanges information to a channel through the master node (publish subscription)

    - Interaction via _sentinel_: Hello channel - Exchanging "views" on nodes and information about themselvesCopy the code

  3. Every 1 second each sentinel pings other Sentinels and Redis

  • Leadership election

    • Only one Sentinel node is required for failover

    • The sentinel IS-master-down-by-addr command is used to become a leader

      -1. Each subjective downline Sentitle node sends commands to other Sentinel nodes asking it to be set as leader -2. Received command on Sentinel node if there is no same command sent through other Sentinel nodes, then the same request will be rejected, otherwise -3. If the Sentinel node finds that the direct number of votes exceeds half of the Sentinel set and exceeds quorum, then it becomes the leader -4. If this process is led by multiple Sentinel nodes, then the election will be re-run after a certain period of timeCopy the code

  • Failover (Sentinel Leader node completed)

    • 1. Select a suitable node from the slave nodes as the master node
    • 2. Run the slaveof no one command on the slave node to make it the master node.
    • 3. Send commands to the remaining slave nodes to make them the slave nodes of the new Maater node. Replication avoidance is related to the parallel syncs parameter
    • 4. Update the original master node as slave and keep “attention” on it. When it recovers, command it to copy the new master node

  • Select the “appropriate” slave node

    • 1. Set slave-priority (priority of the slave node) to the highest. If the slave node exists, the system returns the priority
    • 2. Select the slave node with the largest replication offset to achieve the most complete replication
    • 3. Select the slave node with the smallest runId

Five, the need to explain the problem

  • Deploy all nodes of Redis Sentinel on different physical machines and the same network as possible
  • The number of sentinel nodes in Redis Sentinel should be greater than or equal to 3 and preferably odd. (A large number of nodes ensures high availability.)
  • Data nodes in Redis Sentinel are no different from regular data nodes. Each Sentinel node is essentially a Redis instance, but unlike the Redis data node, its main function is to monitor the Redis data node
  • The client is initialized to connect to a collection of Sentinel nodes, not a specific Redis node, but sentinel is only a configuration center, not a proxy.

Personal blog: blog.yanxiaolu.cn /