Detailed explanation of redis master-slave replication

This chapter introduces a powerful feature of Redis-master-slave replication. A master host can have multiple slave machines. And a slave slave can have multiple slave slaves. This continues to form a powerful multi-level server cluster architecture (high scalability). It can avoid Redis single point of failure and achieve disaster recovery effect (high availability). The architecture of separation of reading and writing satisfies concurrent application scenarios with more reading and less writing. Recommended: redis video tutorial

##The role of master-slave replication

Master-slave replication, read-write separation, disaster recovery recover. One host is responsible for writing data, and multiple slave machines are responsible for backing up data. In high-concurrency scenarios, even if the host machine hangs up, the slave machine can be used to continue working in place of the host machine to avoid system performance problems caused by single points of failure. The separation of reading and writing enables better performance for applications that read more and write less.

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 indeed simple. One command: slaveof host ip host port can determine the master-slave relationship; one command: ./redis-sentinel sentinel.conf Sentinel monitoring can be turned on.

Building is simple, but maintenance is painful. In high concurrency scenarios, many unexpected problems may arise. We only have a clear understanding of the principle of replication, familiarity with the host machine, and the changes after the slave machine goes down. Only then can we overcome these pitfalls well. Each step below is a small knowledge point and a small scene. Every time you complete a step, you will gain knowledge.

Architecture diagram: one master, two servants and one soldier (you can also have multiple masters, multiple servants and multiple soldiers)

Preparation before building Work

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

Step 1: Copy three copies of redis.conf, the names are redis6379.conf, redis6380.conf, redis6381.conf

Step 2: Modify the ports of the three files , pid file name, log file name, rdb file name

Step 3: Open three windows to simulate three servers and start 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.log"
dbfilename dump_6379.rdb
[root@itdragon bin]# vim redis6380.conf
pidfile /var/run/redis_6380.pid
port 6380
logfile "6380.log"
dbfilename dump_6380.rdb
[root@itdragon bin]# vim redis6381.conf
port 6381
pidfile /var/run/redis_6381.pid
logfile "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 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> keys *
(empty list or set)
[root@itdragon bin]# ./redis-server redis6381.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6381
127.0.0.1:6381> keys *
(empty list or set)

Master-slave replication setup steps

Basic setup

Step 1: Query the master From the replication information, select three ports respectively and execute the command: info replication.

# 6379 端口
[root@itdragon bin]# ./redis-server redis6379.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
......

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
......

All three ports print the same information: role:master The role is master, connected_slaves:0 The number of connected slaves is zero. To learn more about the meaning of parameters, please visit the 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 v1
OK

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 端口
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 端口
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 端口
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; master_host:127.0.0.1 ip address of the host; master_port:6379 port of the host.

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

No. Step 4: Copy in full, select port 6380 and port 6381 respectively, execute the command: get k1

# 6380 端口
127.0.0.1:6380> get k1
"v1"

# 6381 端口
127.0.0.1:6381> get k1
"v1"

Both ports can print the value of k1, indicating that when establishing a master-slave relationship, the slave has the master. The data.

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 端口
127.0.0.1:6379> set k2 v2
OK

# 6380 端口
127.0.0.1:6380> get k2
"v2"

# 6381 端口
127.0.0.1:6381> get k2
"v2"

Both ports can print the value of k2, indicating that after the master-slave relationship is established, the new data added by the host will be copied to the slave.

Step 6: Master-slave read-write separation, select port 6380, execute the command: set k3 v3

# 6380 端口
127.0.0.1:6380> set k3 v3
(error) READONLY You can't write against a read only slave.

# 6379 端口
127.0.0.1:6379> set k3 v3
OK

The slave 6380 failed to write because of the read-write separation mechanism.

Step 7: If the host is down, select port 6379 and execute the command: shutdown

# 6379 端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

From the printed results, we know that the slave is on standby

Eight steps: Recover the host after it crashes. 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 端口
[root@itdragon bin]# ./redis-server redis6379.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> set k4 v4
OK

# 6380 端口
127.0.0.1:6380> get k4
"v4"

# 6381 端口
127.0.0.1:6381> get k4
"v4"

After the host restarts, everything is normal.

Step 9: Recover after the slave machine crashes, 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 端口
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 端口
127.0.0.1:6379> set k5 v5
OK

从机宕机后，一切正常。笔者用的是redis.4.0.2版本的。看过其他教程，从机宕机恢复后，只能同步主机新增数据，也就是k5是没有值的，可是笔者反复试过，均有值。留着备忘！

第十步：去中性化思想，选择6380端口，执行命令：SLAVEOF 127.0.0.1 6381。选择6381端口，执行命令：info replication

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6381
OK

# 6381 端口
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
......

虽然6381 是6380的主机，是6379的从机。在Redis眼中，6381依旧是从机。一台主机配多台从机，一台从机在配多台从机，从而实现了庞大的集群架构。同时也减轻了一台主机的压力，缺点是增加了服务器间的延迟。

从机上位

模拟主机宕机，人为手动怂恿从机上位的场景。先将三个端口恢复成6379是主机，6380和6381是从机的架构。

从机上位步骤：

第一步：模拟主机宕机，选择6379端口，执行命令：shutdown

第二步：断开主从关系，选择6380端口，执行命令：SLAVEOF no one

第三步：重新搭建主从，选择6381端口，执行命令：info replication，SLAVEOF 127.0.0.1 6380

第四步：之前主机恢复，选择6379端口，重启Redis服务，执行命令：info replication

在6379主机宕机后，6380从机断开主从关系，6381开始还在原地待命，后来投靠6380主机后，6379主机回来了当它已是孤寡老人，空头司令。

# 6379端口

127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
127.0.0.1:6380> SLAVEOF no one
OK
127.0.0.1:6380> set k6 v6
OK

# 6381端口
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"

哨兵监控

从机上位是需要人为控制，在生产环境中是不可取的，不可能有人实时盯着它，也不可能大半夜起床重新搭建主从关系。在这样的需求促使下，哨兵模式来了！！！

哨兵有三大任务：

1 监控：哨兵会不断地检查你的Master和Slave是否运作正常

2 提醒：当被监控的某个Redis出现问题时, 哨兵可以通过API向管理员或者其他应用程序发送通知

3 故障迁移：若一台主机出现问题时，哨兵会自动将该主机下的某一个从机设置为新的主机，并让其他从机和新主机建立主从关系。

哨兵搭建步骤：

第一步：新开一个窗口，取名sentinel，方便观察哨兵日志信息

第二步：创建sentinel.conf文件，也可以从redis的解压文件夹中拷贝一份。

第三步：设置监控的主机和上位的规则，编辑sentinel.conf，输入 sentinel monitor itdragon-redis 127.0.0.1 6379 1 保存退出。解说：指定监控主机的ip地址，port端口，得票数。

第四步：前端启动哨兵，执行命令：./redis-sentinel sentinel.conf。

第五步：模拟主机宕机，选择6379窗口，执行命令：shutdown。

第六步：等待从机投票，在sentinel窗口中查看打印信息。

第七步：启动6379服务器，

语法结构：sentinel monitor 自定义数据库名 主机ip 主机port 得票数

若从机得票数大于设置值，则成为新的主机。若之前的主机恢复后，

如果哨兵也宕机了？？？那就多配几个哨兵并且相互监控。

# sentinel窗口
[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 29 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 29 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 29 Nov 15:39:45.081 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380

21401:X 29 Nov 16:40:52.055 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 16:41:02.028 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
......

# 6379端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
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端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
......

+slave ：一个新的从服务器已经被 Sentinel 识别并关联。

+sdown ：给定的实例现在处于主观下线状态。

-sdown ：给定的实例已经不再处于主观下线状态。

主从复制的原理

全量复制

实现原理：建立主从关系时，从机会给主机发送sync命令，主机接收命令，后台启动的存盘进程，同时收集所有用于修改命令，传送给从机。

增量复制

实现原理：主机会继续将新收集到的修改命令依次传给从机，实现数据的同步效果。

主从复制的缺点

Redis的主从复制最大的缺点就是延迟，主机负责写，从机负责备份，这个过程有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，从机器数量的增加也会使这个问题更加严重。

Summary

1 View the master-slave replication relationship command: info replication

2 Set the master-slave relationship command: slaveof host ip host port

3 Turn on the sentinel mode command: ./redis-sentinel sentinel.conf

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

5 Three major tasks of sentinel mode: monitoring , reminder, automatic fault migration

For more redis knowledge, please pay attention to the redis database tutorial column.

The above is the detailed content of Detailed explanation of redis master-slave replication. For more information, please follow other related articles on the PHP Chinese website!