Redis Learning Notes (4)-ha high-availability Scenarios 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 feature will be affected, in the case of a minimum configuration: master, slave each node, which is obviously unacceptable in a production environment. Fortunately Redis provides a Sentinel (Sentinel) mechanism, Sentinel mode to start Redis, automatically monitor the operation of Master/slave, the basic principle is: heartbeat mechanism + voting decision

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

If the "Sentinel group" in most of the Sentinel, reported that a master did not respond to the system to think that the master "complete Death" (ie: the objective of the real down machine, objective down, referred to as Odown), through a certain vote algorithm, From the remaining slave node, select one to master and automatically modify the associated 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 5000
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 where Redis-server runs the instance

Line 3rd, specify the working directory

Line 5th, which shows that the monitor master node 10.6.144.155,master node uses port 7030, and the last number represents the "minimum quorum" required for the poll, for example, 10 Sentinal sentinels are monitoring a master node, If you need at least 6 sentinels to find master hang up, then think Master really down, then this is configured to 6, the minimum configuration of 1 master,1 Taiwan Slave, on two machines are all started sentinal, the number of Sentinels only 2, if a machine physically hung , there is only one sentinal can find the problem, so it is configured to 1, as MyMaster is just a name, you can start casually, but to ensure that 5-8 lines are using the same name

Line 6th indicates that if the MyMaster in 5s is not responding, it is considered that Sdown

Line 8th, which means that if the mysater still does not come alive after 15 seconds, start the failover and select one of the remaining slave to upgrade to master

Line 7th, which indicates how many other slave nodes can synchronize the cache from the new master at the same time if Master is selected, and the larger the value, the faster the overall speed of the sync switch for all slave nodes, but if someone is accessing these slave at this point, May cause the read to fail, the influence face will be more extensive. The most Baoding setting is 1, at the same time, only one can do this, so other slave can continue to service, but all slave complete the cache update synchronization process will slow down.

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

Specific Use steps: (The Convention 7030 is the Redis-server port, 7031 is the Redis-sentinel port, and the master, slave Redis-server has been started normally)

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

2./redis-sentinel. /conf/sentinel.conf (both master and slave are enabled Sentinel, which eventually has two Sentinels)

3./redis-cli-p 7031 Sentinel Masters This command allows you to view the current master node situation (note that you must take the Sentinel port here)

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

[17569] Nov 11:06:56.277 # +odown Master mymaster 10.6.144.155 7030 #quorum 1/1
[17569] Nov 11:06:56.277 # Next failover delay:i'll 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] Nov 11:06:57.389 # +switch-master MyMaster 10.6.144.155 7030 10.6.144.156 7030
[17569] Nov 11:06:57.389 * +slave slave 10.6.53.131:7030 10.6.53.131 7030 @ mymaster 10.6.144.156 7030

As you can see from the Red section, Master has migrated, and when the master that has just stopped is restarted, it can be observed that it will be added as a slave, similar to the following output:

[36444] Nov 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 master migration, if you encounter operational requirements, want to restart all Redis, you must first restart the "new" Master node, otherwise Sentinel will not be able to 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

Line 4-6 is the key, where the sentinel node information is specified. But this code found a problem at run time: for 1 master 1 from the minimum configuration, if two consecutive write operations occur, after the 1th set succeeds, if the breakpoint is stopped here, down the master, then the remaining slave will be promoted to master, but the 2nd time set, will throw an exception, Similar: the connection is disconnected. (Note: When Jedis and Redis are integrated through Spring-data-redis, there is no such problem with redistemplate calls, and it appears that Spring-data-redis has optimized the issue, so it is recommended that the formal project Invoke the relevant functionality through the Spring-data-redis consolidation Redis instead of directly referencing the Jedis jar package for use)

Second, Redisson View Code

Similarly do similar tests, two times, two read, if the 1th time after the manual down master, the remaining slave will be upgraded to master, the second write OK, but at this time Redis node, only master, there is no slave, from the test results to see, The second get is still trying to find the slave node, but this time no longer exists, so has been waiting, causing the subsequent processing is blocked.

This is not a redis problem, but Redisson client design is not smart enough.

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

The advantage of this is that, after 1 master hangs, the remaining 2 slave will have 1 upgraded to master, and the overall guarantee has 1 master and one slave, and neither read nor write is affected.

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