Shulou(Shulou.com)06/01 Report--

This article will explain in detail the building steps of redis master-slave replication. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

The principle of master-slave replication

In a Redis cluster, several Redis servers are asked to replicate another Redis server. We define the replicated server as the master server (master), while the server that replicates the master server is called the slave server (slave). This mode is called master-slave replication mode.

Source: the role of master-slave replication in brief books

Master-slave replication, read-write separation, disaster recovery. One host is responsible for writing data, and multiple slaves are responsible for backing up the data. In high concurrency scenarios, even if the host is down, the slave can be used instead of the host to continue to work to avoid system performance problems caused by a single point of failure. Read-write separation makes applications that read more and write less perform better.

Master-slave replication architecture

At the base of Redis replication there is a very simple to use and configure master-slave replication that allows slave Redis servers to be exact copies of master servers.

It is really simple, one command: slaveof host ip host port, you can determine the master-slave relationship; a command:. / redis-sentinel sentinel.conf, you can turn on Sentinel monitoring.

Building is simple and maintenance is painful. In high concurrency scenarios, there will be many unexpected problems. We only have a clear understanding of the principle of replication, familiar with the host, from the changes after downtime. In order to cross these holes well. Each of the following steps is a small knowledge point, a small scene. Every time you finish each step, you will gain knowledge.

Architecture diagram: one master, two servants and one soldier (or multiple masters, multiple servants and more soldiers)

The shortcomings of master-slave replication

The biggest disadvantage of master-slave replication of Redis is delay, the host is responsible for writing, and the slave is responsible for backup. There is a certain delay in this process. When the system is very busy, the delay problem will be more serious, and the increase in the number of slave machines will also make this problem more serious.

Preparatory work before construction

Because of poverty, the author chooses to use one server to simulate three hosts. The only difference from a production environment is the ip address and the port port.

Step 1: make three copies of redis.conf, named redis6379.conf,redis6380.conf,redis6381.conf.

Step 2: modify the port port, pid file name, log file name, and rdb file name of the three files

Step 3: open three windows to simulate the three servers and open the redis service.

[root@itdragon bin] # cp redis.conf redis6379.conf [root@itdragon bin] # cp redis.conf redis6380.conf [root@itdragon bin] # cp redis.conf redis6381.conf [root@itdragon bin] # vim redis6379.conflogfile "6379.log" dbfilename dump_ 6379.rbb [root @ itdragon bin] # vim redis6380.confpidfile / var/run/redis_6380.pidport 6380logfile "6380.log" dbfilename dump_ 6380.rdb[ root @ itdragon bin] # vim redis6381.confport 6381pidfile / var/run/redis_6381.pidlogfile " 6381.log "dbfilename dump_ 6381.rbb [root @ itdragon bin] #. / redis-server redis6379.conf [root@itdragon bin] #. / redis-cli-h 127.0.0.1-p 6379127.0.0.1itdragon bin 6379 > keys * (empty list or set) [root@itdragon bin] #. / redis-server redis6380.conf [root@itdragon bin] #. / redis-cli-h 127.0.0.1-p 6380127.0.0.1 > keys * (empty List or set) [root@itdragon bin] #. / redis-server redis6381.conf [root@itdragon bin] #. / redis-cli-h 127.0.0.1-p 6381127.0.1 redis-server redis6381.conf 6381 > keys * (empty list or set) Master-Slave replication build steps

Basic construction

Step 1: query the master-slave replication information, select three ports respectively, and execute the command: info replication.

# 6379 port [root@itdragon bin] #. / redis-server redis6379.conf [root@itdragon bin] #. / redis-cli-h 127.0.0.1-p 6379127.0.1root@itdragon bin 6379 > info replication# Replicationrole:masterconnected_slaves:0.# 6380 port 127.0.0.1 root@itdragon bin 6380 > info replication# Replicationrole:masterconnected_slaves:0.# 6381 port 127.0.0.16381 > info replication# Replicationrole:masterconnected_slaves:0.

All three ports print the same information: the role:master role is that the number of master,connected_slaves:0 connected slaves is zero. Learn more about the meaning of parameters accessible connection: http://redisdoc.com/server/info.html

Step 2: select port 6379 and execute the command: set K1 v1

127.0.0.1 6379 > set K1 v1OK

Step 3: set the master-slave relationship, select port 6380 and port 6381 respectively, and execute the command: SLAVEOF 127.0.0.1 6379

# 6380 port 127.0.0.1 6379OK127.0.0.1:6381 > SLAVEOF 127.0.0.1 6379OK127.0.0.1:6380 > info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.# 6381 port 127.0.0.1 6379OK127.0.0.1:6381 > info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.# 6379 port 127.0. 0.1PUR 6379 > info replication# Replicationrole:masterconnected_slaves:2slave0:ip=127.0.0.1 Port=6380,state=online,offset=98,lag=1slave1:ip=127.0.0.1,port=6381,state=online,offset=98,lag=1.

The master-slave relationship has changed:

Information printed on ports 6380 and 6381: role:slave slave; ip address of master_host:127.0.0.1 host; port port of master_port:6379 host.

Information printed on port 6379: role:master host; connected_slaves:2 connected to two slaves; slaveX: ID, IP address, port number, connection status, slave library information

Step 4: full copy, select port 6380 and port 6381 respectively, and execute the command: get K1

# 6380 Port 127.0.0.1 6380 > get k1 "v1" # 6381 Port 127.0.0.1 6381 > get K1 "v1"

Both ports can print the value of K1, indicating that when the master-slave relationship is established, the slave has the data of the host.

Step 5: incremental copy, select port 6379 and execute the command: set K2 v2. Then select port 6380 and port 6381 respectively, and execute the command: get K2

# 6379 port 127.0.0.1 v2OK# 6379 > set k2 v2OK# 6380 port 127.0.0.1 get "v2" # 6381 port 127.0.0.1 get "v2"

The value of K2 can be printed on both ports, indicating that after the master-slave relationship is established, the new data added by the host will be copied to the slave.

Step 6: read and write separation of master and slave, select port 6380, execute command: set K3 v3

# 6380 Port 127.0.0.1 READONLY You can't write against a read only slave.# 6380 > set k3 v3 (error) READONLY You can't write against a read only slave.# 6379 Port 127.0.0.1 READONLY You can't write against a read only slave.# 6379 > set K3 v3OK

Writing from machine 6380 failed because of the read-write separation mechanism.

Step 7: in case of host downtime, select port 6379 and execute the command: shutdown

# 6379 Port 127.0.0.1 info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.# 6379 > SHUTDOWNnot connected > QUIT# 6380 Port 127.0.0.1 info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.# 6381 Port 127.0.0.1 info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.

From the printed results, we know: stand by from the machine.

Step 8: resume the host after downtime, select port 6379, restart the Redis service, and execute the command: set K4 v4. Select port 6380 and port 6381, respectively, and execute the command: get K4

# 6379 port [root@itdragon bin] #. / redis-server redis6379.conf [root@itdragon bin] #. / redis-cli-h 127.0.0.1-p 6379127.0.1root@itdragon bin 6379 > set k4 v4OK# 6380 port 127.0.0.1 root@itdragon bin 6380 > get k4 "v4" # 6381 port 127.0.0.1set 6381 > get k4 "v4"

Everything is fine after the mainframe is rebooted.

Step 9: recover from the outage, select port 6380 and execute the command: shutdown. Select port 6379 and execute the command: set K5 v5. Select port 6380, restart the Redis service and execute the command: get K5

# 6380 Port 127.0.0.1 root@itdragon bin 6380 > SHUTDOWNnot connected > QUIT [root@itdragon bin] #. / redis-server redis6380.conf [root@itdragon bin] #. / redis-cli-h 127.0.0.1-p 6380127.0.1 root@itdragon bin 6380 > info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.127.0.0.1:6380 > get K5 "v5" # 6379 port 127.0.0.1root@itdragon bin 6379 > set K5 v5OK

Everything has been fine since the plane went down. The author uses the redis.4.0.2 version. After reading other tutorials, after recovering from the outage, we can only synchronize the new data on the host, that is, K5 has no value, but the author has tried it again and again. Keep a memo!

Step 10: de-neutralize the idea, select port 6380, execute the command: SLAVEOF 127.0.0.1 6381. Select port 6381 and execute the command: info replication

# 6380 Port 127.0.0.1 6381OK# 6380 > SLAVEOF 127.0.0.1 6381OK# 6381 Port 127.0.0.1 info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.connected_slaves:1slave0:ip=127.0.0.1,port=6380,state=online,offset=1677,lag=1.

Although 6381 is the host of 6380 and the slave of 6379. In Redis's eyes, 6381 is still a slave. One host is equipped with multiple slaves, and one slave is equipped with multiple slaves, thus realizing a huge cluster architecture. At the same time, it also reduces the pressure on a host, but the disadvantage is to increase the latency between servers.

From the upper position of the machine

Simulates the scene where the host goes down and manually encourages the slave machine to go up. First restore the three ports to 6379 is the host, and 6380 and 6381 are the slave architecture.

From the upper machine step:

Step 1: simulate host outage, select port 6379, and execute command: shutdown

Step 2: disconnect the master-slave relationship, select port 6380, and execute the command: SLAVEOF no one

Step 3: rebuild the master and slave, select port 6381, and execute the command: info replication,SLAVEOF 127.0.0.1 6380

Step 4: before the host is restored, select port 6379, restart the Redis service, and execute the command: info replication

After the outage of the 6379 host, 6380 disconnected the master-slave relationship, and 6381 was still on standby at the beginning. Later, after joining the 6380 host, the 6379 host came back when it was a lonely old man, the commander of the bears.

# 6379 Port 127.0.0.1 v6OK# 6379 > SHUTDOWNnot connected > QUIT# 6380 Port 127.0.0.1 SLAVEOF no oneOK127.0.0.1:6380 > set k6 v6OK# 6381 Port 127.0.0.1 SLAVEOF no oneOK127.0.0.1:6380 > info replication# Replicationrole:slavemaster_host:127.0.0.1master_port:6379.127.0.0.1:6381 > SLAVEOF 127.0.0.1 6380OK127.0.0.1:6381 > get K6 "V6" Sentinel Monitoring

It is impossible for anyone to stare at it in real time, and it is impossible to get up in the middle of the night to rebuild the master-slave relationship. Driven by such demand, the Sentinel mode is coming!

The Sentinel has three major tasks:

1 Monitoring: the Sentinel will constantly check whether your Master and Slave are working properly.

2 reminder: when there is a problem with a monitored Redis, the Sentinel can send a notification to the administrator or other application through API

3 failure migration: if there is a problem with a host, the Sentinel will automatically set one of the slaves under the host as the new host and let other slaves establish a master-slave relationship with the new host.

Steps to build the Sentinel:

Step 1: open a new window, named sentinel, to facilitate the observation of Sentinel log messages

Step 2: create a sentinel.conf file, or you can copy a copy from the unzipped folder of redis.

Step 3: set the host and upper rules for monitoring, edit sentinel.conf, and enter sentinel monitor itdragon-redis 127.0.0.1 6379 1 to save exit. Explanation: specify the ip address of the monitoring host, port port, and the number of votes obtained.

Step 4: start the sentinel at the front end and execute the command:. / redis-sentinel sentinel.conf.

Step 5: simulate the host outage, select 6379 window and execute the command: shutdown.

Step 6: wait for the slave vote and view the print information in the sentinel window.

Step 7: start the 6379 server

Syntax structure: sentinel monitor custom database name host ip host port votes

If the number of votes obtained from the machine is greater than the set value, it will become the new host. If the previous host is restored

If the sentinel goes down, too? Then put a few more sentinels and monitor each other.

# sentinel window [root@itdragon bin] # vim sentinel.confsentinel monitor itdragon-redis 127.0.0.1 6379 1 [root@itdragon bin] #. / redis-sentinel sentinel.conf.21401:X 29 Nov 15VERV 3915.052 * + slave slave 127.0.1RV 6381 127.0.0.1 6381 @ itdragon-redis 127.0.1638021401WR 29 Nov 15RU 3915.052 * + slave slave 127.0.0.1 Rue 6379 127.0 .0.1 6379 @ itdragon-redis 127.0.0.1 638021401 itdragon-redis X 29 Nov 15 Nov 39 sdown slave 45.081 # + sdown slave 127.0.0.1 @ itdragon-redis 127.0.0.1 @ itdragon-redis 127.0.0.1 @ 638021401 Nov 1640 Nov 52.055 #-sdown slave 127.0.1 @ itdragon-redis 127.0.1.638021401 sdown slave 29 Nov 41V 02.028 * + convert-to -slave slave 127.0.0.1 slave slave 6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380.# 6379 port 127.0.0.1 SHUTDOWNnot connected > QUIT# 6380 port 127.0.0.1 SHUTDOWNnot connected > info replication# Replicationrole:masterconnected_slaves:1slave0:ip=127.0.0.1 Port=6381,state=online,offset=72590,lag=0.# 6381 port 127.0.0.1 6381 >.

+ slave: a new slave server has been identified and associated by Sentinel.

+ sdown: the given instance is now subjectively offline.

-sdown: the given instance is no longer in the subjective offline state.

Summary

1 View master-slave replication relationship command: info replication

2 set master-slave relationship command: slaveof host ip host port

3 Open Sentinel mode command:. / redis-sentinel sentinel.conf

4 Master-slave replication principle: full assignment at first, followed by incremental assignment

5 three major tasks in Sentinel mode: monitoring, reminding, and automatic fault migration

On the redis master-slave replication steps to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.