Implementation of redis replication, sentinel and cluster

1. redis.conf configuration parameters

configuration parameter Effect
demonize Set to yes, which can be executed in the background

After setting this in the configuration file, you can start a redis instance through redis-server redis.conf. So there's no need to open another window.

configuration parameter Effect
slaveof Write the ip port number of the main library
daemonize yes redis running in the background
bind 127.0.0.1 192.168.0.1 ip address
port 6389 port number
dir Snapshot file save path
slave-priority From node priority
slaveof Whose slave node is it
slave-read-only Whether the slave node is readable only
slave-serve-stale-data no - before the synchronization from the database is completed, all the commands except info and slave are reversed
min-slaves-to write 1-AT least one slave database can be connected, and the master database can be written
min-slaves-max-lag 10 - allow connection loss from database for 10s
repl-disable-top-nodelay yes - enable hard disk free replication
repl-backlog-size 100mb backlog queue size
repl-backlog-ttl 3600 - how long can the backlog be released after all slave libraries are disconnected from the master database
repl-diskless-sync yes - enable hard disk free replication

2. copy

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

configuration parameter Effect
slaveof Write the ip port number of the main library, which needs to be added manually
daemonize yes redis running in the background
bind 127.0.0.1 192.168.0.1 ip address
port 6381 port number
slave-priority From node priority, it can be left blank. Between 1-100, the smaller the value, the higher the priority
//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

2.2.1.1 replication initialization

  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.

2.2.1.1 replication synchronization phase

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.

2.2.3.1 implementation basis of incremental replication

  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.

3. Sentinels

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
Published 10 original articles, won praise 0, visited 113
Private letter follow

Tags: Redis Database snapshot vim

Posted on Wed, 05 Feb 2020 07:57:09 -0500 by AnAmericanGunner