redis主从复制

redis主从复制

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

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

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

原理

主要是使用PSYNC命令来实现

PSYNC命令具有全同步和部分同步两种模式

redis会首先尝试部分同步，如果失败才会尝试全同步。slave连接master后，会主动发起psync命令，slave会提供master_runid和offset，master验证maste_runid和offset是否有效，master_runid相当于master的身份验证码，用来验证slave上一次连接的master，offset是全局积压空间数据的偏移量。如果验证未通过，则进行全同步

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

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

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

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

配置

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

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

redis-server redis79.conf

以及使用端口启动客户端

redis-cli -p 6379

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

replicaof 127.0.0.1 6379

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

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

一主两仆

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

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

#之前
# 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(如果是直接在配置文件中配置的从属关系则不需要)

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

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配置文件

#sentinel monitor master-name ip redis-port quorum
# master-name为主数据的名字，考虑到主数据库的ip和端口会变化，所以可以通过名字来获取当前系统的主数据库的地址和端口号
# ip和port 是当前系统中主数据的地址，redis-port表示端口号
# quorum 用来表示执行故障恢复操作前至少需要几个哨兵节点同意
# 哨兵监控 6379  当6379挂了之后从库进行投票，票数超过1即可成为主库，配置文件会自动修改为新选举的主库ip和port
sentinel monitor mymaster 127.0.0.1 6379 1
# 如果主服务器存在密码需要进行配置密码 sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
# 判断主服务器的挂机时间，超过该时间则被标记为down
sentinel down-after-milliseconds master-1 3000
# 该配置设置在执行故障转移时，最多可以有多少个从服务器同时对新服务器进行同步
sentinel parallel-syncs mymaster 1
# 故障转移超时时间，超过该时间表示failover失败
sentinel failover-timeout mymaster 180000

哨兵启动

redis-sentinel redis-sentinel.conf

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

查看哨兵信息

redis-cli -h 127.0.0.1 -p 26379 info Sentinel

哨兵的功能

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

• 配置提供者 客户端在初始化时，通过连接哨兵来获得当时redis服务的主节点地址
• 监控： sentinel会不断地检查主服务器和从服务器是否运作正常
• 通知： 当被监控的某个redis服务器出现问题时，sentinel可以通过API向管理员或者其他应用程序发送通知
• 自动故障迁移： 当一个主服务器不能正常工作时，sentinel会开始一次自动故障迁移操作，会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器，当客户端试图链接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器

选举新的主服务器

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

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

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

哨兵原理

首先哨兵需要进行状态感知，在哨兵启动的时候是指定了master的地址的，哨兵每隔10s会向master节点发送info命令，info命令中包含了主从拓扑关系，如果master挂掉之后，哨兵会选择合适的slave节点进行故障恢复，即向所选的slave节点发送replicaof no one命令，使其变成master，然后向其他slave节点发送 replicaof $newmaster命令

作用

• 读写分离
• 灾备

https://zhhll.icu/2021/数据库/非关系型数据库/redis/基础/6.redis主从复制/

本文由mdnice多平台发布