Implementation of redis replication, sentinel and cluster

2.1 configuration

There are three ways to configure the slave database for redis. The second way is recommended for the production environment. In order to save time, practice using the same command-line parameters. Using slavof at runtime will overwrite the original data of the node. Use it with caution.

2.1.1 command line parameters

1. First check whether there is a redis instance being started, and then start a redis instance A. if there is no parameter, it means that port 6370 is listening by default. Make it the main database

[root@localhost ~]# ps -ef|grep redis root 2202 2171 0 10:43 pts/0 00:00:00 grep --color=auto redis [root@localhost ~]# redis-server 2203:C 05 Feb 2020 10:43:08.803 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 2203:C 05 Feb 2020 10:43:08.804 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=2203, just started

1. There is a drawback to the above direct launch. You need to reopen an xshell window. Start a redis instance B to listen to port 6380 and set it to listen to the slave database of the 6379 interface instance.

[root@localhost ~]# redis-server --port 6380 --slaveof 127.0.0.1 6379 2622:C 05 Feb 2020 11:03:52.131 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 2622:C 05 Feb 2020 11:03:52.131 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=2622, just started

2.1.2 configuration file

1. After the installation of redis, a redis.conf file is provided. Do not move this file. Create a new copy folder by yourself

[root@localhost redis-5.0.0]# mkdir copy [root@localhost redis-5.0.0]# cd copy/

1. Now we want to start an instance C listening to port 6381 as the slave database of instance A. We need to create A new 6381 folder under the copy folder, copy the redis configuration file to this folder, and modify several configuration parameters

[root@localhost redis-5.0.0]# cp redis.conf copy/6381 [root@localhost redis-5.0.0]# vim redis.conf

Modify the following parameters

//Profile mode to start the slave database of instance A [root@localhost 6381]# redis-server redis.conf 3822:C 05 Feb 2020 15:14:38.032 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 3822:C 05 Feb 2020 15:14:38.032 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=3822, just started 3822:C 05 Feb 2020 15:14:38.032 # Configuration loaded [root@localhost 6381]# ps -ef|grep redis root 2203 1 0 13:31 ? 00:00:23 redis-server *:6379 root 2327 1 0 13:37 ? 00:00:20 redis-server *:7000 root 2376 2336 0 13:37 pts/2 00:00:00 redis-cli -p 7000 root 2622 1 0 13:52 ? 00:00:18 redis-server *:6380 root 3485 3249 0 14:47 pts/7 00:00:00 redis-cli -p 6379 root 3823 1 0 15:14 ? 00:00:00 redis-server 127.0.0.1:6381 root 3829 3132 0 15:14 pts/5 00:00:00 grep --color=auto redis //View port 6381 replication [root@localhost 6381]# redis-cli -p 6381 127.0.0.1:6381> info replication # Replication role:slave master_host:127.0.0.1 master_port:6379

2.1.3 using slavof at runtime

1. Use the instance A listening to port 6379 as the main database, and add the instance listening to port 7000 as the slave database B

[root@localhost ~]# redis-server --port 7000 2327:C 05 Feb 2020 10:48:59.138 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 2327:C 05 Feb 2020 10:48:59.138 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=2327, just started

1. Use redis cli instance B, add data, and then use it as the slave database of instance A

[root@localhost ~]# redis-cli -p 7000 127.0.0.1:7000> set key v OK 127.0.0.1:7000> slaveof 127.0.0.1 6379 //Use the command to make this instance the slave Library of instance A OK 127.0.0.1:7000> keys * //You can see that the values in the original library are overwritten (empty list or set) //At this time, the set value reports an error because it is read-only by default from the database 127.0.0.1:7000> set k v (error) READONLY You can't write against a read only replica. //Slavof no one can be upgraded to the primary database and disconnected from instance A 127.0.0.1:7000> slaveof no one OK

2.2 principle

Persistence of RDB mode used by redis 2.6 and earlier
redis 2.8 implements incremental replication in the case of primary and secondary short-term reconnection
redis 2.8.18 introduces hard disk free replication, does not save the snapshot to the hard disk, and directly sends it to the slave database through the network, avoiding the performance bottleneck of the hard disk
The master-slave replication adopts optimistic replication, and the master-slave synchronous data is asynchronous.

2.2.1 Persistence Based on RDB

1. After starting the slave database, send the SYNC command to the master database
2. After receiving the SYNC command, the master database saves the snapshot in the background and saves the commands accepted during the snapshot saving. After the snapshot is completed, send the snapshot file and all cached commands to the slave database.
3. After receiving from the database, the received content will be written to the temporary file of the hard disk. When the writing is completed, the RDB snapshot file will be replaced by the temporary file from the database, and then the read file completes the synchronization.

Any command executed by the master database that causes data changes will be asynchronously transferred to the slave database.

2.2.2 no hard disk copy

1. Advantages of rdb: simplify logic and take existing code
2. Disadvantages of rdb mode: persistence is relatively time-consuming, and it can be persisted from the database. However, persistence is disabled from the master database in time, that is, deleting the save data of all configuration files, copying initialization or generating rdb files. In addition, if the performance of hard disk is very slow (such as network hard disk), it will affect the performance
3. When the hard disk free replication is enabled, the snapshot content will not be stored. The main database directly sends the data to the slave database through the network.
4. repl-diskless-sync yes

2.2.3 incremental replication

When the master-slave database is disconnected and reconnected, reconnecting the slave database will send the sync command to copy all the data of the master database again, which is quite time-consuming, especially when there is little change during the disconnection from the database.
Incremental replication optimizes disconnection and reconnection from the database.

1. Save the running id of the main database from the database
2. In the replication synchronization phase, when the master database transmits the command to the slave database, it puts the command into the backlog and records the offset range of the command.
3. At the same time, after receiving the command from the database, record the offset of the latest command.

Data backup and read-write separation can be performed from the database. When the main database goes down, you need to manually switch from the database to the main database. The Sentry can switch automatically.

3.1 sentry function

1. Monitor whether the master-slave database operates normally and print logs
2. In case of failure of the primary database, it will automatically upgrade from the database to the primary database. After short-term reconnection, the master database automatically becomes the slave database of the new master database.

3.2 deployment of Sentinels

1. Create a new folder sentinel under copy to store the configuration file.

[root@localhost ~]# cd /redis/redis-5.0.0/copy/ [root@localhost copy]# mkdir sentinel

1. New configuration file sentinel.conf, write

[root@localhost copy]# cd sentinel [root@localhost sentinel]# ll total 0 [root@localhost sentinel]# vim sentinel.conf //Write content. congige is the name given to the main database sentinel monitor confige 127.0.0.1 6379 1

The name of the master data must consist of three characters: uppercase and lowercase letters, numbers and "." - "

1. Start sentinel

[root@localhost sentinel]# redis-sentinel sentinel.conf 4768:X 05 Feb 2020 16:45:01.732 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 4768:X 05 Feb 2020 16:45:01.732 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=4768, just started . . . 4768:X 05 Feb 2020 16:45:01.735 # Sentinel ID is 39ba7fa9f49c9b9f238f27cc2487edde1ec199b9 4768:X 05 Feb 2020 16:45:01.735 # +monitor master confige 127.0.0.1 6379 quorum 1 4768:X 05 Feb 2020 16:45:01.736 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ confige 127.0.0.1 6379 4768:X 05 Feb 2020 16:45:01.738 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ confige 127.0.0.1 6379

Explanation of sentinel configuration price inquiry parameters:
Reference resources
sentinel monitor
Tell sentinel to listen to a master whose address is ip:port. Here, the master name can be customized. quorum is a number, indicating how many sentinels think a master is invalid, and the master is really invalid
sentinel auth-pass
Set the password when connecting master and slave. Note that sentinel cannot set different passwords for master and slave respectively, so the passwords for master and slave should be the same.
sentinel down-after-milliseconds
This configuration item specifies how long the expiration time is required for a master to be subjectively considered unavailable by the sentinel. Unit is milliseconds, default is 30 seconds
sentinel parallel-syncs
This configuration item specifies the maximum number of slaves that can synchronize the new master at the same time in the event of failover master-slave switching. The smaller the number is, the longer the time required to complete failover will be. However, the larger the number is, the more slaves are unavailable due to replication. You can set this value to 1 to ensure that only one slave at a time is in a state where command requests cannot be processed.
sentinel failover-timeout
Failover timeout can be used in the following aspects:
a. The interval between two failures of the same sentinel pair and the same master.
b. When a slave synchronizes data from a wrong master, the time is calculated. Until the slave is corrected to synchronize data with the correct master.
c. The time it takes to cancel an ongoing failover.
d. When failover occurs, configure the maximum time required for all slaves to point to the new master. However, even after this timeout, slaves will still be correctly configured to point to the master, but they will not follow the rules configured by parallel syncs.

1. We close the main library and look at the output;

[root@localhost ~]# ps -ef|grep redis root 2203 1 0 13:31 ? 00:00:55 redis-server *:6379 root 2327 1 0 13:37 ? 00:00:44 redis-server *:7000 root 2622 1 0 13:52 ? 00:00:45 redis-server *:6380 root 3485 3249 0 14:47 pts/7 00:00:00 redis-cli -p 6379 root 3823 1 0 15:14 ? 00:00:27 redis-server 127.0.0.1:6381 root 4768 3177 0 16:45 pts/6 00:00:10 redis-sentinel *:26379 [sentinel] root 5072 3436 0 17:11 pts/8 00:00:00 grep --color=auto redis [root@localhost ~]# kill -9 2203

The input is as follows

//6379 port corresponding node 1 subjective offline 4768:X 05 Feb 2020 17:12:24.564 # +sdown master confige 127.0.0.1 6379 //Node 1 Objective offline 4768:X 05 Feb 2020 17:12:24.564 # +odown master confige 127.0.0.1 6379 #quorum 1/1 4768:X 05 Feb 2020 17:12:24.564 # +new-epoch 1 //Sentry begins to recover 4768:X 05 Feb 2020 17:12:24.564 # +try-failover master confige 127.0.0.1 6379 //Start to elect the lead sentry 4768:X 05 Feb 2020 17:12:24.565 # +vote-for-leader 39ba7fa9f49c9b9f238f27cc2487edde1ec199b9 1 //Select the lead sentry 4768:X 05 Feb 2020 17:12:24.565 # +elected-leader master confige 127.0.0.1 6379 //Select node 1 as the primary database 4768:X 05 Feb 2020 17:12:24.565 # +failover-state-select-slave master confige 127.0.0.1 6379 //Select the node 3 corresponding to port 6381 as the slave database 4768:X 05 Feb 2020 17:12:24.650 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:24.650 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:24.728 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:25.131 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:25.131 # +failover-state-reconf-slaves master confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:25.211 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:26.151 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:26.151 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ confige 127.0.0.1 6379 //Complete recovery 4768:X 05 Feb 2020 17:12:26.214 # +failover-end master confige 127.0.0.1 6379 4768:X 05 Feb 2020 17:12:26.214 # +switch-master confige 127.0.0.1 6379 127.0.0.1 6381 4768:X 05 Feb 2020 17:12:26.215 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ confige 127.0.0.1 6381 4768:X 05 Feb 2020 17:12:26.215 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ confige 127.0.0.1 6381 4768:X 05 Feb 2020 17:12:56.237 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ confige 127.0.0.1 6381

1. Restart instance A

[root@localhost redis-5.0.0]# redis-server redis.conf 5154:C 05 Feb 2020 17:17:37.481 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 5154:C 05 Feb 2020 17:17:37.481 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=5154, just started 5154:C 05 Feb 2020 17:17:37.481 # Configuration loaded

Look at the sentinel output

//Discovery node 4768:X 05 Feb 2020 17:17:38.190 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ confige 127.0.0.1 6381 //The slave node that turns the node into a new master node 4768:X 05 Feb 2020 17:17:48.198 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ confige 127.0.0.1 6381

3.3 sentry principle

The content of the configuration file is read when the sentry starts
sentinel monitor confige 127.0.0.1 6379 1
After fault recovery, the ip address and port number of the main database may change, so the ip and port number information can be obtained through the name of the main database
sentinel.conf has a lot of content after initialization. Now, with daemonize, it can run in the background

[root@localhost sentinel]# vim sentinel.conf sentinel myid 39ba7fa9f49c9b9f238f27cc2487edde1ec199b9 # Generated by CONFIG REWRITE port 26379 dir "/redis/redis-5.0.0/copy/sentinel" sentinel deny-scripts-reconfig yes sentinel monitor confige 127.0.0.1 6381 1 sentinel config-epoch confige 1 sentinel leader-epoch confige 1 sentinel known-replica confige 127.0.0.1 6379 sentinel known-replica confige 127.0.0.1 6380 sentinel current-epoch 1

Restart after modifying sentinel configuration file

[root@localhost sentinel]# redis-sentinel sentinel.conf 6117:X 05 Feb 2020 18:43:34.891 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 6117:X 05 Feb 2020 18:43:34.892 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=6117, just started 6117:X 05 Feb 2020 18:43:34.892 # Configuration loaded //View process number, port, service [root@localhost sentinel]# ps -ef|grep redis root 2327 1 0 13:49 ? 00:01:01 redis-server *:7000 root 2622 1 0 14:04 ? 00:01:04 redis-server *:6380 root 3485 3249 0 15:00 pts/7 00:00:00 redis-cli -p 6379 root 3823 1 0 15:26 ? 00:00:48 redis-server 127.0.0.1:6381 root 5155 1 0 17:29 ? 00:00:17 redis-server 127.0.0.1:6379 root 6118 1 1 18:43 ? 00:00:00 redis-sentinel *:26379 [sentinel] root 6131 5851 0 18:43 pts/0 00:00:00 grep --color=auto redis [root@localhost sentinel]# redis-cli -p 26379 //View master node information 127.0.0.1:26379> info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=confige,status=ok,address=127.0.0.1:6381,slaves=2,sentinels=1 127.0.0.1:26379>

1. After the sentinel starts, two connections will be established with the main database to be monitored
   (1) Subscribe to the "sentinel" of the main database: Hello channel obtains the information of the sentinel node of the main database node, which is also monitored;
   (2) Send INFO and other commands to the master database regularly to obtain the information of the master database node itself
2. After the connection with the main database is established, the Sentry will perform the following three operations at regular intervals
   (1) The INFO command is sent to the master and slave databases every 10 seconds.
   (2) Every 2 seconds, the Sentry will send his own information to the ﹐ sentinel ﹐ Hello channel of the master database and the slave database
   (3) It will be sent to the master database, slave database and other sentinel nodes every 1 second

• Give the thumbs-up
• Collection
• share
• • Article report