This paper briefly introduces the installation and deployment of three modes of redis in linux and the summary of data storage, hoping to communicate with each other and improve each other.

For Centos7, you need to install some common tools before installing redis:

Turn off the firewall

Formal installation of redis

There will be a series of exceptions when redis makes a maketest, and there are several solutions:

It is meaningless to start redis with redis-server and do some experiments.

Run redis as the daemon of the system. Every time the system starts, the redis process starts together. The operation is as follows:

RDB and AOF are a data persistence mechanism of redis. Persistence is to avoid system data loss caused by catastrophic system failure. We usually store the data on the local disk and upload the data to the cloud server regularly.

RDB is a snapshot of redis, which is set through the save configuration in redis.conf, such as save 60 1000:

AOF stores data in appendonly mode. When AOF mode is turned on, all data stored in redis memory will enter os cache, and then fsync write operation will be performed at 1 sec by default and appended to appendonly.aof file. Usually, we configure the following instructions in redis.conf:

Aof and RDB modes are usually turned on in a production environment. Generally speaking, when the redis service is suspended and restarted, AOF files will be given priority.

When a slave node starts, it will send a PSYNC command to the master node. If this is a slave node reconnecting to the master node, then the master node will only copy the data lost from the slave node. Otherwise, if the slave node connects to the master node for the first time, it will trigger a full resynchronization;

At the beginning of full resynchronization, the host will start a background thread, start generating RDB snapshot files, and cache all the write commands received from the client in memory. After the RDB file is generated, the master device will send this RDB to the slave device, and the slave device will write it to the local disk first, and then load it into the memory from the local disk. Then the master will send the write command cached in the memory to the slave, and the slave will synchronize the data.

If the slave node is disconnected due to the network failure of the master node, it will automatically reconnect. If the master node finds that multiple slave nodes need to be reconnected, it will only start one rdb save operation and provide a copy of the data for all slave nodes.

Starting from redis 2.8, the breakpoint continuation of master-slave replication has been supported. If the network connection is interrupted during the master-slave replication, you can continue to copy from the last place instead of starting the replica from scratch.

The master node usually has a backlog in memory, and both the master node and the slave node save a copy offset and a master node id, and the offset is saved in the backlog. If the network connection between the master device and the slave device is broken, the slave device will let the master device continue copying from the last copy offset, but if the corresponding offset is not found, resynchronization will be performed.

Master creates rdb directly in memory and sends it to slave, so it won't log on to the disk locally. It can be configured as follows:

The slave device does not expire the key, but only waits for the master device to expire the key. If a key of the master device has expired, or a key is deleted through LRU, a del command will be simulated and sent to the slave device.

In the redis.conf configuration file, the above parameters indicate that at least three slave nodes need to be connected to the master node, and the data synchronization delay between the master node and each slave node cannot exceed 10 second. Once the above settings do not match, the master will no longer provide corresponding services.

The condition of sdown is simple. If the sentry ping the main server exceeds the number of milliseconds specified by is-master-down-after- milliseconds, it is subjectively considered that the main server has been shut down.

The condition of sdown to odown conversion is very simple. If a sentry receives a specified number of other sentries from quorum within a specified time and thinks that the owner is down, then it is considered odown, and objectively the owner is Down.

If the slave is disconnected from the master more than 10 times, plus the downtime of the master, it is considered that the slave is not suitable to be selected as the master.

(down-after- ms * 10)+ms _ from _ master _ under _ state

Every time a sentry wants to switch between master and standby, a quorum of sentries should think that it is odown first, and then a slave station should be selected to switch, and the slave station should be authorized by most sentries to formally perform the switch.

(2)SENTINEL RESET *, which is executed on all SENTINEL to clear all host states.

(3) Sentinel mastername, which is executed on all sentinels to see if all sentinels agree on the number.

4.3.2 The slave is permanently offline.

Let the master remove a slave: the sentry resets the offline master name and executes it on all sentinels.

Redis cluster mode In order to solve the problem of horizontal expansion of the system and storage of massive data, if you have a large amount of data, you can use Redis cluster.

Redis cluster can support n redismasters, and a master can mount multiple slaves. Generally, we mount one or two slaves, and when the host hangs up, it will switch to the slave actively, or when all slaves on one host hang up, the cluster will find redundant slaves from other hosts and mount them on this host, thus realizing high availability of the system.

2. Important configuration of1redis cluster

2.2 Start six redis instances on three machines.

Distribute the above six configuration files in /etc/redis, namely: 700 1.conf, 7002.conf, 7003.conf, 7004.conf, 7005.conf and 7006.conf.

In each startup script, the corresponding port number is modified.

2.3 Create a cluster

The solution is to install rvm first and then upgrade the ruby version to 2.3.3.

Use the redis-trib.rb command to create a cluster.

-replicas: indicates how many slave devices each master device has.

Redis-trib.rbcheck192.168.31.187: 7001View shapes.

3. 1 Add a new master shape

After the above same configuration is completed, set the startup script to start and then use the following command to add nodes:

3.2 Re-store some data in the past

3.3 Add a Node as a Slave Node

3.4 Delete nodes