Redis master Copy
This chapter describes a powerful feature of Redis – Master-slave replication. A master host can have multiple slave from the computer. And a slave from the machine can also have multiple slave from the machine. This continues to form a powerful multi-level server cluster architecture (high expansion). Can avoid Redis single point of failure, achieve disaster recovery effect (high availability). Read-write separation of the architecture, to meet the read-write and less concurrent application scenarios. the role of master-slave replication
Master-slave Copy, read-write separation, disaster recovery. One host is responsible for writing data, and many are responsible for backing up data from the computer. In a high concurrency scenario, even if the host is hung, you can use the machine instead of the host to continue to work, to avoid a single point of failure to cause system performance problems. Read-write separation, so that less reading and writing application can be better. Master-slave replication Architecture
At the base of Redis replication There are a very simple to use and configure Master-slave replication that allows slave Re DIS servers to is exact copies of master servers.
The official said that building the master-slave architecture is a very simple. Official connection: Https://redis.io/topics/replication
is really simple, a 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.
It is simple to build and maintenance is painful. In a high concurrency scenario, there are a lot of unexpected problems coming up. We only understand the principle of duplication, familiar with the mainframe, from the machine down after the change. To be able to cross these pits well. Each of the following steps is a small point of knowledge, a small scene. Every step you get, you will gain knowledge. Come on... Daydayup ...
Architecture diagram: A Master Two servants (also can more than the master more than soldiers)
preparatory work before the erection
Because of poor, I chose to use a server to simulate three hosts. The difference from the production environment is only that the IP address and port ports are different.
First step: Copy the redis.conf three copies, the name is, redis6379.conf,redis6380.conf,redis6381.conf
Step Two: Modify the port port of three files, PID file name, log file name, RDB file name
Step three: Open three windows to simulate 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.conf logfile] 6379.lo G "Dbfilename Dump_6379.rdb [Root@itdragon bin]# vim redis6380.conf pidfile/var/run/redis_6380.pid Port 6380 logfile" 638 0.log "Dbfilename Dump_6380.rdb [Root@itdragon bin]# vim redis6381.conf Port 6381 pidfile/var/run/redis_6381.pid "6381.log" Dbfilename Dump_6381.rdb [Root@itdragon bin]#./redis-server redis6379.conf [Root@itdragon bin]#./redis-cli -H 127.0.0.1-p 6379 127.0.0.1:6379> keys * (empty list or set) [Root@itdragon bin]#./redis-server redis6380.conf [ro Ot@itdragon bin]#./redis-cli-h 127.0.0.1-p 6380 127.0.0.1:6380> keys * (empty list or set) [Root@itdragon bin]#./re Dis-server redis6381.conf [Root@itdragon bin]#./redis-cli-h 127.0.0.1-p 6381 Keys * (127.0.0.1:6381> list or Set)
Master-slave replication setup Steps
Foundation Build (๑őдő) b
The first step: Query master-slave replication information , select three ports, 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 637 9
127.0.0.1:6379> Info replication
# replication
role:master
connected_slaves:0
...
# 6380 Port
127.0.0.1:6380> info Replication
# replication
role:master
connected_slaves : 0.
# 6381 Port
127.0.0.1:6381> info Replication
# replication
role:master
connected_slaves:0
......
All three ports print the same information: role:master role is master,connected_slaves:0 The number of connections from the machine is zero. Learn more about parameter meaning accessible connections: http://redisdoc.com/server/info.html
Step Two: Select Port 6379, execute command: Set K1 v1
127.0.0.1:6379> set K1 v1
OK
Step Three: Set the master-slave relationship , select 6380 ports and 6381 ports, execute the command: slaveof 127.0.0.1 6379
# 6380 Port
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
127.0.0.1:6380> info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
... # 6381 Port
127.0.0.1:6381> slaveof 127.0.0.1 6379
OK
127.0.0.1:6381> info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
... # 6379 Port
127.0.0.1:6379> info Replication
# replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=98,lag=1
slave1:ip=127.0.0.1,port=6381,state= Online,offset=98,lag=1 ...
The master-slave relationship has changed:
6380-Port and 6381-Port printing information: Role:slave from the machine, master_host:127.0.0.1 host IP address, master_port:6379 host port.
6379-Port printing information: Role:master host Connected_slaves:2 two from the machine; Slavex:id, IP address, port number, connection status, from library information
Fourth Step: Full Volume replication , select 6380 ports and 6381 ports, execute command: Get K1
# 6380 Port
127.0.0.1:6380> get K1
"v1"
# 6381 Port
127.0.0.1:6381> get K1
"v1"
Two ports can print the value of K1, indicating that in the establishment of the master-slave relationship, from the machine will have the host data.
Step Fifth: Incremental replication , select 6379 port, execute command: Set K2 v2. Then select 6380 ports and 6381 ports, and execute the command: Get K2
# 6379 Port
127.0.0.1:6379> set K2 v2
OK
# 6380 Port
127.0.0.1:6380> get K2
' v2 '
# 6381 Port
127.0.0.1:6381> get K2
"v2"
Two ports can print the value of K2, indicating that after the master-slave relationship, the host new data will be copied to the machine.
Sixth step: master-slave read and write separation , select 6380 port, execute command: Set K3 v3
# 6380 Port
127.0.0.1:6380> set K3 v3
(Error) READONLY you can ' t write against a read only slave.
# 6379 Port
127.0.0.1:6379> set K3 v3
OK
The failure to write from Machine 6380 is due to a read-write separation mechanism.
Step Seventh: Host Downtime , select 6379 port, execute command: shutdown
# 6379 Port
127.0.0.1:6379> SHUTDOWN not
connected> QUIT
# 6380 Port
127.0.0.1:6380> Info Replication
# replication
role:slave
master_host:127.0.0.1
master_port:6379
... # 6381 Port
127.0.0.1:6381> info Replication
# replication
role:slave
master_host:127.0.0.1
master_port:6379
...
From the results of the print: Standby from the machine in situ
Eighth: Host downtime after recovery , select 6379 ports, restart the Redis service, execute the command: set K4 v4. Select 6380 ports and 6381 ports, execute command: Get K4
# 6379 Port
[Root@itdragon bin]#./redis-server redis6379.conf
[Root@itdragon bin]#./redis-cli-h 127.0.0.1-p 6 379
127.0.0.1:6379> Set K4 v4
OK
# 6380 port
127.0.0.1:6380> get K4
"v4"
# 6381 Port C25/>127.0.0.1:6381> get K4
"v4"
After the host reboot, everything is OK.
nineth step: Recover from Machine Downtime , select 6380 port, execute command: shutdown. Select Port 6379 to execute the command: Set K5 v5. Select Port 6380, restart Redis service and execute command: Get K5
# 6380 Port
127.0.0.1:6380> SHUTDOWN not
connected> QUIT
[Root@itdragon bin]#./redis-server redis6380.conf
[Root@itdragon bin]#./redis-cli-h 127.0.0.1-p 6380 127.0.0.1:6380>
info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
... 127.0.0.1:6380> get K5
"v5"
# 6379 Port
127.0.0.1:6379> set K5 v5
OK
Everything is fine after the machine has crashed. The author uses the redis.4.0.2 version. Read other tutorials, from the machine down after the recovery, can only sync host new data, that is, K5 is no value, but the author repeatedly tried, all have a value. Keep a memo.
Tenth step: to neuter the idea , choose 6380 port, execute command: slaveof 127.0.0.1 6381. Select Port 6381, execute command: INFO replication
# 6380 Port
127.0.0.1:6380> slaveof 127.0.0.1 6381
OK
# 6381 Port
127.0.0.1:6381> Info Replication
# replication
role:slave
master_host:127.0.0.1
master_port:6379
...
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1677,lag=1
...
Although 6381 is 6380 of the host, is 6379 from the machine. In the eyes of Redis, 6381 is still from the machine. A host with multiple units from the machine, one from the machine in a number of units from the machine, thus realizing a huge cluster structure. Also reduces the pressure of a host, the disadvantage is to increase the delay between the server. from the Machine Superior (๑őдő) b
Simulation of host downtime, manually instigated from the computer scene. First, restore three ports to 6379 is the host, 6380 and 6381 are from the machine's schema.
Step from the computer:
Step one: Simulate host downtime, select Port 6379, execute command: shutdown
Step two: Disconnect the master-slave relationship, select 6380 port, execute command: slaveof no one
Step three: Rebuild Master and subordinate, select 6381 port, execute command: info replication,slaveof 127.0.0.1 6380
Fourth: Before host recovery, select 6379 port, restart Redis service, execute command: INFO replication
In 6379 mainframe downtime, 6380 from the machine disconnect from the master-slave relationship, 6381 is still in situ standby, and then take refuge in 6380 host, 6379 host back when it is already an elderly, short commander.
# 6379 Port
127.0.0.1:6379> SHUTDOWN not
connected> QUIT
# 6380 Port
127.0.0.1:6380> slaveof No one
OK
127.0.0.1:6380> set K6 v6
OK
# 6381 port
127.0.0.1:6381> info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
... 127.0.0.1:6381> slaveof 127.0.0.1 6380
OK
127.0.0.1:6381> get K6
"V6"
Sentinel Surveillance (๑őдő) b
From the machine is the need for artificial control, in the production environment is not desirable, there can be no real time to stare at it, it is impossible to get up in the middle of the night to rebuild the master-slave relationship. In this demand prompted, the Sentinel mode came ...
The Sentinel has three major tasks:
1 Surveillance : The Sentinel will constantly check to see if your master and slave are functioning properly.
2 reminder : When a monitored redis problem occurs, the Sentinel can send notifications to administrators or other applications via the API
3 Failover : If a host has a problem, the sentry will automatically set the host to a machine from the new host, and let other from the machine and the new host to establish Master-slave relationship.
Sentinel Setup steps:
The first step: open a new window, named Sentinel, easy to observe Sentinel log information
Step Two: Create the sentinel.conf file, or copy one of the Redis's unpacked folders.
The third step: Set up monitoring host and upper rules, edit sentinel.conf, Input Sentinel monitor Itdragon-redis 127.0.0.1 6379 1 Save exit. Explanation: Specify the IP address of the monitoring host, port, the number of votes.
Fourth step: Front start Sentry, execute command:./redis-sentinel sentinel.conf.
Fifth step: Simulate host downtime, select 6379 windows, execute command: shutdown.
Step sixth: Wait to vote from the machine, and view the printed information in the Sentinel window.
Seventh step: Start 6379 server,
Syntax structure: Sentinel monitor custom database name host IP host Port ticket number
If the number of votes from the machine is greater than the set value, it becomes the new host. If the previous host is restored,
If the Sentinels are down ... Then go with a few sentinels and monitor each other.
# Sentinel Window [Root@itdragon bin]# vim sentinel.conf Sentinel Monitor Itdragon-redis 127.0.0.1 6379 1 [Root@itdragon bin]#
./redis-sentinel sentinel.conf ... 21401:x Nov 15:39:15.052 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ itdragon-redis 127.0.0.1 6380 21401:x Nov 15 : 39:15.052 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380 21401:x-Nov 15:39:45.081 # +SDO WN slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380 21401:x Nov 16:40:52.055 #-sdown slave 127.0.0 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380 21401:x 1:6379 Nov 16:41:02.028 * +convert-to-slave slave 127.0.0.1:637 9 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380 ... # 6379 port 127.0.0.1:6379> SHUTDOWN not connected> QUIT # 63 80 Port 127.0.0.1:6380> Info Replication # replication Role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6381, State=online,offset=72590,lag=0 ... # 6381 port 127.0.0.1:6381> Info replication # replication Role:slave master_host:127.0.0.1 master_port:6380 ...
+slave: A new from the server has been Sentinel identified and associated.
+sdown: The given instance is now in a subjective off-line state.
-sdown: The given instance is no longer in the subjective off-line state.
More content to visit the official website: Https://redis.io/topics/sentinel
principle of Master-slave copying
Full Volume replication
Implementation principle: Establish Master-slave relationship, from the opportunity to send sync commands to the host, host receiving commands, background to start the disk process, while collecting all for the change command , transmitted to the machine.
Incremental Replication
Implementation principle: The host will continue to the new collection of modified commands to the machine in turn, to achieve the data synchronization effect. Disadvantages of Master-slave replication
Redis The biggest drawback is the delay, the host is responsible for writing, from the machine responsible for backup, the process has a certain delay, when the system is busy, delay problem will be more serious, from the increase in the number of machines will also make this problem more serious. 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 copy principle: Start with a full value assignment, followed by an incremental assignment
5 Sentinel mode three major tasks: monitoring, alerting, automatic fault migration
Redis's master and slave copy here is over, there is nothing wrong to welcome corrections. The next chapter Redis the cluster to build and integrate spring