Redis Master-Slave cluster description and configuration

The architecture diagram is as follows:

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M00/7F/97/wKiom1cjPE-jZb1QAADi_DezMAw835.png "title=" Redis.png "alt=" Wkiom1cjpe-jzb1qaadi_dezmaw835.png "/>

1.sentinel description

(1) Monitoring (monitoring): Sentinel will constantly check whether your primary server and slave server are functioning properly.

(2) Reminder (Notification): Sentinel can send notifications to administrators or other applications through the API when a problem occurs with a Redis server being monitored.

(3) automatic failover (Automatic failover): When a primary server fails, Sentinel starts an automatic failover operation that upgrades one of the failed primary servers from the server to the new primary server. And let the other server from the failed master to replicate the new primary server, when the client tries to connect to the failed primary server, the cluster will also return 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.

Redis Sentinel is a distributed system that allows you to run multiple Sentinel processes (progress) in one architecture that uses the gossip protocol (gossip protocols) to receive information about whether the primary server is offline, The Voting Protocol (agreement protocols) is used to determine whether automatic failover is performed and which slave server is selected as the new primary server.

2.redis Master-Slave synchronization principle

(1) The slave server is connected to the master server.

(2) The slave server sends the SYCN command.

(3) The master server backs up the database to an. rdb file.

(4) The master server transmits the. rdb file to the slave server.

(5) The slave server imports the. rdb file data into the database.

3. Architecture Planning

master:10.1.1.8:6379

salve1:10.1.1.11:6379

salve2:10.1.1.12:6379

salve3:10.1.1.13:6379

sentinel:10.1.1.11:26379

sentinel:10.1.1.12:26379

sentinel:10.1.1.13:26379

4. master-Slave configuration

Installing Redis Skip

3.1. Configure Master-Slave

Configuration master:

master:10.1.1.8

vim /etc/redis.confdaemonize yes  //daemon pidfile  "/var/run/redis.conf.pid"    PID Path port 6379   //Listener port bind 0.0.0.0  //bind address timeout 300  // Time-out loglevel notice //log level logfile  "/data/redis/redis-server.log"  //log path databases 16   //number of instances save 900 1  //900 seconds with 1 changes write disk save 300 10  // 300 seconds has 10 changes write disk SAVE 60 10000 //60 seconds has 10,000 changes write disk rdbcompression yes  // Supports RDB compression dbfilename  "Dump.rdb"  //db file name dir  "/data/redis/lib"  //rdb path Slave-serve-stale-data  yes  //if  slave-serve-stale-data  is set to   ' Yes '   (The default)   Slave will still respond to client requests, and there may be a problem. Appendonly no  //aof off appendfsync everysec  //write disk once per second No-appendfsync-on-rewrite Automatic rewriting of  no //append only  files,  Redis can be called bgrewriteaof  when the aof  log file is about to grow to a specified percentage From the rewrite append only file. List-max-ziplist-entries 512 list-max-ziplist-value 64 //if the number of integral elements in set does not exceed 512, Redis will use this special encoding set-max-intset-entries 512activerehashing yes //to specify whether to activate the reset hash, which is turned on by default to masterauth  " 456789 " //Certified password requirepass " 456789 "

Configuration slave1:

salve1:10.1.1.11:6379

Daemonize yespidfile "/var/run/redis/redis-server.pid" Port 6379bind 0.0.0.0timeout 300loglevel noticelogfile "/data/ Redis/redis-server.log "Databases 16save 1save 10save 10000rdbcompression yesdbfilename" Dump.rdb "dir"/data/ Redis/lib "Slave-serve-stale-data yesappendonly noappendfsync Everysecno-appendfsync-on-rewrite Nolist-max-ziplist-entries 512list-max-ziplist-value 64set-max-intset-entries 512activerehashing Yesmasterauth " 456789 "Requirepass" 456789 "slaveof 10.1.1.8 6379

Configuration salve2:

salve1:10.1.1.12:6379

Configuration consistent with Slave1

Configuration salve3:

salve1:10.1.1.13:6379

Configuration consistent with Slave1

4. Start the process

Start master:10.1.1.8:

/usr/local/bin/redis-server/etc/redis.conf

Start salve1:10.1.1.11:6379

/usr/local/bin/redis-server/etc/redis.conf

Start salve2:10.1.1.12:6379

/usr/local/bin/redis-server/etc/redis.conf

Start salve3:10.1.1.13:6379

/usr/local/bin/redis-server/etc/redis.conf

To view the Master log:

Cat /data/redis/redis-server.log .... 16337:m 29 apr 16:40:00.335 * db loaded from disk: 0.000  Seconds16337:m 29 apr 16:40:00.335 * the server is now ready  to accept connections on port 637916337:m 29 apr 16:40:14.757  * Slave 10.1.1.11:6379 asks for synchronization16337:M 29 Apr  16:40:14.757 * full resync requested by slave 10.1.1.11:637916337:m 29  Apr 16:40:14.757 * Starting BGSAVE for SYNC with target:  disk16337:m 29 apr 16:40:14.757 * background saving started by  Pid 1634616346:c 29 apr 16:40:14.765 * db saved on disk16346:c  29 apr 16:40:14.766 * rdb: 6 mb of memory used by copy-on-write16337:m 29 apr 16:40:14.864 * background saving  terminated with success16337:m 29 apr 16:40:14.864 * synchronization  with slave 10.1.1.11:6379 succeeded //salve1  Synchronous ok16337:m 29 apr  16:40:33.200 * slave 10.1.1.12:6379 asks for synchronization16337:m 29  Apr 16:40:33.200 * Full resync requested by slave  10.1.1.12:637916337:m 29 apr 16:40:33.200 * starting bgsave for sync  with target: disk16337:m 29 apr 16:40:33.201 * background saving  started by pid 1634716347:c 29 apr 16:40:33.219 * db saved  on disk16347:C 29 Apr 16:40:33.220 * RDB: 6 MB of  Memory used by copy-on-write16337:m 29 apr 16:40:33.308 * background saving terminated with  success16337:m 29 apr 16:40:33.308 * synchronization with slave  10.1.1.12:6379 succeeded //salve2  Synchronous ok16337:m 29 apr 16:40:35.257 *  slave 10.1.1.13:6379 asks for synchronization16337:m 29 apr 16:40:35.257  * full resync requested by slave 10.1.1.13:637916337:m 29 apr  16:40:35.258 * starting bgsave for sync with target: disk16337:m  29 Apr 16:40:35.260 * Background saving started by pid  1634816348:c 29 apr 16:40:35.274 * db saved on disk16348:c 29  Apr 16:40:35.275 * RDB: 8 MB of memory used by  copy-on-write16337:m 29 apr 16:40:35.315 * background saving terminated with success16337:m 29  apr 16:40:35.315 * synchronization with slave 10.1.1.13:6379 succeeded  //salve3  Sync OK

Log in to master to view synchronization information:

127.0.0.1:6379> info....# Replicationrole:master//Role not master Connected_slaves:3//3 slave Resolve slave0:ip=10.1.1.11,port= 6379,state=online,offset=71,lag=1//salve1 Information slave1:ip=10.1.1.12,port=6379,state=online,offset=71,lag=1// Slave2 Information slave2:ip=10.1.1.13,port=6379,state=online,offset=71,lag=1//slave3 information master_repl_offset:71//copy offset Repl_ Backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:70 ....

5. Test Master and Slave:

The Lord Inserts the data:

#/usr/local/bin/redis-cli 127.0.0.1:6379> Set name "Ckl" OK

SALVE1 View:

127.0.0.1:6379> Get Name "Ckl" 127.0.0.1:6379>

Salve2 View:

127.0.0.1:6379> Get Name "Ckl" 127.0.0.1:6379>

Salve3 View:

127.0.0.1:6379> Get Name "Ckl" 127.0.0.1:6379>

6. Configure Sentinel

Configuration sentinel:10.1.1.11:26379:

Port 26379 daemonize Yes Sentinel monitor Ckl_master 10.1.1.12 6379 2 Sentinel failover-timeout ckl_master 900000 senti Nel auth-pass ckl_master 456789 Sentinel Config-epoch ckl_master 1 Sentinel leader-epoch ckl_master 1 logfile "/data/re Dis/sentinel.log "

Configuration file Explanation:

Port 26379 #指定启动的端口daemonize Yes #后台守护进程启动sentinel the master node of the monitor Ckl_master 10.1.1.12 6379 2 #让sentinel去监控名称为ckl_master, The IP is 10.1.1.8 Port 6379 when two Sentinel detects a failure before performing a toggle Sentinel failover-timeout ckl_master 900000 #sentinel判断master断开时间, The default is Ms Sentinel Auth-pass ckl_master 456789 #设置认证密码sentinel config-epoch ckl_master 1 #从节点由于故障转移事件被提升为主节点时, in order to replace its failed master node, Will set Configepoch to the Configepoch value when it wins the election. LogFile "/data/redis/sentinel.log" #指定日志路径

Configuration sentine2:10.1.1.12:26379:

Consistent with Sentinel configuration

Configuration sentine3:10.1.1.13:26379:

Consistent with Sentinel configuration

7. Launch Sentinel

Start sentine1:10.1.1.11:26379:

/usr/local/bin/redis-sentinel/etc/sentinel.conf

Start sentine2:10.1.1.12:26379:

/usr/local/bin/redis-sentinel/etc/sentinel.conf

Start sentine3:10.1.1.13:26379:

/usr/local/bin/redis-sentinel/etc/sentinel.conf

To view a process:

# Ps-ef |        grep redisroot 11360 1 0 16:40?        00:00:03/usr/local/bin/redis-server 0.0.0.0:6379 root 11437 1 0 18:06? 00:00:00/usr/local/bin/redis-sentinel *:26379 root 11443 11306 0 18:07 pts/1 00:00:00 grep redis

To view the Sentinel logs:

... [11501] 29 apr 18:06:23.656 # sentinel runid is  2535af9a6926391270af19cb872c93a1cd499ea9[11501] 29 apr 18:06:23.656 # +monitor  master ckl_master 10.1.1.8 6379 quorum 2[11501] 29 apr 18:06:23.657  * +slave slave 10.1.1.11:6379 10.1.1.11 6379 @ ckl_master  10.1.1.8 6379 //SALVE1 information of the same Lord [11501] 29 apr 18:06:23.704 * +slave slave  10.1.1.12:6379 10.1.1.12 6379 @ ckl_master 10.1.1.8 6379 // Salve2 information [11501] 29 apr 18:06:23.711 * +slave slave 10.1.1.13:6379  with the Lord 10.1.1.13 6379 @ ckl_master 10.1.1.8 6379 //salve3 information of the same Lord [11501] 29 APR  18:06:23.973 * +sentinel sentinel 10.1.1.12:26379 10.1.1.12 26379 @  ckl_master 10.1.1.8 6379[11501] 29 apr 18:06:25.133 * +sentinel sentinel 10.1.1.11:26379 10.1.1.11  26379 @ ckl_master 10.1.1.8 6379 ...

The Sentinel configuration file has been found to have changed, adding the following:

# Generated by CONFIG Rewritedir "/home/chenkangle" Sentinel Known-slave ckl_master 10.1.1.13 6379 Sentinel Known-slave Ckl _master 10.1.1.11 6379sentinel known-slave ckl_master 10.1.1.12 6379sentinel known-sentinel ckl_master 10.1.1.12 26379 3f Eafdc8dd9dd92bc01034ce2d059db517c2feeesentinel Known-sentinel ckl_master 10.1.1.13 26379 2535af9a6926391270af19cb872c93a1cd499ea9sentinel Current-epoch 1

Log in to one of 3 Sentinel viewing information:

#/usr/local/bin/redis-cli-p 26379 127.0.0.1:26379> info......# sentinelsentinel_masters:1sentinel_tilt:0 sentinel_running_scripts:0sentinel_scripts_queue_length:0master0:name=qm_master,status=ok,address= 10.1.1.8:6379,slaves=3,sentinels=3 ....

8.sentinel detection of main node offline principle

Subjective downline and objective downline

(1) Subjective downline (subjectively down, abbreviated as Sdown) refers to a single Sentinel instance to the server to make the downline judgment.

(2) Objective downline (objectively down, abbreviated as Odown) refers to a number of Sentinel instances in the same server to make Sdown judgment, and through Sentinel is-master-down-by-addr command to communicate with each other, to obtain The server offline judgment.

Objective downline conditions apply only to the primary server: for any other type of Redis instance, Sentinel does not need to negotiate before judging them as a downline, so the objective downline condition will never be reached from the server or other Sentinel.

As soon as a Sentinel discovers that a primary server has entered an objective downline, this sentinel may be selected by other Sentinel and perform an automatic failover of the failed primary server.

Timed tasks performed by each Sentinel instance

(1) Each Sentinel sends a PING command to the master server it knows, from the server, and from other Sentinel instances, at a rate of one time per second.

(2) If an instance (instance) is closer to the last valid PING command than the value specified by the Down-after-milliseconds option, the instance is flagged by Sentinel as a subjective downline. A valid reply can be: +pong,-loading, or-masterdown.

(3) If a primary server is marked as a subjective downline, then all Sentinel monitoring of this primary server will confirm that the primary server has actually entered a subjective downline state at a frequency of once per second.

(4) If a primary server is marked as a subjective downline, and there is a sufficient number of Sentinel (at least the number specified in the configuration file) to agree to this judgment within a specified time frame, then the primary server is marked as an objective offline.

(5) In general, each Sentinel sends an INFO command to all of its known primary and slave servers at a frequency of every 10 seconds. When a primary server is marked as objective by Sentinel, Sentinel sends all the INFO commands from the server to the offline primary server from 10 seconds to once per second.

(6) When there is not enough Sentinel to agree that the primary server has been offline, the objective downline status of the primary server is removed. When the primary server re-returns a valid reply to Sentinel's PING command, the primary server's supervisor downline status is removed.

9. Simulated test main node down:

#/USR/LOCAL/BIN/REDIS-CLI 127.0.0.1:6379> SHUTDOWN

To view the Sentinel logs:

# tailf /data/redis/sentinel.log&nbsp, ..... [11501] 29 apr 18:23:17.377 # +sdown master ckl_master10.1.1.8 6379[ 11501] 29 apr 18:23:17.435 # +odown master ckl_master10.1.1.8 6379   #quorum  3/2  //3 2 detects node down [11501] 29 apr 18:23:17.435 # + New-epoch 2[11501] 29 apr 18:23:17.435 # +try-failover master ckl_ master10.1.1.8 6379  //primary resolve failover [11501] 29 apr 18:23:17.442 # + vote-for-leader 2535af9a6926391270af19cb872c93a1cd499ea9 2[11501] 29 apr 18:23:17.455  # 10.1.1.12:26379 VOTED FOR 2535AF9A6926391270AF19CB872C93A1CD499EA9 2[11501]  29 Apr 18:23:17.456 # 10.1.1.11:26379 voted for  2535af9a6926391270af19cb872c93a1cd499ea9 2[11501] 29 apr 18:23:17.534 # + Elected-leader master ckl_master10.1.1.8 6379[11501] 29 apr 18:23:17.534 # + failover-state-select-slave master ckl_master10.1.1.8 6379[11501] 29 apr  18:23:17.634 # +selected-slave slave 10.1.1.11:6379 10.1.1.116379 @ ckl_ master10.1.1.8 6379 //elect a new master node [11501] 29 apr 18:23:17.635 * + Failover-state-send-slaveof-noone slave 10.1.1.11:6379 10.1.1.116379 @ ckl_ Master10.1.1.8 6379[11501] 29 apr 18:23:17.711 * +failover-state-wait-promotion  slave 10.1.1.11:6379 10.1.1.116379 @ ckl_master10.1.1.8 6379[11501] 29  apr 18:23:18.535 # +promoted-slave slave 10.1.1.11:6379 10.1.1.116379  @ ckl_master10.1.1.8 6379[11501] 29 apr 18:23:18.535 # + failover-state-reconf-slaves master ckl_master10.1.1.8 6379[11501] 29 apr 18:23:18.541 * +slave-reconf-sent slave 10.1.1.13:6379  10.1.1.136379 @ ckl_master10.1.1.8 6379 //Reset Configuration Specifies the new primary node [11501] 29 apr  18:23:19.532 * +slave-reconf-inprog slave 10.1.1.13:6379 10.1.1.136379 @  Ckl_master10.1.1.8 6379 [11501] 29 apr 18:23:19.532 * +slave-reconf-done  slave 10.1.1.13:6379 10.1.1.136379 @ ckl_master10.1.1.8 6379[11501] 29  apr 18:23:19.584 # -odown master ckl_master10.1.1.8 6379[11501] 29  Apr 18:23:19.584 * +slave-reconf-sent slave 10.1.1.12:6379 10.1.1.12  6379 @ ckl_master10.1.1.8 6379 //Reset Configuration Specifies the new primary node [11501] 29 apr 18:23:20.589  * +slave-reconf-inprog slave 10.1.1.12:6379 10.1.1.12 6379 @ ckl_ master10.1.1.8 6379[11501] 29 apr 18:23:20.589 * +slave-reconf-done slave 10.1.1.12:6379 10.1.1.12  6379 @ ckl_master10.1.1.8 6379[11501] 29 apr 18:23:20.640 # + failover-end master ckl_master10.1.1.8 6379[11501] 29 apr 18:23:20.640 #  +switch-master ckl_master10.1.1.8 6379 10.1.1.116379[11501] 29 Apr  18:23:20.640 * +slave slave 10.1.1.13:6379 10.1.1.136379 @ ckl_ master10.1.1.116379[11501] 29 apr 18:23:20.640 * +slave slave  10.1.1.12:6379 10.1.1.12 6379 @ ckl_master10.1.1.116379[11501] 29 apr  18:23:20.641 * +slave slave 10.1.1.8:6379 10.1.1.8 6379 @ ckl_ master10.1.1.116379[11501] 29 apr 18:23:50.669 # +sdown slave 10.1.1.8:6379  10.1.1.8 6379 @ ckl_master10.1.1.116379

To view the master node information for the new election:

10.1.1.11

#/usr/local/bin/redis-cli127.0.0.1:6379> info....# replicationrole:masterconnected_slaves:2slave0:ip= 10.1.1.13,port=6379,state=online,offset=67708,lag=0slave1:ip=10.1.1.12,port=6379,state=online,offset=67852,lag =0master_repl_offset:67852repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_ backlog_histlen:67851

To test the new master-slave synchronization:

10.1.1.11:6379

#/usr/local/bin/redis-cli127.0.0.1:6379> Set Port "1090"

10.1.1.12:6379

127.0.0.1:6379> get Port "1090"

10.1.1.13:6379

127.0.0.1:6379> get Port "1090"

This article is from the "OPS rookie" blog, please be sure to keep this source http://ckl893.blog.51cto.com/8827818/1769094

Redis Master-Slave cluster description and configuration