Redis Learning Note (4)-ha Highly available scenario Sentinel configuration

Http://www.cnblogs.com/yjmyzz/p/redis-sentinel-sample.html

The Master-slave mode is described in the previous section, where the "full" read/write functionality will be affected in the case of a minimum configuration: master, slave each node, either master or slave down, which is obviously unacceptable in the production environment. Fortunately, Redis provides Sentinel (Sentinel) mechanism to automatically monitor the running state of Master/slave after launching Redis through Sentinel mode, the basic principle is: heartbeat mechanism + voting verdict

Each Sentinel sends a message to other sentinal, master, and slave periodically to confirm that the other person is "alive", and if it finds that the other person has not responded within a specified time (configurable), it is temporarily considered to have been hung (so-called "subjective view of the outage" subjective down , referred to as Sdown).

If most Sentinel in Sentinel group reports that a master is not responding, the system considers the master to be "completely dead" (i.e.: objective real down machine, Objective down, abbreviation Odown), through a certain vote algorithm, From the remaining slave nodes, select one to master and then automatically modify the related configuration.

The minimized sentinel configuration file is:

1 Port 7031
2 
3 dir/opt/app/redis/redis-2.8.17/tmp
4 
5 Sentinel Monitor MyMaster 10.6.144.155 7030 1
  6 Sentinel Down-after-milliseconds mymaster
7 Sentinel Parallel-syncs MyMaster 1
8 Sentinel Failover-timeout MyMaster 15000

Line 1th, specify the port that Sentinel uses and cannot conflict with the port of the Redis-server running instance

Line 3rd, specifying the working directory

Line 5th, display the Monitoring master node 10.6.144.155,master node using port 7030, the last number represents the "minimum quorum" required for voting, for example, 10 Sentinal Sentinel are monitoring a master node, If you need at least 6 sentinels to find that master hangs up, then the master really down, then this is configured to 6, the minimum configuration of 1 master,1 slave, on two machines are started Sentinal case, the Sentinel number only 2, if a machine physically hung off , there is only one sentinal can find the problem, so this is configured to 1, as for MyMaster is just a name, can be casually up, but to ensure that 5-8 lines are used the same name

The 6th line indicates that if MyMaster is not responding within 5s, it is considered sdown

The 8th line indicates that if Mysater is still not alive after 15 seconds, start failover and select one from the remaining slave to upgrade to master.

The 7th line, that is, if master is re-elected, the other slave nodes can simultaneously parallel the number of simultaneous cache from the new master, it is clear that the larger the value, all the slave nodes to complete the synchronization of the overall speed, the faster, but if someone is accessing these slave at this time, May cause read failures and affect polygons more broadly. The most Baoding setting is 1, only the same time, only one can do this thing, so that other slave can continue to service, but all slave complete cache update synchronization process will be slow.

Another: A sentinal can monitor multiple master at the same time, as long as the 5-8 lines to repeat multiple paragraphs, to be modified.

Specific Use steps: (Convention 7030 is Redis-server port, 7031 is Redis-sentinel port, and redis-server on master and slave have started normally)

1, first create the Conf subdirectory under the Redis root directory, the new configuration file sentinel.conf, the content reference previous content (both master and slave do the same configuration)

2./redis-sentinel. /conf/sentinel.conf (Sentinel is enabled on both master and slave, i.e. there are two sentinels at the end)

3./redis-cli-p 7031 Sentinel Masters This command to view the current master node (note, this must be the port with Sentinel)

4, on Master,./redis-cli-p 7030 shutdown, manually stop master and observe Sentinel's output

[17569] Nov 11:06:56.277 # +odown Master mymaster 10.6.144.155 7030 #quorum 1/1
[17569] 11:06:56.277 # Next failover delay:i would not start a failover before Fri Nov 21 11:07:26 2014
[17569] Nov 11:06:57.389 # +config-update-from Sentinel 10.6.144.156:7031 10.6.144.156 7031 @ mymaster 10.6.144.155 703 0
[17569] 11:06:57.389 # +switch-master MyMaster 10.6.144.155 7030 10.6.144.156 7030
[17569] 11:06:57.389 * +slave slave 10.6.53.131:7030 10.6.53.131 7030 @ mymaster 10.6.144.156 7030

As can be seen from the Red Line section, master has been migrated, and so on after the shutdown of the master and restart, you can observe that it will be added as slave, similar to the following output:

[36444] 11:11:14.540 * +convert-to-slave slave 10.6.144.155:7030 10.6.144.155 7030 @ mymaster 10.6.144.156 7030

Note: After the master migration occurs, if you encounter operational needs and want to restart all Redis, you must first restart the "new" Master node, or Sentinel will never find master.

Finally, if you want to stop Sentinel, you can enter a command./redis-cli-p 7031 shutdown

Use of the client:

First, Jedis View Code

The 4-6 row is the key, and sentinel node information is specified here. However, this code found a problem at run time: for the 1 Master 1 from the minimum configuration, if a continuous two write operations, after the 1th set succeeds, if the breakpoint stops here, down the master, then the remaining slave will be promoted to master, but the 2nd time set, will throw an exception, Similar to: The connection has been disconnected. (Note: When integrating Jedis and Redis with Spring-data-redis, there is no problem with redistemplate calls and it seems that Spring-data-redis has been optimized for this issue, so it is recommended that the formal project Use Spring-data-redis to integrate Redis to invoke related functions instead of referencing Jedis's jar packages directly.

Second, Redisson View Code

Similarly do similar tests, two write, two reads, if the 1th time after writing, manually down the master, the remaining slave will be promoted to master, the second write OK, but at this time Redis node, only master, no slave, from the test results, see, The second get or try to find the slave node, but there is no longer exist, so has been waiting, resulting in the subsequent processing is blocked.

This is not the problem with Redis, but the Redisson client design is not smart enough.

In view of this situation, if you want to use Redisson, it is best to make 1 main 2 from the deployment structure: (sentinel.conf in the "quorum", the proposed adjustment to 2)

The advantage is that 1 master hangs, the remaining 2 slave, there will be 1 upgrade to master, the overall still guaranteed to have 1 master and a Slave, read and write are unaffected.

For more details on Sentinel, refer to the official website documentation: Http://www.redis.io/topics/sentinel