Redis ha High-availability scenarios Sentinel and Shard

1, build Redis-master, Redis-slave and Seninel Sentinel monitoring

In the case of a minimum configuration: master, slave each node, either master or slave down one, the "full" read/write functionality will be affected, 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 node, select one to master and then automatically modify the relevant configuration

The minimized sentinel configuration file is:

[HTML]View PlainCopy print?

1. 1 Port 26389
2. 2
3. 3 dir./tmp
4. 4
5. 5 Sentinel Monitor MyMaster 127.0.0.1 6379 1
6. 6 Sentinel Down-after-milliseconds MyMaster 5000
7. 7 Sentinel Parallel-syncs MyMaster 1
8. 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.

Each start the Redis master and Sentinal Sentinel to see the Redis master

./redis-cli-p 26389 Sentinel Masters This command to view the current master node condition

Simulates when master hangs, whether slave switch is master.

The switch succeeds, will hang up the master to start up, whether the redis is changing to slave.

2, Sentinel and Shard Redis guarantee high availability of redis clusters.

Sentinel&jedis looks like a perfect solution, which is only half right, in the case of non-sharding, but our application uses data sharding-sharing, the data is distributed evenly across 4 different instances, each of which is deployed in a master-slave structure, Jedis does not provide Sentinel-based Shardedjedispool, meaning that in 4 shards, if one of the shards has a master-slave switchover, the shardedjedispool used by the application cannot be notified, and all operations on that Shard will fail.
This article provides a Sentinel-based shardedjedispool that can sense all of the Shard master-slave switching behavior in a timely manner, for connection pool reconstruction ....

3\ Monitoring:

At present, the monitoring for Redis is relatively rare, mainly redis-live, Dredis and so on. However, these tools are more critical to redis performance and are difficult to monitor in real time.

Redis monitoring can be easily divided into security monitoring and performance monitoring. Security monitoring can determine the status of master and slave through the Redissentinel output log, and performance monitoring requires the performance parameters of the Redis to be collected for evaluation. So there is no conflict between the two, and the shell script allows for lightweight monitoring, with the disadvantage of having no visual real-time charts.

1. Safety monitoring

Redis Sentinel's output logs are concise and informative, including the real-time status of Redis, failover times, and the status of Sentinel itself, with detailed documentation for troubleshooting. Through Sentinel log mining, find fault time to timely alarm, and notify the administrator.

Because Sentinel does not enable logging by default, you can log logs by using the following methods:

To start the input log:

Src/redis-sentinel sentinel.conf >>sentinel.log &

Redis ha High-availability scenarios Sentinel and Shard