Shulou(Shulou.com)06/02 Report--

Redis High availability principle:

Redis uses sentinel mechanism to achieve high availability. Sentinel is another cluster, which is mainly used to monitor all Redis servers, all redis master nodes and redis slave nodes. The monitoring method uses ping instructions. Sentinel sends [ping] to master every 1 second. If you do not receive [pong] or receive an invalid reply within a period of time, master is considered offline.

Sentinel has two definitions of offline:

a. Subjective referral (sdown): the judgment of the sentinel instance to the service instance

b. Objective offline (odown): when multiple sentinel instances make a negotiated judgment on the status of the same service SDOWN, only master can be in odown status.

To put it simply, the judgment made by a sentinel alone can only be sdown, which does not have any official effect. Only when multiple sentinel are agreed and agreed, can a certain master state be set from sdown to odown. Only after determining the transition from master state to odown state can follow-up failover operations be done.

Sentinel can monitor the entire master-slave replication architecture. All you have to do is tell sentinel who is the master server. It will send info instructions from the master server, that is, to the master server, to know which slave servers are under this master server. If it is found that the master server is offline, it will automatically elect a new master node from one of the slave servers under the master server, so the master node connected to the slave node before is the original master. What if the original master node is gone? sentinel tells the client who the new master is, and sends slaveof to the client to specify that the slave node reselect the master node.

What if the sentinel cannot connect to the master node or the sentinel itself fails, so sentinel needs to do a cluster. Each node in the cluster determines whether the redis node is down.

The role of Sentinel is to manage multiple redis services to implement HA

Monitoring: Sentinel will constantly check whether your master server and slave server are working properly.

Notification: when there is a problem with a monitored Redis server, Sentinel can send a notification to the administrator or other application through API.

Automatic failover: when a master server does not work properly, Sentinel starts an automatic failover operation, which upgrades one of the slaves of the failed master server to the new master server and allows the other slaves of the failed master server to replicate the new master server When the client tries to connect to the failed primary server, the cluster also returns the address of the new primary server to the client, so that the cluster can use the new primary server instead of the failed server.

Using the gossip protocol, the voting protocol.

Startup of sentinel

There are two ways to start:

# start through the sentinel parameter of redis-server: redis-servier / etc/sentinel.conf-- sentinel# starts through the redis-sentinel command: redis-sentinel / etc/sentinel.conf

Sentinel depends on the configuration file, and it must keep its own state information with the configuration file.

There are several steps to start a sentinel:

The server initializes itself.

Run the code dedicated to the sentinel function in redis-server to initialize the sentinel state and initialize the list of monitored master servers based on the given configuration file to create a connection to the master. The sentinel dedicated configuration file parses # sentinel.conf as its dedicated configuration file, and mainly sets the following parameters: # default Port port 26379 # specifies that the master,mymaster to be monitored is the defined master name, and quorum is the legal number of votes 2, which refers to the number of sentinel. The decision made by sentinel is considered valid only when the specified sentinel agrees, which is generally more than half of the number of sentinel. There can be multiple master, and a group of sentinel clusters can monitor N master-slave replication architecture sentinel monitor mymaster 127.0.0.1 6379 2 # specify at least how long the redis master password sentinel auth-pass mymaster redis # to be connected can not be connected before the master is offline. Unit is ms, that is, the connection timeout period sentinel down-after-milliseconds mymaster 30000 # has just been set as the new master, and how many slaves are allowed to initiate synchronization requests to the master at the same time. Sentinel parallel-syncs 1 # when master fails, the new slave is promoted to master, and the failover is considered to have failed for as long as it takes. Sentinel failover-timeout mymaster 180000 # timeout for failover sentinel special command: sentinel masters # get all monitored mastersentinel slaves # list all slave nodes of the master sentinel get-master-addr-by-name # get the address sentinel reset # reset all according to the master name, start from scratch sentinel failover # manual failover, and indicate which group of master to initiate a manual Redis high availability configuration example

Redis version: 3.2.2

One master and two followers:

Master: 10.3.1.15 6379

From: 10.3.1.15 6378

From: 10.3.1.15 6376

A Sentinel:10.3.1.17

Add slaveof to the redis.conf of each slave node to become a master-slave relationship: slaveof

Bind snooping in the redis.conf configuration file if there is more than one IP, put the native IP first and the loopback address last, because redis usually uses the first IP to communicate with the master.

Connect to the master server to view: # you can see that the master-slave relationship has been normal 127.0.0.1 6379 > INFO replication# Replicationrole:masterconnected_slaves:2slave0:ip=10.3.1.15,port=6378,state=online,offset=5204,lag=1slave1:ip=10.3.1.15,port=6376,state=online,offset=5204,lag=1master_repl_offset:5218repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:5217127.0.0.1:6379 > configure sentinel.conf

The configuration parameters for sentinel.conf are described above. Start sentinel# at the foreground to launch sentinel. / bin/redis-sentinel / data/service/redis/sentinel.conf 18844 Mar 23 Mar 18844 Mar 34. 053 * Increased maximum number of open files to 10032 (it was originally set to 1024). .18844: X 23 Mar 18:34:58.054 # WARNING: The TCP backlog setting of 511 cannot be enforced because / proc/sys/net/core/somaxconn is set to the lower value of 128. 18844 Mar X 23 Mar 18 Mar 34R 58.056 # Sentinel ID is 524c94beed78f379e4a0b3b641992449b0cdcf7f 18844 monitor master mymaster 10.3.1.15 6379 quorum 2 18844 quorum 2 18844 quorum 218844 quorum 2 18844 quorum 2 18844 .3.1.15 6379 # Startup completed You can see from the console that sentinel has found master and slave.

Here's how to connect to sentinel to view master information:

Root@ubuntu17:$ redis-cli-h 10.3.1.17-p 26379 10.3.1.17 no bind address was specified > info DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the'--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.

As above, enter info and report an error that redis is working in protected mode and is turned off by 'CONFIG SET protected-mode no, because the default protected-mode is yes.

So add this sentence to all redis, that is, one master and two slaves, and then enter sentinel and enter info, and still report this error, so try to add this sentence to the sentinel.conf file of sentinel itself, save and restart sentinel, and then execute info not to report an error.

Verification of deployment success: # shows normal 10.3.1.17 26379 > INFO # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=10.3.1.15:6379,slaves=2 Sentinels=1 10.3.1.17 sentinels=1 26379 > # get the redis master server information monitored by sentinel 10.3.1.17 redis master 26379 > sentinel masters 1) 1) "name" 2) "mymaster" 3) "ip" 4) "10.3.1.15" 5) "port" 6) "6379" 7) "runid" 8) "3520e56cadc7a3cd591da0094199d46a83771318" 9) "flags" 10) "master" 11) "link-pending-commands" 12) "0" 13) "link-refcount" 14) "1" 15) "last-ping-sent" 16) "0" 17) "last-ok-ping-reply" 18) "697" 19) "last-ping-reply" 20) "697" 21) "down-after -milliseconds "22)" 30000 "High availability Verification:

When the master master is disabled, the detailed failover process can be seen in the sentinel console: 62360 Mar X 24 Mar 13 master 053.197 # + sdown master mymaster 10.3.1.15 6379 # subjectively think that master has failed 62360 Mar X 24 master 13 master 53.197 # + odown master mymaster 10.3.1.15 # quorum 1 # 1 # objectively believes that master has failed 62360 Mar X 24 Mar 13 new-epoch 06race 07.965 # + new-epoch 13 # ready to enter the new era of master The 13th election. 62360 Mar X 24 Mar 13 master 06V 07.965 # + try-failover master mymaster 10.3.1.15 6379 # attempt to transfer master 62360 master 62360 master X 24 Mar 13 # Vol 07.967 # + vote-for-leader 9cf767f451de09136054ccc6afc6dcc5f939b5a0 13 # vote for master 62360 master 62360 master X 24 Mar 13 # vote for master 62360 master 62360 master X 24 Mar 13 # 07.967 # + elected-leader master mymaster 10.3.1.15 6379 # previously elected .3.1.15 6379 # Leader start select suitable master 62360 master X 24 Mar 13 master 06RV 08.034 # + selected-slave slave 10.3.1.15 master 6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 # We have found a suitable one from 10.3.1.15 to 6376 mainly 62360 Mar X 1306Rose 08.034 * + failover-state-send-slaveof-noone slave 10.3.1.15Rd 6376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 # Leader sends "slaveof no one" instruction to slave At this time, slave has completed the role conversion. This slave is master 62360 Mar 24 Mar 13 Mar 06slave 0893 * + failover-state-wait-promotion slave 10.3.1.15 mymaster 10.3.1.15 6376 @ mymaster 10.3.1.15 # waiting for other sentinel to confirm the success of slave 62360 Mar X 24 Mar 06lav 09.116 # + promoted-slave slave 10.3.1.156376 10.3.1.15 6376 @ mymaster 10.3.1.15 6379 # confirm success 62360 Mar X 24 Mar 13:06: 09.116 # + failover-state-reconf-slaves master mymaster 10.3.1.15 6379 # start reconfig operation on slaves 62360 reconfig X 24 Mar 13 reconfig 09.176 * + slave-reconf-sent slave 10.3.1.15 reconfig 6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 # send the "slaveof" instruction to the specified slave Tell this slave to follow the new master 62360 Mar X 24 Mar 06 slave 10.132 * + slave-reconf-inprog slave 10.3.1.15 6378 10.3.1.15 6378 @ mymaster 10.3.1.15 6379 to start the reconfig operation on slaves

Then go to sentinel to view the new master:

10.3.1.17 sentinel masters 26379 > sentinel masters # you can see that master has changed 1) 1) "name" 2) "mymaster" 3) "ip" 4) "10.3.1.15" 5) "port" 6) "6376" 7) "runid"

Go back to one of the slave nodes to view:

10.3.1.15 config get slaveof 6378 > slaveof 1) "slaveof" 2) "10.3.1.15 6376" 10.3.1.15 6378 >

Now start the original master 6379 and see if it is master or slave:

10.3.1.15master 6379 > config get slaveof 1) "slaveof" 2) "10.3.1.15 6376" # the original master is now a slave node

Now check out the newly elected master:

10.3.1.15 6376 > info replication# Replicationrole:masterconnected_slaves:2slave0:ip=10.3.1.15,port=6379,state=online,offset=707098,lag=1slave1:ip=10.3.1.15,port=6379,state=online,offset=707013,lag=1master_repl_offset:707098repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:70709710.3.1.15:6376 >

The above is Redis sentinel is a highly available feature, the application should send a request to sentinel to find the address of the new Master, then use the redis special program to contact the new server according to sentinel feedback.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.