concept

Master Slave replication refers to copying data from one Redis server to other Redis servers. The former is called master/leader and the latter is called slave/follower; Data replication is unidirectional and can only be from master node to Slave node. Master mainly writes, Slave mainly reads.

Master-slave copy, read-write separation! 80% of the cases are read operations! Reduce server pressure!

By default, each Redis server is the master node; And a master node can have multiple slave nodes (or no slave nodes), but a slave node has and has only one master node.

The main functions of master-slave replication include

• Data redundancy: master-slave replication realizes the hot backup of data, which is a data redundancy method other than persistence.
• Fault recovery: when the master node has problems, the slave node can provide services to achieve rapid fault recovery; It is actually a kind of service redundancy.
• 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 to the master node when writing Redis data, and the application connects to the slave node when reading Redis data), sharing the server load; Especially in the scenario of less writing and more reading, the concurrency of Redis server can be greatly improved by sharing the load among multiple nodes.
• 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 is the basis for Redis high availability.

Generally speaking, to apply redis to engineering projects, it is absolutely impossible to use only one redis (downtime). The reasons are as follows:
1. Structurally, a single redis server will have a single point of failure, and one server needs to handle all the request loads, which is under great pressure.
2. In terms of capacity, the memory capacity of a single redis server is limited. Even if the memory capacity of a redis server is 256GB, all memory can not be used as redis storage memory. Generally speaking, the maximum memory used by a single redis should not exceed 20GB.

Environment configuration

You only need to configure the slave database, not the master database, because by default, each Redis server is the master node.

127.0.0.1:6379> info replication #View information about the current library
# Replication
role:master #Role master
connected_slaves:0 #Number of slave Libraries
master_failover_state:no-failover
master_replid:7e06d29925419238aac9519cfa2025680a0dca55
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Modify 3 profiles:
1. Port
2,pid
3. log file name
4. rdb backup file name

One master and two slaves

By default, each redis server is the primary node; We just need to configure the slave node.

Mode 1: command configuration (temporary)

############ Slave node 1 ###########
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 #Set the slave node of the master node (Master)
OK
127.0.0.1:6380> info replication
# Replication
role:slave #The current role is a slave node
master_host:127.0.0.1 #Master node information
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_read_repl_offset:14
slave_repl_offset:14
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:16682d498ce34c8fe6785dc0b4e5b44afcc2e2ef
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

############ Slave node 2 ###########
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379 #Set the slave node of the master node (Master)
OK
127.0.0.1:6381> info replication
# Replication
role:slave #The current role is a slave node
master_host:127.0.0.1 #Master node information
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:56
slave_repl_offset:56
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:16682d498ce34c8fe6785dc0b4e5b44afcc2e2ef
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:43
repl_backlog_histlen:14

############ Master node ###########
127.0.0.1:6379> info replication
# Replication
role:master #The current character is the primary node
connected_slaves:2 #Number of slave nodes
slave0:ip=127.0.0.1,port=6380,state=online,offset=70,lag=0 #Slave node information
slave1:ip=127.0.0.1,port=6381,state=online,offset=70,lag=1 #Slave node information
master_failover_state:no-failover
master_replid:16682d498ce34c8fe6785dc0b4e5b44afcc2e2ef
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:70
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:70

Method 2: configuration file (permanent)
Modify the configuration file and set the master node information

details
The master node can write, but the slave node cannot write and can only read! All information and data in the master node will be automatically saved by the slave node!

############### Master node (writable) ###############
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> get k1
"v1"

############### Slave node (non writable, read only) ###############
127.0.0.1:6380> keys *
1) "k1"
127.0.0.1:6380> get k1
"v1"
127.0.0.1:6380> set k2 v2
(error) READONLY You can't write against a read only replica.

be careful:
1. When the master node goes down, the slave node is still connected to the master node as a slave node and has no write permission; When the master node reconnects, the slave node can still directly obtain the information written by the master node!
2. If the slave node is configured with the command line, the master-slave configuration will fail when the slave node is restarted! But when reconfigured as a slave node, the value will be obtained from the master node immediately!
3. If the slave node is configured in the configuration file, the slave node goes down and the master node writes. When the slave node reconnects, the value will be obtained from the master node. The previous master node write operation information still exists in the slave node!

Replication principle

After Slave is successfully started and connected to the Master, it will send a sync synchronization command!
After receiving the synchronization command, the Master starts the background save process and collects all received commands for modifying the dataset. After the background process is executed, the Master will transfer the whole data file to Slave and complete a synchronization!

Full copy: after receiving the database file data, the Slave service saves it and loads it into memory.

Incremental replication: the Master continues to transmit all new collected modification commands to Slave in turn to complete synchronization.

However, as long as the Master is reconnected, a full synchronization (full replication) will be performed automatically. The data must be seen in Slave.

Manually configure the master node after downtime

Link model: M-S(M)-S. when the first master node survives, the S(M) node is a slave node and cannot write!

When the first primary node goes down, you can manually set the node as the primary node:

slaveof no one #Make yourself the master node

If the first primary node is restored, it needs to be reconfigured.