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  
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 多平台发布

你可能感兴趣的:(redis,程序人生)