redis master-slave replication and sentinel mode

1, Master slave replication concept

Master slave replication refers to copying data from one Redis server to other Redis servers. The former is called the master node
(master/leader), which is called slave / follower; Data replication is unidirectional and can only be from master node to slave node.
Master mainly writes, Slave mainly reads.
By default, each Redis server is the master node; A master node can have multiple slave nodes (or no slave nodes), but a slave node can only have one master node.
​

2, Role of master-slave replication:

1. Data redundancy: master-slave replication realizes the hot backup of data, which is a data redundancy method other than persistence.
2. Fault recovery: when the master node has problems, the slave node can provide services to achieve rapid fault recovery; It's actually a service
Redundancy.
3. Load balancing: on the basis of master-slave replication, combined with read-write separation, the master node can provide write services and the slave node can provide read services
(that is, the application connects the master node when writing Redis data and the slave node when reading Redis data) to share the server load, especially when writing
In the scenario of less reading and more reading, multiple slave nodes share the reading load, which can greatly improve the concurrency of Redis server.
4. High availability (cluster) cornerstone: in addition to the above functions, master-slave replication is also the basis for sentinel and cluster implementation. Therefore, master-slave replication
System is the basis of Redis high availability.
​

3, Modify master-slave replication configuration file and start Redis service

[root@VM-4-10-centos redis-6.2.4]# ls
 00-RELEASENOTES  deps       redis-6379.conf  runtest      sentinel_26379.log   sentinel-26382.conf  src
BUGS             INSTALL    redis-6380.conf  runtest-cluster      sentinel-26380.conf  sentinel_26382.log   tests
CONDUCT          Makefile   redis-6381.conf  runtest-moduleapi    sentinel_26380.log   sentinel-26383.conf  TLS.md
CONTRIBUTING     MANIFESTO  redis-6382.conf  runtest-sentinel     sentinel-26381.conf  sentinel_26383.log
COPYING          README.md  redis-6383.conf  sentinel-26379.conf  sentinel_26381.log   sentinel.conf

Configure multiple redis Conf is used to start multiple redis services. It is easier to distinguish by adding end slogans. Five configuration files are configured: redis-6379 conf,redis-6380.conf,redis-6381.conf,redis-6382.conf,redis-6383.conf.

Port 6379 is the master node, and the rest are slave nodes.

By default, each Redis server is the master node; Generally, only the slave is configured. Configure in the configuration file of each slave node:

daemonize yes #Indicates background startup

port 6379     #Change to your own port number

slaveof 127.0.0.1 6379  #Master node IP address: the port number of the master node indicates that it is the slave node of the node

After the configuration file is configured, the redis service is started

Use the command:/ redis-server …/redis-6379.conf to start a redis service

[root@VM-4-10-centos src]# ./redis-server ../redis-6379.conf 
[root@VM-4-10-centos src]# ps -ef|grep redis
root      3298     1  0 14:28 ?        00:00:29 ./redis-server 127.0.0.1:6379
root      3323     1  0 14:28 ?        00:00:26 ./redis-server 127.0.0.1:6380
root      3340     1  0 14:28 ?        00:00:25 ./redis-server 127.0.0.1:6381
root      3353     1  0 14:28 ?        00:00:26 ./redis-server 127.0.0.1:6382
root      3365     1  0 14:28 ?        00:00:26 ./redis-server 127.0.0.1:6383

[root@VM-4-10-centos src]# ./redis-cli -p 6379  #Start the client of the master node
127.0.0.1:6379> info replication

# Replication
role:master  #Indicates that the node is the primary node
connected_slaves:4  #Indicates that the node has 4 slave nodes
slave0:ip=127.0.0.1,port=6380,state=online,offset=1809829,lag=0 #Information from the node
slave1:ip=127.0.0.1,port=6381,state=online,offset=1809829,lag=0
slave2:ip=127.0.0.1,port=6382,state=online,offset=1809829,lag=0
slave3:ip=127.0.0.1,port=6383,state=online,offset=1809829,lag=0
master_failover_state:no-failover
master_replid:415619cc6e479b710c68b353d1ebbad28d368ea1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1809962
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:761387
repl_backlog_histlen:1048576
127.0.0.1:6379> 

[root@VM-4-10-centos src]# ./redis-cli -p 6380 #Start the client of the slave node with port number 6380
127.0.0.1:6380> info replication

# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:1824900
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:415619cc6e479b710c68b353d1ebbad28d368ea1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1824900
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:776325
repl_backlog_histlen:1048576
127.0.0.1:6380> 

127.0.0.1:6379> set key "value"      #Set a key value pair in the master node and try to get it from the slave node
OK
127.0.0.1:6379> 

[root@VM-4-10-centos src]# ./redis-cli -p 6380    #Start the client of the slave node with port number 6380
127.0.0.1:6380> get key                           #Successfully fetched from the node
"value"
127.0.0.1:6380> set key2 "value2"                 #Try to write to the slave node and the prompt is read-only.
(error) READONLY You can't write against a read only replica.
127.0.0.1:6380>

The method of master-slave switching technology is: when the master server is down, a slave server needs to be manually switched to the master server, which requires manual intervention, which is laborious and laborious, and the service will not be available for a period of time. This is not a recommended way. More often, we give priority to sentinel mode.

4, Sentinel mode concept

Sentinel mode is a special mode. Firstly, Redis provides sentinel commands. Sentinel is an independent process. As a process, it will run independently. The principle is that the * * * sentinel monitors multiple running Redis instances by sending commands and waiting for a response from the Redis server***

[root@VM-4-10-centos redis-6.2.4]# ./src/redis-sentinel ./sentinel-26379.conf  #Start the sentry
[root@VM-4-10-centos redis-6.2.4]# ps -ef|grep redis
root      3298     1  0 14:28 ?        00:00:33 ./redis-server 127.0.0.1:6379
root      3323     1  0 14:28 ?        00:00:30 ./redis-server 127.0.0.1:6380
root      3340     1  0 14:28 ?        00:00:28 ./redis-server 127.0.0.1:6381
root      3353     1  0 14:28 ?        00:00:30 ./redis-server 127.0.0.1:6382
root      3365     1  0 14:28 ?        00:00:30 ./redis-server 127.0.0.1:6383
root      9050     1  0 15:03 ?        00:00:55 ./src/redis-sentinel *:26379 [sentinel]
root     12160     1  0 15:23 ?        00:00:42 ./src/redis-sentinel *:26380 [sentinel]
root     12196     1  0 15:24 ?        00:00:42 ./src/redis-sentinel *:26382 [sentinel]
root     12213     1  0 15:24 ?        00:00:41 ./src/redis-sentinel *:26383 [sentinel]
root     14032  9428  0 22:35 pts/0    00:00:00 ./redis-cli -p 6379
root     14626  9484  0 22:39 pts/1    00:00:00 ./redis-cli -p 6380
root     24367 23851  0 23:42 pts/2    00:00:00 grep --color=auto redis
[root@VM-4-10-centos redis-6.2.4]#

Other configuration items for sentinel mode

Configuration itemParameter typeeffect
portintegerStart sentinel process port
dirFolder directoryThe sentinel process service temporary folder is / tmp by default. You should ensure that you have writable permissions
sentinel down-after-milliseconds< service name > < milliseconds (integer) >When the designated Sentry is monitoring the Redis service, when the Redis service cannot answer within a default millisecond, the subjective offline time considered by a single Sentry is 30000 (30 seconds) by default
sentinel parallel-syncs< service name > < number of servers (integer) >Specify how many Redis services can synchronize new hosts. Generally speaking, the smaller the number, the longer the synchronization time, and the larger the number, the higher the requirements for network resources
sentinel failover-timeout< service name > < milliseconds (integer) >Specifies the number of milliseconds allowed for failover. If it exceeds this time, the failover is considered to have failed. The default is 3 minutes
sentinel notification-script< service name > < script path >Specifies the alarm script to be called when sentinel detects the instance exception pointed to by the redis instance of the monitoring. This configuration item is optional and commonly used

The sentinel down after milliseconds configuration item is just a sentinel. If the sentinel still fails to respond after the specified time, it will think that the host is unavailable. For other sentinels, this is not the case. The sentinel will record this message. When the number of sentinels who think they are offline reaches the configured number of sentinel monitor, a vote will be initiated to fail. At this time, the sentinel will rewrite the sentinel configuration file of Redis to meet the needs of the new scene.

Modify redis The conf file is as follows:

# The Redis server can be accessed across the network
bind 0.0.0.0
# Set password
requirepass "123456"
# Specify the master server. Note: slaveof configuration only configures the slave server, and the master server does not need to be configured
slaveof 192.168.11.128 6379
# Master server password. Note: slaveof configuration only configures the slave server, and the master server does not need to be configured
masterauth 123456

The above content is mainly to configure the Redis server. The slave server has one more slave configuration and password than the master server.

Configure 3 sentinels, and the configuration of each sentinel is the same. There is a sentinel in the Redis installation directory Conf file, copy a copy to modify

# Disable protection mode
protected-mode no
# Configure the master server for listening. sentinel monitor stands for monitoring and mymaster stands for the name of the server. It can be customized. 192.168 11.128 represents the monitored master server, 6379 represents the port, and 2 represents the failover operation only when two or more sentinels think the master server is unavailable.
sentinel monitor mymaster 192.168.11.128 6379 2
# Sentinel author pass defines the password of the service. mymaster is the service name and 123456 is the Redis server password
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

Redis cache penetration, cache breakdown, cache avalanche cause + Solution

  • Cache penetration: the data corresponding to the key does not exist in the data source. Every time a request for this key cannot be obtained from the cache, the request will be sent to the data source, which may crush the data source. For example, using a nonexistent user id to obtain user information, no matter in the cache or the database, if hackers use this vulnerability to attack, it may crush the database.

    solve:

    There must be no cache and data that cannot be queried. Because the cache is written passively when it misses, and for the sake of fault tolerance, if the data cannot be found from the storage layer, it will not be written to the cache, which will cause the nonexistent data to be queried at the storage layer every request, losing the significance of the cache.

    There are many methods to effectively solve the cache penetration problem. The most common is to use bloom filter to hash all possible data into a large enough bitmap, and a non-existent data will be intercepted by the bitmap, so as to avoid the query pressure on the underlying storage system. In addition, there is a more simple and crude method (we use this method). If the data returned by a query is empty (whether the data does not exist or the system fails), we still cache the empty result, but its expiration time will be very short, no more than five minutes.

  • Cache breakdown: the data corresponding to the key exists, but it expires in redis. At this time, if a large number of concurrent requests come, if these requests find that the cache expires, they will generally load data from the back-end dB and set it back to the cache. At this time, large concurrent requests may crush the back-end DB instantly.

    solve:

    key may be accessed at some point in time with extremely high concurrency, which is a very "hot" data. At this time, we need to consider a problem: the cache is "broken down".

    Use mutex key

    A common practice in the industry is to use mutex. In short, When the cache fails (it is judged that the value is empty), instead of immediately loading dB, set a mutex key by using some operations of the cache tool with the return value of successful operations (such as SETNX of Redis or ADD of Memcache). When the operation returns success, load db and reset the cache; otherwise, retry the whole get cache method.

    public String get(key) {
      String value = redis.get(key);
      if (value == null) { //Represents that the cache value has expired
          //Set a 3min timeout to prevent the next cache expiration from failing to load db when the del operation fails
      if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //Representative setting succeeded
               value = db.get(key);
                      redis.set(key, value, expire_secs);
                      redis.del(key_mutex);
              } else {  //At this time, it means that other threads at the same time have loaded dB and set it back to the cache. At this time, you can retry to obtain the cache value
                      sleep(50);
                      get(key);  //retry 
              }
          } else {
              return value;      
          }
 }

  • Cache avalanche: when the cache server restarts or a large number of caches fail in a certain period of time, it will also bring great pressure to the back-end system (such as DB).

    solve:

    The avalanche effect of cache failure has a terrible impact on the underlying system! Most system designers consider locking or queuing to ensure that a large number of threads will not read and write to the database at one time, so as to avoid a large number of concurrent requests falling on the underlying storage system in case of failure. There is also a simple scheme to spread the cache expiration time. For example, we can add a random value based on the original expiration time, such as 1-5 minutes random, so that the repetition rate of each cache expiration time will be reduced, and it is difficult to cause collective failure events.

    Normal:

    Avalanche:

Keywords: Redis

Added by 3s2ng on Tue, 21 Dec 2021 02:43:33 +0200

Popular Keywords

©2024 Programming VIP