Redis主从复制——非哨兵模式

Redis主从复制——非哨兵模式

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点 (master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。 Master以写为主，Slave 以读为主。

默认情况下，每台Redis服务器都是主节点。

且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用主要包括：

1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 （即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在读多写少的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4、高可用（集群）基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：

1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较 大；

2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"读多写少"。

主从复制，读写分离，80%的场景都是读操作，减缓服务器的压力。

最低配置，一主二从。

环境配置

只配置从库，不用配置主库

127.0.0.1:6379> info replication	# 查看当前库的信息
# Replication
role:master							# 角色
connected_slaves:0					# 从节点数
master_replid:497ad0b76b7e4a7a4f7c96ee34d7b47f0d907dc2
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

部署伪集群

全部都部署到同一台机器上。

[root@huan bin]# cp redis.conf redis10.conf
[root@huan bin]# cp redis.conf redis20.conf
[root@huan bin]# cp redis.conf redis30.conf

修改这三个配置文件的内容如下

logfile "10.log"
dbfilename dump10.rdb
pidfile /var/run/redis30.pid
port 6310

其他两个配置文件按redis10.conf的进行修改，分别对应各自的数字。

修改完成之后，分别按照对应的启动脚本启动。

[root@huan bin]# ./redis-server redis10.conf 
[root@huan bin]# ./redis-server redis20.conf 
[root@huan bin]# ./redis-server redis30.conf

查看进程

[root@huan bin]# ps -ef | grep redis
root       1174      1  0 01:40 ?        00:00:30 redis-server 127.0.0.1:6379
root       1424   1183  0 08:19 pts/1    00:00:00 redis-cli
root       1525      1  0 09:02 ?        00:00:00 ./redis-server 127.0.0.1:6310
root       1531      1  0 09:02 ?        00:00:00 ./redis-server 127.0.0.1:6320
root       1538      1  0 09:02 ?        00:00:00 ./redis-server 127.0.0.1:6330
root       1543   1149  0 09:02 pts/0    00:00:00 redis-cli
root       1546   1453  0 09:03 pts/2    00:00:00 grep --color=auto redis

[root@huan src]# redis-cli -p 6310
127.0.0.1:6310> info replication
# Replication
role:master
connected_slaves:0

使用redis-cli连上10这台服务器上可以看到，节点角色为master，还记得上面说过的吗？

默认情况下，每台Redis服务器都是主节点。

配置主从的时候，只需要配从机就好了。使用SLAVEOF命令即可。

127.0.0.1:6310> SLAVEOF host port
127.0.0.1:6330> SLAVEOF 127.0.0.1 6379
OK

可以看到这里已经是OK了，再次查看info信息

127.0.0.1:6310> info replication
# Replication
role:slave
master_host:localhost
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:0
master_link_down_since_seconds:1598794183
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:286a6da521875dfdde01d2146fe7cfad07c8fceb
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

查看主节点的节点信息。

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6310,state=online,offset=0,lag=0
master_replid:40dac278258af6dbd6402b153e5d94d39c742102
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0

发现目前已经有一个slave节点加入了集群中。

接下来20，30主机也都使用SLAVEOF 127.0.0.1 6379命令做同样操作，然后再次查看节点状态。

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:3
slave0:ip=127.0.0.1,port=6310,state=online,offset=84,lag=1
slave1:ip=127.0.0.1,port=6320,state=online,offset=84,lag=0
slave2:ip=127.0.0.1,port=6330,state=online,offset=84,lag=0
master_replid:40dac278258af6dbd6402b153e5d94d39c742102
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:84
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:84

可以看到，connected_slaves:3，说明3个节点全部加入了集群中。

注意：

• 因为这里是演示，所以使用了redis-cli -p port的形式来连接，在实际的生产环境中，从机的配置信息都是写到对应的配置文件中。

• 全部的redis节点都在同一台主机上，在实际的生产环境中，各个redis节点都是部署到不同的机器上。否则，一旦这个机器宕机，或者网络故障等，整个redis集群将全部瘫痪，无法再对外提供服务。

那么，在配置文件中应该如何配置？

以vim形式查看redis.conf文件，找到REPLICATION这里。

################################# REPLICATION #################################
# Master-Replica replication. Use replicaof to make a Redis instance a copy of
# another Redis server. A few things to understand ASAP about Redis replication.
#
#   +------------------+      +---------------+
#   |      Master      | ---> |    Replica    |
#   | (receive writes) |      |  (exact copy) |
#   +------------------+      +---------------+

主机的IP和端口
# replicaof <masterip> <masterport>

主机的密码
# masterauth <master-password>

部署细节

主机可以设置key(注意可以写)，从机不能设置值key(从机只能读)。主机中的所有信息和数据，都会自动被从机保存。

# 主机 <<<<<<
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> 

# 从机 <<<<<<
127.0.0.1:6310> get k1
"v1"
127.0.0.1:6310> set k2 v2	# 从机设置值报错
(error) READONLY You can't write against a read only replica.

测试高可用。

127.0.0.1:6379> SHUTDOWN
not connected> 

[root@huan bin]# ps -ef | grep redis
root       1642      1  0 09:35 ?        00:00:01 redis-server 127.0.0.1:6310
root       1648      1  0 09:35 ?        00:00:01 redis-server 127.0.0.1:6320
root       1654      1  0 09:35 ?        00:00:01 redis-server 127.0.0.1:6330
root       1719   1700  0 09:49 pts/1    00:00:00 redis-cli -p 6310
root       1727   1667  0 09:53 pts/0    00:00:00 redis-cli -p 6320
root       1751   1732  0 09:53 pts/2    00:00:00 redis-cli -p 6330
root       1778   1756  0 09:54 pts/3    00:00:00 grep --color=auto redis

# 从机 <<<<<<
127.0.0.1:6310> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down # <<<< 主机状态，down

127.0.0.1:6330> get k1
"v1"

可以看到现在不管是哪个从节点，还是能够获取值，只是不能写入值了。

通过查看三台从机的info replication信息，发现三个从机都是slave状态，并没有某个节点被选举为master，这又是为什么呢？

因为如果要实现redis的高可用，需要redis实现哨兵模式才能够成为高可用的redis集群。

接下来继续测试，如果我们手动恢复主机，再做相应的写操作，会怎么样？

[root@huan bin]# redis-server redis.conf 
1807:C 30 Aug 2020 10:01:15.197 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1807:C 30 Aug 2020 10:01:15.197 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=1807, just started
1807:C 30 Aug 2020 10:01:15.197 # Configuration loaded

现在master节点已经重新启动。

127.0.0.1:6379> get k1
"v1"

依然能够获取到值，那设置值之后，其他节点是否还能获取到新写入的值呢？

127.0.0.1:6320> get k2
"v2"

可以看到，重新加入的master节点在设置了新的值之后，其他从机能够获取到新设置的值。

那从机断开之后重连呢？又会出现什么情况呢？我们在20机器上演示。

127.0.0.1:6320> SHUTDOWN
not connected> exit
[root@huan bin]# redis-server redis20.conf 
[root@huan bin]# redis-cli -p 6320
127.0.0.1:6320> get k1
"v1"
127.0.0.1:6320> get k2
"v2"

可以看到，之前设置的值依然能够拿到，因为redis有自己的持久化机制。而如果我们在主机上设置新的值之后，还能拿到吗？

# 主机 <<<<<<
127.0.0.1:6379> set k3 v3
OK
# 从机 <<<<<<
127.0.0.1:6320> get k3
(nil)

看到从机6320此时并没有拿到k3的值，这是为什么？

127.0.0.1:6320> info replication
# Replication
role:master
connected_slaves:0

role:master，再看我们上面说过的一句话：默认情况下，每台Redis服务器都是主节点。

因为我们没有把从机的相关信息写入到配置文件中，之前设置从机是通过命令SLAVEOF 127.0.0.1 6379让节点加入到集群的。所以节点宕机之后重新启动，除非再次执行SLAVEOF 127.0.0.1 6379命令，否则该节点只能是一个单独的节点。

127.0.0.1:6320> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6320> get k3
"v3"

只要变为从机，就马上能够从集群中获取到最新的值。

复制原理

Slave 启动成功并连接到 master 后，会发送一个sync同步命令

Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步。

但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。从机就能获取主机中最新的值。

其他情况

6379是主机，6310，6320，6330是从机，那现在将6330的master节点设置为6320，其他保持不变。

这样，6320是6379的从机，又是6330的主机。

127.0.0.1:6330> SHUTDOWN
not connected> exit
[root@huan bin]# redis-cli -p 6330

127.0.0.1:6330> SLAVEOF 127.0.0.1 6320
OK

查看6320节点的信息，该节点的角色会是什么呢？

127.0.0.1:6320> info replication
# Replication
role:slave						# 角色依然是slave
master_host:127.0.0.1			# 连接到主节点
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:2293
slave_priority:100
slave_read_only:1
connected_slaves:1				# 看这里，有一个slave节点已经连接

老大不死，小弟永远是小弟，小弟又可以是其他小弟的老大

当主节点(6379)挂掉之后呢？

127.0.0.1:6379> SHUTDOWN
not connected> exit

再次查看6320

127.0.0.1:6320> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:2587
master_link_down_since_seconds:17
slave_priority:100
slave_read_only:1
connected_slaves:1

那此时是否能写入数据呢？

127.0.0.1:6320> set k4 v4
(error) READONLY You can't write against a read only replica.

很明显，答案是：不可以！

为什么呢？

还是那句话，因为我们没有配置哨兵模式，从机没有也不能自动升级为主机，从机只能读，不能写数据。因此，即使该从机有从机节点，但是依然不能够写入数据。

那既然不能自动升级，我们如何手动升级为主机呢？

127.0.0.1:6320> SLAVEOF no one
OK

127.0.0.1:6320> info replication
# Replication
role:master
connected_slaves:1

可以通过SLAVEOF no one命令，手动升级为主机。此时，就可以写入数据了。其他节点也可以手动加入进来。

127.0.0.1:6320> set k4 v4
OK

# 从机 <<<<<<
127.0.0.1:6330> get k4
"v4"

而这个时候，如果主机恢复了，按照上面说的，默认情况下，新启动的redis节点都是主节点。如果其他节点没有手动加入到其他redis集群中，则该节点依旧会存在从节点，反之，该节点只能是一个单独的redis节点。

环境恢复

现在把所有节点初始化，依然让6379成为主机，其他节点是从机。