JavaEE 企业级分布式高级架构师(五)Redis学习笔记(4)

集群篇

Redis主从复制

什么是主从复制

持久化保证了即使 Redis服务器重启也不会丢失数据,因为 Redis 服务器重启后会将硬盘上持久化的数据恢复到内存中,但是当 Redis 服务器的硬盘损坏了可能会导致数据丢失,不过通过 Redis 的主从复制机制就可以避免这种单点故障,如下图:
在这里插入图片描述
说明:

  • 主 Redis 中的数据有两个副本(replication),即从 Redis1 和从 Redis2,即使一台Redis服务器宕机其他两台Redis服务也可以继续提供服务
  • 主 Redis 中的数据和从 Redis 上的数据保持实时同步,当主 Redis 写入数据时,通过主从复制机制会复制到两个从 Redis 服务器上
  • 只有一个主 Redis,可以有多个从 Redis
  • 主从复制不会阻塞 master,在同步数据时,master可以继续处理 client 请求
  • 一个 Redis 可以即是主有是从,如下图:
    在这里插入图片描述

主从配置

主Redis配置

无需特殊配置

从Redis配置

修改从服务器上的Redis.conf文件

# replicaof <masterip> <masterport>
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135,端口是6379。 
# 4.0之前只能slaveof 4.0之后默认replicaof,slaveof也起作用
slaveof 192.168.254.128 6379
replicaof 192.168.254.128 6379

实现原理

  • Redis 的主从同步,分为全量同步增量同步
  • 只有从机第一次连接上主机是全量同步
  • 断线重连有可能触发全量同步,也有可能是增量同步(master判断runid是否一致)
  • 除此之外的情况都是增量同步
    在这里插入图片描述
全量同步

Redis 的全量同步过程主要分三个阶段:

  • 同步快照阶段:Master创建并发送快照给Slave,Slave载入并解析快照。Master同时将此阶段所产生的新的写命令存储到缓冲区
  • 同步写缓冲阶段:Master向Slave同步存储在缓冲区的写操作命令
  • 同步增量阶段:Master向Slave同步写操作命令
    在这里插入图片描述
增量同步
  • Redis增量同步主要指Slave完成初始化后开始正常工作时,Master发生的写操作同步到Slave的过程
  • 通常情况下,Master每执行一个写命令就会向Slave发送相同的写命令,然后Slave接收并执行

Redis哨兵机制(难点,面试)

Redis主从复制的缺点:没有办法对master进行动态选择,需要使用Sentinel机制完成动态选举

简介

  • 哨兵(Sentinel)主要是为了解决在主从复制架构中出现宕机的情况,主要分为两种情况:
    • 从Redis宕机:这个相对而言比较简单,在Redis中从库重新启动后会自动加入到主从架构中,自动完成同步数据。在Redis2.8版本后,主从断线后恢复的情况下实现增量复制。
    • 主Redis宕机:这个相对而言就会复杂一些,需要以下2步才能完成
      • 在从数据库中执行SLAVEOF NO ONE命令,断开主从关系并且提升为主库继续服务。
      • 将主库重新启动后,执行SLAVEOF命令,将其设置为其他库的从库,这时数据就能更新回来。
    • 由于这个手动完成恢复的过程其实是比较麻烦的并且容易出错,所以 Redis 提供的哨兵 (sentinel) 的功能来解决
  • Sentinel(哨兵)进程是用于监控 Redis 集群中 Master 主服务器工作的状态,在 Master 主服务器发送故障的时候,可以实现 Master 和 Slave 服务器的切换,保证系统的高可用(HA)。
  • 其已经被集成在 redis2.6+ 的版本中,Redis的哨兵模式到了 2.8版本之后就稳定了下来。

Redis Sentinel工作原理分析

哨兵(sentinel)机制的高可用
  • Sentinel(哨兵)是Redis 的高可用性解决方案:由一个或多个Sentinel 实例组成的Sentinel 系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器。如下图所示:
    在这里插入图片描述
  • 在Server1 掉线后:
    在这里插入图片描述
  • 升级Server2 为新的主服务器:
    在这里插入图片描述
哨兵的定时监控
  • 任务1:每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图,哨兵配置时只要配置对主节点的监控即可,通过向主节点发送info,获取从节点的信息,并当有新的从节点加入时可以马上感知到。
    在这里插入图片描述
  • 任务2:每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断,以及当前哨兵节点的信息,同时每个哨兵节点也会订阅该频道,来了解其它哨兵节点的信息及对主节点的判断,其实就是通过消息publish和subscribe来完成的。
    在这里插入图片描述
  • 任务3:每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测,这个也是哨兵用来判断节点是否正常的重要依据
    在这里插入图片描述
故障判定原理分析
  • 主观下线(SDOWN):所谓主观下线,就是单个sentinel认为某个服务下线(有可能是接收不到订阅,之间的网络 不通等等原因)。
  • sentinel会以每秒一次的频率向所有与其建立了命令连接的实例(master、slave服务,其他sentinel)发 ping命令,通过判断ping回复是有效回复,还是无效回复来判断实例时候在线(对该sentinel来说是“主观在线”)。
  • sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度,如果实例在down- after-milliseconds毫秒内,返回的都是无效回复,那么sentinel回认为该实例已(主观)下线,修改其 flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务,有可能存在多个sentinel的down-after- milliseconds配置不同,这个在实际生产中要注意。
  • 客观下线(ODOWN):当主观下线的节点是主节点时,此时该哨兵3节点会通过指令sentinel is-masterdown-by- addr寻求其它哨兵节点对主节点的判断,如果其他的哨兵也认为主节点主观线下了,则当认为主观下线 的票数超过了quorum(选举)个数,此时哨兵节点则认为该主节点确实有问题,这样就客观下线了, 大部分哨兵节点都同意下线操作,也就说是客观下线。
    在这里插入图片描述
    在这里插入图片描述
    重点:sentinel monitor
哨兵Leader的选举流程

如果主节点被判定为客观下线之后,就要选取一个哨兵节点来完成后面的故障转移工作,选举出一个Leader的流程如下:

  • 每个在线的哨兵节点都可以成为领导者,当它确认(比如哨兵3)主节点下线时,会向其它哨兵发is-master-down-by-addr命令,征求判断并要求将自己设置为领导者,由领导者处理故障转移。
  • 当其它哨兵收到此命令时,可以同意或者拒绝它成为领导者。
  • 如果哨兵3发现自己在选举的票数num 大于等于 (sentinels)/2+1时,将成为领导者,如果没有超过,继续选举…
    在这里插入图片描述

自动故障转移机制

在从节点中选择新的主节点】:sentinel状态数据结构中保存了主服务的所有从服务信息,领头sentinel按照如下的规则从从服务列表中挑选出新的主服务:

  • 过滤掉主观下线的节点;
  • 选择slave-priority/ replica-priority最高的节点,如果有则返回没有就继续选择;
  • 选择出复制偏移量最大的系节点,因为复制偏移量越大则数据复制的越完整,如果由就返回了,没有就继续;
  • 选择run_id最小的节点。
    在这里插入图片描述
    更新主从状态】通过slaveof no one命令,让选出来的从节点成为主节点;并通过slaveof命令让其他节点成为其从节点。
  • 将已下线的主节点设置成新的主节点的从节点,当其回复正常时,复制新的主节点,变成新的主节点的从节点。
  • 同理,当已下线的服务重新上线时,sentinel会向其发送slaveof命令,让其成为新主的从。

哨兵进程的作用

  • 监控(Monitoring):哨兵(sentinel)会不断地检查你的 Master 和 Slave 是否运行正常
  • 提醒(Notification):当被监控的某个Redis节点出现问题时,哨兵(sentinel)可以通过 API 向管理员或者其他应用程序发送通知
  • 自动故障迁移(Automatic failover):当一个 Master 不能正常工作时,哨兵(sentinel)会开始一次自动故障迁移操作,具体操作如下:
* 它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master
* 当客户端视图连接失效的Master时,集群也会向客户端返回新Master地址,使得集群可以使用现在的Master替换失效Master
* Master和Slave服务器切换后,Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变,即Master主服务器的redis.conf配置文件中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换

哨兵配置

  • 修改从机的 sentinel.conf
# 【命令格式】:sentinel monitor <master-name> <master ip> <master port> <quorum>
# 参数<master-name>:可以自己命名的主节点名字,只能由字母[a-zA-Z]、数字[0-9]、[,-_]组成
# 参数<master ip> <master port>:哨兵 sentinel 监控的 redis 主节点的 IP PORT
# 参数<quorum>:当有 quorum个 sentinel哨兵认为master主节点失联,那么这时客观上认为主节点失联了
sentinel monitor mymaster 192.168.254.128 6379 1
  • 其他配置项说明
# 哨兵 sentinel 实例运行的端口 默认26379
port 26379

# 哨兵 sentinel 的工作目录
dir /tmp

# 【命令格式】:sentinel monitor <master-name> <master ip> <master port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 【命令格式】:sentinel auth-pass <master-name> <password>
# 当在 Redis 实例中开启了requirepass foobared 授权密码,这样所有连接 Redis 实例的客户端都要提供密码
# 设置哨兵 sentinel 连接主从的密码,注意必须为 主从设置一样的验证密码
sentinel auth-pass mymaster MySUPER--secret-0123passwOrd

# 【命令格式】:sentinel down-after-milliseconds <master-name> <milliseconds>
# 指定多少毫秒之后,主节点没有应答哨兵 sentinel,此时哨兵主观认为主节点下线,默认30秒
sentinel down-after-milliseconds mymaster 30000

# 【命令格式】:sentinel parallel-syncs <master-name> <numslaves>
# 这个配置项指定了在发生 failover 主备切换时,最多可以有多少个 slave 同时对新的 master 进行同步,
# 这个数字越小,完成 failover 所需的时间就越长,但是如果这个数字越大,就意味着越多的 slave 因为 replication 而不可用
# 可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1

# 【命令格式】:sentinel failover-timeout <master-name> <milliseconds>
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面:
# 1. 同一个 sentinel 对同一个 master 两次 failover 之间的间隔时间
# 2. 当一个 slave 从一个错误的 master 那里同步数据开始计算时间,直到 slave 被矫正为向正确的 master 那里同步数据时
# 3. 当想要取消一个正在进行的 failover 所需要的时间
# 4. 当进行 failover 时,配置所有 slaves 指向新的 master 所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向 master,但是就不按 parallel-syncs 所配置的规则来了
# 默认三分钟
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION

# 配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员
# 对于脚本的运行结果有以下规则:
# 若脚本执行后返回1,那么该脚本稍后将会再次执行,重复次数目前默认为10
# 若脚本执行后返回2,或者比2更高的一个返回值,脚本将不会重复执行
# 如果脚本在执行过程中由于收到系统中断信号被终止了,则通返回值1时的行为相同
# 一个脚本的最大执行时间为60s,如果超时,脚本将会被一个SIGKILL信号终止,之后重新执行

# 【命令格式】:sentinel notification-script <master-name> <script-path>
# 通知型脚本:当 sentinel 有任何警告级别的时间发生时(比如说redis实例的主观失效和客观失效等),将会去调用这个脚本,这时这个脚本应该通过邮件、SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时,将传给脚本两个参数,一个是事件类型,一个是事件的描述。
# 如果sentinel.conf配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无法正常启动成功。
sentinel notification-script mymaster /var/redis/notify.sh

# 【命令格式】:sentinel client-reconfig-script <master-name> <script-path>
# 客户端重新配置主节点参数脚本
# 当一个 master 由于 failover 而发生改变时,这个脚本将会被调用,通知相关的客户端关于 master 地址已经发生改变的信息
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是 failover
# 参数<from-ip> <from-port> <to-ip> <to-port>是用来和旧的master与新的master(即旧的slave)通信的这个脚本应该是通用的,能被多次调用,不是针对性的。
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
  • 通过 redis-sentinel 启动哨兵服务
./redis-sentinel sentinel.conf
推荐配置

推荐的sentinel 集群是1主2从3哨兵

  • 如果有一个sentinel:实际情况,其实单纯从代码的情况,其实1个Sentinel就能完成主观下线(sdown,SubjectivelyDown),客观下线(odown, Objectively Down) 的判断,自动发现 Sentinel 和从服务器,并且完成故障转移。
  • 如果有2个sentinel:如果哨兵集群仅仅部署了个2个哨兵实例,quorum=1。s1和s2中只要有1个哨兵认为master宕机就可以还行切换,同时s1和s2中会选举出一个哨兵来执行故障转移。同时这个时候,需要majority,也就是大多数哨兵都是运行的,2个哨兵的majority就是2(2的majority=2,3的majority=2,5的majority=3,4的majority=3),如果一个节点挂了那么哨兵也就挂了,哨兵只剩下一个,那么就无法完成故障转移。
    在这里插入图片描述
  • 如果是经典的3节点哨兵集群:Configuration: quorum = 2。majority=2(majority不能配置,由redis自行计算所得。)如果M1所在机器宕机了,那么三个哨兵还剩下2个,S2和S3可以一致认为master宕机,然后选举出一个来执行故障转移。同时3个哨兵的majority是2,所以还剩下的2个哨兵运行着,就可以允许执行故障转移。这就是经典的sentinel3个节点的集群。节省资源的同时又满足了高可用。
    在这里插入图片描述

Redis集群演变

主从复制

  • 参考主从复制

Replication+Sentinel 高可用

  • 这套架构使用的是社区版本推出的原生高可用解决方案,其架构图如下
    在这里插入图片描述
    这里Sentinel的作用有三个:
  • 监控:Sentinel 会不断的检查主服务器和从服务器是否正常运行。
  • 通知:当被监控的某个Redis服务器出现问题,Sentinel通过API脚本向管理员或者其他的应用程序 发送通知。
  • 自动故障转移:当主节点不能正常工作时,Sentinel会开始一次自动的故障转移操作,它会将与失 效主节点是主从关系的其中一个从节点升级为新的主节点,并且将其他的从节点指向新的主节点。
工作原理
  • 当Master宕机的时候,Sentinel会选举出新的Master,并根据Sentinel中client-reconfig-script脚本配置的内容,去动态修改VIP(虚拟IP),将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可。故障发生后的转移情况,可以理解为下图:
    在这里插入图片描述
缺陷
  • 主从切换的过程中会丢数据。
  • Redis只能单点写,不能水平扩容。
常用方案

内网DNS,VIP和封装客户端直连Redis Sentinel 端口。

内网DNS
  • 底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端连接内网 DNS 提供服务。内网 DNS 按照一定的规则分配,比如 xxxx.redis.cache/queue.port.xxx.xxx,第一个段表示业务简写,第二个段表示这是 Redis 内网域名,第三个段表示 Redis 类型,cache 表示缓存,queue 表示队列,第四个段表示Redis 端口,第五、第六个段表示内网主域名。当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Sentinel 集群会调用 client-reconfig- 配置的脚本,修改对应端口的内网域名。对应端口的内网域名指向新的 Redis 主节点。
  • 优点:秒级切换,10秒之内;脚本自定义,架构可控;对应用透明,前端不用担心后端发生什么变化。
  • 缺点:维护成本高;依赖DNS,存在解析超时;哨兵存在短时间服务不可用;服务时通过外网不可采用。
VIP
  • 和第一种方案略有不同,把内网 DNS 换成了虚拟 IP。底层是 Redis Sentinel 集群,代理着 Redis 主从,Web 端通过 VIP 提供服务。在部署 Redis 主从的时候,需要将虚拟 IP 绑定到当前的 Redis 主节点。当主节点发生故障,比如机器故障、Redis 节点故障或者网络不可达,Sentinel 集群会调用 client-reconfig- 配置的脚本,将 VIP 漂移到新的主节点上。
  • 优点:秒级切换,5秒之内 ;脚本自定义,架构可控;对应用透明,前端不用担心后端发生什么变化。
  • 缺点:维护成本更高,使用VIP增加维护成本,并存在IP混乱风险。
封装客户端直连Redis Sentinel 端口
  • 这个主要是因为有些业务只能通过外网访问 Redis,于是衍生出了这种方案。Web 使用客户端连接其中一台 Redis Sentinel 集群中的一台机器的某个端口,然后通过这个端口获取到当前的主节点,然后再连接到真实的 Redis 主节点进行相应的业务员操作。需要注意的是,Redis Sentinel 端口和 Redis 主节点均需要开放访问权限。前端业务使用 Java,有JedisSentinelPool 可以复用。
  • 优点:服务探测故障及时,DBA维护成本低。
  • 缺点:依赖客户端支持Sentinel;Sentinel 服务器和 Redis 节点需要开放访问权限;再有对应用有侵入性。

Proxy+Replication+Sentinel(了解)

这里的Proxy有两种选择:Codis(豌豆荚)和Twemproxy(推特)。

  • 因为Codis开源的比较晚,考虑到更换组件的成本问题。毕竟本来运行好好的东西,你再去换组件,风险是很大的。
  • Redis Cluster在2015年还是试用版,不保证会遇到什么问题,因此不敢尝试。所以我没接触过Codis,之前一直用的是Twemproxy作为Proxy。这里以Twemproxy为例说明,如下图所示:
    在这里插入图片描述
工作原理
  • 前端使用Twemproxy+KeepAlived做代理,将其后端的多台Redis实例分片进行统一管理与分配。
  • 每一个分片节点的Slave都是Master的副本且只读。
  • Sentinel持续不断的监控每个分片节点的Master,当Master出现故障且不可用状态时,Sentinel会通知/启动自动故障转移等动作。
  • Sentinel 可以在发生故障转移动作后触发相应脚本(通过 client-reconfig-script 参数配置 ),脚本获取到最新的Master来修改Twemproxy配置。
缺陷
  • 部署结构超级复杂。
  • 可扩展性差,进行扩缩容需要手动干预。
  • 运维不方便。
    Redis3.0以后推出的Redis cluster集群方案,Redis cluster集群保证了高可用、高性能、高可扩展性

Redis-cluster集群(重点)

Redis-cluster架构图

在这里插入图片描述

架构细节
  • 所有的 redis 节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽
  • 所有节点的 fail 是通过集群中超过半数的节点检测失效时才生效
  • 客户端与 redis 节点直连,不需要中间 proxy 层,客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
  • redis-cluster 把所有的物理节点映射到[0-16383]slot上,cluster 负责维护 node<=>slot<=>value
    在这里插入图片描述
Redis 集群中内置了16383个哈希槽,当需要在 Redis 集群中放置一个 key-value 时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对16384求余数,这样每个key都会对应一个编号 0-16383 之间的哈希槽,redis 会根据节点数量大致均等的将哈希槽映射到不同的节点

在这里插入图片描述

Redis-cluster投票:容错
  • 如何判断redis cluster中的master主节点 fail?
  • 如何判断redis cluster集群 fail?
    在这里插入图片描述
  • 节点失效判断:集群中所有master参与投票,如果半数以上master节点与其中一个master节点通常超过(cluster-node-timeout),认为该master节点挂掉。

集群失效判断:什么时候整个集群不可用(cluster_state:fail)?

  • 如果集群任意 master 挂掉,且当前 master 没有slave,则集群进入fail状态。也可以理解为 [0-16383]slot 映射不完全时进入 fail 状态
  • 如果集群超过半数以上 master 挂掉,无论是否有 slave,集群进入 fail 状态。
工作原理
  • 客户端与Redis节点直连,不需要中间Proxy层,直接连接任意一个Master节点。
  • 根据公式HASH_SLOT=CRC16(key) mod 16384,计算出映射到哪个分片上,然后Redis会去相应的节点进行操作。
优点
  • 无需Sentinel哨兵监控,如果Master挂了,Redis Cluster内部自动将Slave切换Master。
  • 可以进行水平扩容。
  • 支持自动化迁移,当出现某个Slave宕机了,那么就只有Master了,这时候的高可用性就无法很好的保证了,万一Master也宕机了,咋办呢? 针对这种情况,如果说其他Master有多余的Slave ,集群自动把多余的Slave迁移到没有Slave的Master 中。
缺点
  • 批量操作是个坑。
  • 资源隔离性较差,容易出现相互影响的情况。

Redis Cluster集群安装

安装Ruby环境

redis 集群需要使用集群管理脚本 redis-trib.rb,它的执行相应依赖 ruby 环境

  • 第一步:安装 ruby
yum install ruby
yum install rubygems
  • 第二步:下载 redis-3.2.2.gem(下载地址:https://rubygems.org/downloads/redis-3.2.2.gem),并安装
gem install redis-3.2.2.gem

在这里插入图片描述

  • 第三步:复制 redis-3.2.9/src/redis-trib.rb 文件到 /usr/local/server/redis-cluster目录
cp /root/redis-3.2.9/src/redis-trib.rb /usr/local/server/redis-cluster/ -r
安装RedisCluster

Redis集群最少需要三台主服务器,三台从服务器
端口号分别为:7001 ~ 7006

  • 第一步:创建7001实例,并编辑redis.conf文件,修改port为7001.
    注意:创建实例,即拷贝单机版安装时,生成的 bin 目录,为7001(cp /usr/local/server/redis/bin/ ./7001 -r)
    在这里插入图片描述
    在这里插入图片描述
  • 第二步:修改 redis.conf 配置文件,打开 Cluster-enable yes
    在这里插入图片描述
    在这里插入图片描述
  • 第三步:复制7001,创建7002~2006实例,注意端口修改
    在这里插入图片描述
  • 第四步:启动所有实例,vim start-cluster.sh:
cd ./7001
./redis-server redis.conf
cd ..
cd ./7002
./redis-server redis.conf
cd ..
cd ./7003
./redis-server redis.conf
cd ..
cd ./7004
./redis-server redis.conf
cd ..
cd ./7005
./redis-server redis.conf
cd ..
cd ./7006
./redis-server redis.conf
cd ..

在这里插入图片描述

  • 第五步:创建Redis集群
./redis-trib.rb create --replicas 1 192.168.254.128:7001 192.168.254.128:7002 192.168.254.128:7003 192.168.254.128:7004 192.168.254.128:7005 192.168.254.128:7006
# --replicas 1 : 表示一主一从

在这里插入图片描述
在这里插入图片描述

命令客户端连接集群
  • 命令:
./redis-cli -h 127.0.0.1 -p 7001 -c

在这里插入图片描述

  • 注意:-c 表示是以 redis 集群方式进行连接
    在这里插入图片描述
查看集群的命令
  • 查看集群状态
    在这里插入图片描述
  • 查看集群中的节点
    在这里插入图片描述
维护节点

集群创建成功后可以继续向集群中添加节点

添加主节点
  • 先创建7007节点
cp -f ./7001 ./7007
cd 7007
rm -rf appendonly.aof
rm -rf dump.rdb
rm -rf nodes.conf
  • 修改7007节点的配置文件,将端口好改为7007
  • 添加7007节点作为新节点,执行命令:
./redis-trib.rb add-node 127.0.0.1:7007 127.0.0.1:7001

在这里插入图片描述

  • 查看集群节点,发现7007已添加到集群中,但是7007并没有分配槽
    在这里插入图片描述
hash槽重新分配(数据迁移)

添加完主节点,需要对主节点进行hash槽分配,这样该主节点才可以存储数据

  • 查看集群中槽占用情况:
cluster nodes

redis 集群有16384个槽,集群中的每个节点分配自己的槽,通过查看集群节点可以看到槽占用情况
给刚添加的 7007 节点分配槽步骤:

  • 第一步:连接上集群(连接集群中任意一个可用节点都行)
./redis-trib.rb reshard 192.168.254.128:7001
  • 第二步:输入要分配的槽数量,例如,输入3000,表示给目标节点分配3000个槽
    在这里插入图片描述
  • 第三步:输入接收槽的节点id,这里是给7007分配槽,通过节点信息可以看到7007节点的id为:d2e5beb0d6f0d1293d716f63a39f56a3fb37c586
    在这里插入图片描述
  • 第四步:输入源节点id,槽将从源节点中拿,分配后的槽在源节点中就不存在了,输入all表示从源节点中获取槽,输入done表示取消分配。
    在这里插入图片描述
  • 第五步:输入 yes 开始移动槽到目标节点 id
    在这里插入图片描述
  • 查看节点信息
    在这里插入图片描述
添加从节点
  • 添加新节点7008,并启动之
    在这里插入图片描述
  • 启动7008
    在这里插入图片描述
  • 添加7008从节点,将7008作为7007的从节点
  • 命令:
./redis-trib.rb add-node --slave --master-id 主节点id 新节点ip和端口 旧节点ip和端口(集群中任意节点都可以)

在这里插入图片描述
d2e5beb0d6f0d1293d716f63a39f56a3fb37c586是7007节点的id,可以通过cluster nodes 查看
注意:如果原来该节点在集群中的配置信息已经生成到 cluster-config-file 指定的配置文件中,这时可能会报错:
在这里插入图片描述
解决办法是删除生成的配置文件 nodes.conf,删除后执行 ./redis-trib.rb add-node 命令

  • 查看集群中的节点,刚添加的7008为7007的从节点
    在这里插入图片描述
删除节点
  • 命令
./redis-trib.rb del-node 127.0.0.1:7005 b1b05dfdde75b62cec776f822c571beaddec64f0

在这里插入图片描述

  • 删除已经占有hash槽的节点会失败,报错如下
    在这里插入图片描述
  • 需要将该节点占用的 hash 槽分配出去
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

讲文明的喜羊羊拒绝pua

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值