0%

redis主从复制

redis主从复制

注意:我使用的版本是6.0.10,不同版本可能略有差别

虽然redis有持久化的功能可以保证redis服务重启不会丢失数据,但是如果redis服务器的硬盘损坏就会导致数据丢失,,使用主从复制来避免这种单点故障。

主机数据更新后根据配置和策略自动同步到备机的master/slave机制,master以写为主,slave以读为主

原理

主要是使用PSYNC命令来实现

PSYNC命令具有完整重同步和部分重同步两种模式

  • 完整重同步用于处理初次复制的情况:slave启动成功连接到master后会发送一个psync命令,master接到命令后会启动后台创建并发送RDB文件,完成后将命令发送给slave
  • 部分重同步用于处理断线后重复制的情况:在断线后重连,slave向master发送psync命令,master将断线之后的写命令发送给slave

那么如何知道slave和master之间只差了这几个命令呢?

是因为master和slave在复制的时候都维护了一个复制偏移量,而master在复制积压缓冲区中会保存一部分最近传播的写命令,为每个字节来记录相应的复制偏移量,可以根据复制偏移量来找到对应的字节,当然,如果复制积压缓冲区中没有这个偏移量了,那么就只能进行全量复制了

redis默认的复制积压缓冲区为1mb,可以修改配置中repl-backlog-size 来进行调整

配置

配主不配从,配置slave即可,使得slave时刻盯住主机

在这里由于我只有一台电脑,所以只能用三个配置文件来启动三个redis服务了,带有配置文件的启动服务

1
redis-server redis79.conf

以及使用端口启动客户端

1
redis-cli -p 6379

启动之后就可以配置从机了

1
replicaof 127.0.0.1 6379

在5.0之后使用replicaof,5.0之前使用slaveof 不过当前slaveof还没有失效

1
2
3
# 可以配置最少有多少个从节点  主节点才可以写
# min-replicas-to-write 3
# min-replicas-max-lag 10

一主两仆

graph TD
master79-->slave80
master79-->slave81

看一下执行命令之前的配置变化(使用info replication来查看)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#之前
# Replication
role:master
connected_slaves:0
master_replid:96519fc9dab0e66f4d1e8513f519b68622f4af9e
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

#之后
#主机
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=2646,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=2646,lag=1
master_replid:63b39507da5e42ce5e1b4d931f4e743c91bb92cd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2646
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2646


#从机
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:63b39507da5e42ce5e1b4d931f4e743c91bb92cd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:43
repl_backlog_histlen:0

重点:

  • 从机会将主机的所有数据进行备份
  • 从机只能读,不能写(error) READONLY You can’t write against a read only replica.
  • 主机挂了之后,从机身份不变(master_link_status变成down),直到主机回来,主机回来之后还是主机
  • 从机挂了之后需要重新执行从属命令replicaof 127.0.0.1 6379(如果是直接在配置文件中配置的从属关系则不需要)

可以使用命令来将从库变成主库

1
replicaof no one

在5.0之后使用replicaof,5.0之前使用slaveof 不过当前slaveof还没有失效

薪火相传

由于一主两仆机制会导致主机挂掉之后整个redis就挂掉的问题,所以为了去中心化,有了薪火相传机制,上一个slave可能是下一个slave的master,slave同样可以接收其他的slave的连接和请求,可以有效地减轻master的写压力

graph LR
master79-->slave80-->slave81

这里slave80对于slave81是主机,对于master79是从机

该机制可能会存在延迟

哨兵模式

由于一主两从的主库挂掉之后,需要人工的去干预从库反客为主,再进行更改主从配置,而哨兵模式通过监听主库是否挂掉,从库根据投票来决定自动将从库切换为主库

配置redis-sentinel.conf配置文件

1
2
#哨兵监控 6379  当6379挂了之后从库进行投票,票数超过1即可成为主库,配置文件会自动修改为新选举的主库ip和port
sentinel monitor mymaster 127.0.0.1 6379 1

哨兵启动

1
redis-sentinel redis-sentinel.conf

当主库挂掉之后,从库进行重新选举出新的主库,原来的主库回来之后,只会成为从库,不会变成双主库

哨兵的功能

哨兵节点不同于数据节点,不存储数据,且仅支持部分命令

  • 监控 哨兵检查主节点和从节点是否正常运作
  • 自动故障转移 主节点不能正常工作时,哨兵开始自动故障转移操作,将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点复制新的主节点
  • 配置提供者 客户端在初始化时,通过连接哨兵来获得当时redis服务的主节点地址
  • 通知 将故障转移结果发送给客户端
选举新的主服务器

sentinel会将所有的从服务器保存到一个列表中,然后进行筛选

  • 首先会删除掉下线的从服务器
  • 然后删除掉最近五秒内没有回复过sentinel的info命令的从服务器
  • 删除掉与主服务连接断开超过down-after-milliseconds * 10 毫秒的从服务器(down-after-milliseconds表示判断主服务器下线所需的时间)
  • 根据从服务器优先级进行排序,如果有多个最高优先级的从服务器,则选出偏移量最大的
  • 如果存在多个最高优先级、复制偏移量最大的从服务器,则按照id进行排序,选出id最小的

sentinel是不会监控从服务器的,所以如果从服务器挂掉之后,sentinel是不会对其进行故障转移的

作用

  • 读写分离
  • 灾备