In-depth introduction to Redis-redis sentinel cluster, simple introduction to redis-redis

In-depth introduction to Redis-redis sentinel cluster, simple introduction to redis-redis
1. Sentinel

Sentinel is a Redis high availability solution: a Sentinel system consisting of one or more Sentinel instances can monitor any number of Master servers, and all slave servers under the master server. When the monitored master server goes offline, it automatically upgrades a slave server under the master server to a new master server.

For example:

After Server1 is disconnected:

Upgrade Server2 to a new master server:

　　

 

 

2. Redis master-slave Separation

Before explaining the Sentinel cluster, we will first build a simple master-slave separation (read/write splitting ).

First, we have installed redis by default.Redis. confCopy multiple copies and create multiple directories to differentiate multiple redis services:

　　　

Here, each directory has its own redis. conf configuration file. Next, we will first set the configuration file of the master server.

1. Configure Master

1. Modify the port

# Accept connections on the specified port, default is 6379 (IANA #815344).# If port 0 is specified Redis will not listen on a TCP socket.port 6380

The default port of redis is 6379. Here we set the port of the master server to 6380.

 

2. Modify pidfile

# If a pid file is specified, Redis writes it where specified at startup# and removes it at exit.## When the server runs non daemonized, no pid file is created if none is# specified in the configuration. When the server is daemonized, the pid file# is used even if not specified, defaulting to "/var/run/redis.pid".## Creating a pid file is best effort: if Redis is not able to create it# nothing bad happens, the server will start and run normally.pidfile /var/run/redis_6380.pid

Pidfile is the pid process number assigned to us by linux when we start redis. If this parameter is not modified, it will affect the startup of the redis service in the future.

 

3. Start redis

Start redis. We can see that redis has occupied port 6380.

Enter the client

redis-cli -p 6380127.0.0.1:6380> info...# Replicationrole:masterconnected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0...

 

We can see that the current role of redis is a master-started service.

 

Ii. Configure Slave

Like configuring the master, we need to modify the port number and pid file. After the modification, we have two ways to configure

　　1. Configure the slave service in the configuration file

################################# REPLICATION ################################## Master-Slave replication. Use slaveof to make a Redis instance a copy of# another Redis server. A few things to understand ASAP about Redis replication.## 1) Redis replication is asynchronous, but you can configure a master to#    stop accepting writes if it appears to be not connected with at least#    a given number of slaves.# 2) Redis slaves are able to perform a partial resynchronization with the#    master if the replication link is lost for a relatively small amount of#    time. You may want to configure the replication backlog size (see the next#    sections of this file) with a sensible value depending on your needs.# 3) Replication is automatic and does not need user intervention. After a#    network partition slaves automatically try to reconnect to masters#    and resynchronize with them.## slaveof <masterip> <masterport>

slaveof 127.0.0.1 6380

We can directly modify it in the configuration file.SlaveofAttribute. You can directly configure the ip address and port number of the master server.

You can configureMasterauthTo set the link Password

# If the master is password protected (using the "requirepass" configuration# directive below) it is possible to tell the slave to authenticate before# starting the replication synchronization process, otherwise the master will# refuse the slave request.## masterauth <master-password>

Start the redis service:

We can see that two of them are currently running. Let's go to the 6381 client and check its status,

# Replicationrole:slavemaster_host:127.0.0.1master_port:6380master_link_status:upmaster_last_io_seconds_ago:1master_sync_in_progress:0slave_repl_offset:71slave_priority:100slave_read_only:1connected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0

 

We can see that the current redis is a slave service role that connects to the 6380 service.

 

　　 2. After the service is started, Set

　　　　After modifying the server configuration file of port 6382, start the service.

Go to the client and check the status of the current server:

# Replicationrole:masterconnected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0

We can see that the current server status is running as a master service role, and we will modify its status:

127.0.0.1: 6382> slaveof 127.0.0.1 6380 // the modified status # Replicationrole: Role: 127.0.0.1master _ port: 6380master_link_status: Role: 0master_repl_offset: role: 0repl_backlog_size: 1048576repl_backlog_first_byte_offset: 0repl_backlog_histlen: 0

　　　　

　　 3. Summary

Let's take a look at the current master Status:

# Replicationrole:masterconnected_slaves:2slave0:ip=127.0.0.1,port=6381,state=online,offset=785,lag=0slave1:ip=127.0.0.1,port=6382,state=online,offset=785,lag=0master_repl_offset:785repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:784

 

We can see that two slave services are already connected to the master server. The difference between the two configurations is that after salve is disconnected and reconnected,

If we modify the class configuration file, after the reconnection, We will link it to the master and synchronize the data above the master,

If we connect to the master server manually, after the reconnection, the slave server will read its local rdb to reply data, instead of automatically linking to the master service.

 

To set read/write splitting, you only need to set it in the master server:

# Note: read only slaves are not designed to be exposed to untrusted clients# on the internet. It's just a protection layer against misuse of the instance.# Still a read only slave exports by default all the administrative commands# such as CONFIG, DEBUG, and so forth. To a limited extent you can improve# security of read only slaves using 'rename-command' to shadow all the# administrative / dangerous commands.slave-read-only yes

 

 

 

3. Sentinel

 

1. Configure the port

In sentinel. in the conf configuration file, we can find the port attribute, which is used to set the sentinel port. Generally, at least three sentinel ports are required to monitor redis, we can start multiple sentinel services by modifying the port.

# port <sentinel-port># The port that this sentinel instance will run onport 26379

 

2. Configure the ip address and port of the master server

Modify the listening port to 6380 and add the weight to 2. The weight here is used to calculate which server we need to upgrade to the master server.

# sentinel monitor <master-name> <ip> <redis-port> <quorum>## Tells Sentinel to monitor this master, and to consider it in O_DOWN# (Objectively Down) state only if at least <quorum> sentinels agree.## Note that whatever is the ODOWN quorum, a Sentinel will require to# be elected by the majority of the known Sentinels in order to# start a failover, so no failover can be performed in minority.## Slaves are auto-discovered, so you don't need to specify slaves in# any way. Sentinel itself will rewrite this configuration file adding# the slaves using additional configuration options.# Also note that the configuration file is rewritten when a# slave is promoted to master.## Note: master name should not include special characters or spaces.# The valid charset is A-z 0-9 and the three characters ".-_".sentinel monitor mymaster 127.0.0.1 6380 2

 

　

3. Start Sentinel

/sentinel$ redis-sentinel sentinel.conf

 

After sentinel is started, it will monitor a master server and two slave servers.

When we disable one of the slave servers, we can see the log:

10894:X 30 Dec 16:27:03.670 # +sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

The log indicates that the slave server 6381 has been removed from the master server, and we will re-connect the slave server 6381.

10894:X 30 Dec 16:28:43.288 * +reboot slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 638010894:X 30 Dec 16:28:43.365 # -sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

 

 

　　

4. Disable the Master

After we manually shut down the Master, sentinel will start to calculate the weight value and then re-allocate the master server after the listening Master is indeed disconnected.

We can see that after the 6380 master server is disconnected, sentinel helped us select 6382 as the new master server.

Go to the 6382 client and check its status:

# Replicationrole:masterconnected_slaves:1slave0:ip=127.0.0.1,port=6381,state=online,offset=13751,lag=0master_repl_offset:13751repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:13750

 

We can see that 6382, heavy slave is upgraded to master

127.0.0.1:6382> set name jaycekonOK

The original write permission is not available, and the corresponding permission is also obtained.

 

　　

5. reconnect to the Master

You may be wondering if the master node will be reconnected to his position. The answer is no. For example, if you are robbed of the position of your boss by a younger brother, will he give you back to this position. So when the master comes back, he can only be a younger brother.

 

 

4. Sentinel Summary IAnd Sentinel:

A. Master Status Monitoring

B. If the Master node is abnormal, the Master-slave conversion will be performed. One of the Slave will be used as the Master node and the previous Master will be used as the Slave node.

C. After the Master-Slave switch, the content of master_redis.conf, slave_redis.conf, and sentinel. conf will change, that is, the master_redis.conf will have one more slaveof configuration, and the sentinel. conf monitoring target will be

 

 

IIAnd Sentinel:

1): Each Sentinel sends a PING command to the Master, Slave, and other Sentinel instances it knows every second.
2) If the time between an instance and the last valid PING command reply exceeds the value specified by the "down-after-milliseconds" option, this instance is marked as subjective offline by Sentinel.
3): If a Master is marked as a subjective deprecation, all Sentinel of the Master being monitored should confirm that the Master is in the subjective deprecation status once per second.
4): when there is a sufficient number of Sentinel (greater than or equal to the value specified in the configuration file) within the specified time range, it is confirmed that the Master has entered the subjective deprecation status, the Master will be marked as an objective offline
5): In general, each Sentinel sends the INFO command to all known masters every 10 seconds.
6): When the Master is marked as an objective deprecation by Sentinel, the frequency of sending the INFO command from Sentinel to all Slave of the offline Master is changed from 10 seconds to once per second.
7): If there is not enough Sentinel to agree that the Master has been deprecated, the objective deprecation status of the Master will be removed.
If the Master returns a valid reply to the Sentinel PING command again, the Master's subjective offline status will be removed.