redis消息队列、redis其他命令、redis主从配置、redis主从复制过程、主从同步优化、哨兵配置、集群配置、集群添加节点、集群手动修改节点状态、集群删除节点、集群导入现有数据

最新推荐文章于 2022-09-07 15:19:41 发布

zerocdn

最新推荐文章于 2022-09-07 15:19:41 发布

阅读量339

点赞数

分类专栏： Linux

本文链接：https://blog.csdn.net/zerocdn/article/details/115837418

版权

Linux 专栏收录该内容

44 篇文章 1 订阅

订阅专栏

redis消息队列

消息队列主要分为两种，分别是生产者消费者模式和发布者订阅者模式，这两种模式 Redis 都支持

1.生产者消费者模式

在生产者消费者(Producer/Consumer)模式下，上层应用接收到的外部请求后开始处理其当前步骤的操作，在执行完成后将已经完成的操作发送至指定的频道(channel)当中，并由其下层的应用监听该频道并继续下一步的操作，如果其处理完成后没有下一步的操作就直接返回数据给外部请求，如果还有下一步的操作就再将任务发布到另外一个频道，由另外一个消费者继续监听和处理。

生产者消费者模式下，多个消费者同时监听一个队里，但是一个消息只能被最先抢到消息的消费者消费，即消息任务是一次性读取和处理，此模式在分布式业务架构中非常常用，比较常用的软件还有RabbitMQ、Kafka、RocketMQ、ActiveMQ 等

队列当中的消息由不同的生产者写入也会有不同的消费者取出进行消费处理，但是一个消息一定是只能被取出一次也就是被消费一次。

生产者发布消息：

 LPUSH channel1 msg1 #从管道的左侧写入

查看队列消息：

LRANGE channel1 0 2
1) "msg5"
2) "msg4"
3) "msg3"
如果使用-1则是查看所有消息
LRANGE channel1 0 -1

消费者消费消息：

RPOP channel1 #从管道的右侧消费

2.发布者订阅模式

在发布者订阅者模式下，发布者将消息发布到指定的 channel 里面，凡是监听该 channel 的消费者都会收到同样的一份消息，这种模式类似于是收音机模式，即凡是收听某个频道的听众都会收到主持人发布的相同的消息内容。
此模式常用语群聊天、群通知、群公告等场景。
Subscriber：订阅者
Publisher：发布者
Channel：频道

发布者发布消息：

PUBLISH channel1 test1 #发布者发布消息

订阅者订阅频道：

SUBSCRIBE channel1 #订阅者订阅指定的频道

订阅多个频道：

SUBSCRIBE channel1 channel1

订阅所有频道：

PSUBSCRIBE *

订阅匹配的频道：

PSUBSCRIBE chann*

redis其他命令

1.CONFIG

用于查看当前redis配置、以及不重启更改redis配置等

更改最大内存：

单位是字节
CONFIG set maxmemory 8589934592

设置连接密码：

CONFIG set requirepass 123456

获取当前配置：

CONFIG get *

2.info

显示当前节点redis运行状态信息，默认显示全部
也可以加参数显示指定部分

info
info server

3.SELECT

用于切换数据库

SELECT 1

4.keys

用户查看当前库的key

keys *

5.BGSAVE

手动在后台执行RDB持久化操作

BGSAVE

6.DBSIZE

手动在后台执行RDB持久化操作

BGSAVE

7.FLUSHDB

强制清空当前库中的所有 key

FLUSHDB

8.FLUSHALL

强制清空当前redis服务器所有数据库中的所有key，即删除所有数据

FLUSHALL

redis主从配置

虽然redis可以实现单机的数据持久化，但无论是RDB也好或者AOF也好，都解决不了单点宕机问题，即一旦redis服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失，因此需要使用另外的技术来解决单点问题。

主备模式，可以实现Redis数据的跨主机备份。
程序端连接到高可用负载的VIP，然后连接到负载服务器设置的redis后端real server，此模式不需要在程序里面配置redis服务器的真实IP地址，当后期Redis服务器IP地址发生变更只需要更改redis相应的后端real server即可，可避免更改程序中的IP地址设置。

redis slave也要开启持久化并设置和master同样的连接密码，因为后期slave会有提升为master的可能,slave端切换master同步后会丢失之前的所有数据。

一旦某个Slave成为一个master的slave，redis slave服务会清空当前redis服务器上的所有数据并将master的数据导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据。

命令配置

当前状态为master，需要转换为slave角色并指向master服务器的IP+PORT+Password

使用redis-cli连上之后输入
REPLICAOF 192.168.1.10 6379
CONFIG SET masterauth 123456

文件配置

修改redis.conf文件中

slaveof 192.168.1.10 6379
masterauth 123456

redis主从复制过程

redis 支持主从复制分为全量同步和增量同步，首次同步是全量同步，主从同步可以让从服务器从主服务器备份数据，而且从服务器还可与有从服务器，即另外一台 redis 服务器，可以从一台从服务器进行数据同步。

redis 的主从同步是非阻塞的，其收到从服务器的 sync(2.8 版本之前是 PSYNC)命令会fork 一个子进程在后台执行 bgsave 命令，并将新写入的数据写入到一个缓冲区里面，bgsave 执行完成之后并生成的将 RDB 文件发送给客户端，客户端将收到后的 RDB 文件载入自己的内存，然后主 redis将缓冲区的内容在全部发送给从 redis，之后的同步从服务器会发送一个 offset 的位置(等同于 MySQL的 binlog 的位置)给主服务器，主服务器检查后位置没有错误将此位置之后的数据包括写在缓冲区的积压数据发送给 redis 从服务器，从服务器将主服务器发送的挤压数据写入内存，这样一次完整的数据同步，再之后再同步的时候从服务器只要发送当前的 offset 位置给主服务器，然后主服务器根据响应的位置将之后的数据发送给从服务器保存到其内存即可。

Redis 全量复制一般发生在 Slave 初始化阶段，这时 Slave 需要将 Master 上的所有数据都复制一份。具体步骤如下：
1）从服务器连接主服务器，发送 SYNC 命令；
2）主服务器接收到 SYNC 命名后，开始执行 BGSAVE 命令生成 RDB 快照文件并使用缓冲区记录此后执行的所有写命令；
3）主服务器 BGSAVE 执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
7）后期同步会先发送自己 slave_repl_offset 位置，只同步新增加的数据，不再全量同步。

主从同步优化

Redis 在 2.8 版本之前没有提供增量部分复制的功能，当网络闪断或者 slave Redis 重启之后会导致主从之间的全量同步，即从 2.8 版本开始增加了部分复制的功能。

repl-diskless-sync yes#yes 为支持 disk，master 将 RDB 文件先保存到磁盘在发送给 slave，no 为 maste直接将 RDB 文件发送给 slave，默认即为使用 no，Master RDB 文件不需要与磁盘交互。

repl-diskless-sync-delay 5 #Master 准备好 RDB 文件后等等待传输时间

repl-ping-slave-period 10 #slave 端向 server 端发送 ping 的时间区间设置，默认为 10 秒

repl-timeout 60 #设置超时时间

repl-disable-tcp-nodelay no #是否启用 TCP_NODELAY，如设置成 yes，则 redis 会合并小的 TCP 包从而节省带宽，但会增加同步延迟（40ms），造成 master 与 slave 数据不一致，假如设置成 no，则 redis master会立即发送同步数据，没有延迟，前者关注性能，后者关注一致性

repl-backlog-size 1mb #master 的写入数据缓冲区，用于记录自上一次同步后到下一次同步过程中间的写入命令，计算公式：b repl-backlog-size = 允许从节点最大中断时长 * 主实例 offset 每秒写入量，比如 master 每秒最大写入 64mb，最大允许 60 秒，那么就要设置为 64mb*60 秒=3840mb(3.8G)=

repl-backlog-ttl 3600 #如果一段时间后没有 slave 连接到 master，则 backlog size 的内存将会被释放。如果值为 0 则表示永远不释放这部份内存。

slave-priority 100 #slave 端的优先级设置，值是一个整数，数字越小表示优先级越高。当 master 故障时将会按照优先级来选择 slave 端进行恢复，如果值设置为 0，则表示该 slave 永远不会被选择。

#min-slaves-to-write 0
#min-slaves-max-lag 10
上面两个设置是当一个 master 端的可用 slave 少于 N 个，延迟时间大于 M 秒时，不接收写操作。Master 的重启会导致 master_replid 发生变化，slave 之前的 master_replid 就和 master 不一致从而会引发所有 slave 的全量同步。

附加内容

slave 切换 master

停止同步

SLAVEOF no one

查看状态

>info Replication

输出结果
# Replication
role:master
connected_slaves:0
master_replid:ac3475e5e4fae8c5f47711a643e465b9520c4182
master_replid2:8ee6bc1ac452fd4d2ccbaa660a219f78d218399a
master_repl_offset:8840
second_repl_offset:8841
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:8547
repl_backlog_histlen:294

有slave的master状态信息：

# Replication
role:slave
master_host:192.168.1.102
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9 #最近一次与 master 通信已经过去多少秒。
master_sync_in_progress:0 #是否正在与 master 通信。
slave_repl_offset:5334 #当前同步的偏移量。
slave_priority:100 #slave 优先级，master 故障后值越小越优先同步。
slave_read_only:1
connected_slaves:1
slave0:ip=192.168.1.103,port=6379,state=online,offset=5334,lag=1
master_replid:0f0318c25a022add7fd51d4438c470cf608631f9
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5334
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5334

python连接redis

#!/bin/env python
import redis
pool = redis.ConnectionPool(host="192.168.1.10", port=6379,password="123456")
r = redis.Redis(connection_pool=pool)
for i in range(100):
 r.set("k%d" % i,"v%d" % i)
 data=r.get("k%d" % i)
print(data)

哨兵配置

主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用，而redis高可用无法实现自故障转移(将slave提升为master)，需要手动改环境配置才能切换到slaveredis服务器，另外也无法横向扩展Redis服务的并行写入性能，当单台Redis服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的
两个核心问题，即：
1.master和slave角色的无缝切换，让业务无感知从而不影响业务使用
2.可以横向动态扩展Redis服务器，从而实现多台服务器并行写入以实现更高并发的目的。

Sentinel进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本。

哨兵(Sentinel)是一个分布式系统，可以在一个架构中运行多个哨兵(sentinel)进程，这些进程使用流言协议(gossipprotocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(AgreementProtocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机”，主观是每个成员都具有的独自的而且可能相同也可能不同的意识，英文名称：Subjective Down，简称SDOWN。有主观宕机，肯定就有客观宕机。

当“哨兵群”中的多数Sentinel进程在对Master主服务器做出SDOWN的判断，并且通过SENTINELis-master-down-by-addr命令互相交流之后，得出的MasterServer下线判断，这种方式就是“客观宕机”，客观是不依赖于某种意识而已经实际存在的一切事物，英文名称是：ObjectivelyDown，简称ODOWN。通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）。

Sentinel机制可以解决master和slave角色的切换问题。

哨兵配置

vim /usr/local/redis/etc/sentinel.conf

bind 0.0.0.0
port 26379
daemonize yes
pidfile "redis-sentinel.pid" 
logfile "sentinel_26379.log" #日志文件
dir "/usr/local/redis" #redis路径
sentinel monitor mymaster 192.168.7.10 6379 2 #法定人数限制(quorum)，即有几个 slave 认为 masterdown 了就进行故障转移
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000 #(SDOWN)主观下线的时间
sentinel parallel-syncs mymaster 1 #发生故障转移时候同时向新 master 同步数据的 slave 数量，数字越小总同步时间越长
sentinel failover-timeout mymaster 180000 #所有 slaves 指向新的 master 所需的超时时间
sentinel deny-scripts-reconfig yes #禁止修改脚本

注意：master、哨兵的端口还有mstart的密码都要一致，否则切换会出问题
其他哨兵配置也一样，配置完之后哨兵要同时启动
ss -ntl可以看到哨兵监听了26379端口

集群配置

创建集群的前提

1.每个redis node节点采用相同的硬件配置、相同的密码
2.每个节点必须开启的参数
cluster-enabled yes #必须开启集群状态，开启后 redis 进程会有 cluster 显示
cluster-config-file nodes-6380.conf #此文件有 redis cluster 集群自动创建和维护，不需要任何手动操作
3.所有 redis 服务器必须没有任何数据
4.先启动为单机 redis 且没有任何 key value

集群管理工具 redis-trib.rb

redis-trib.rb是redis官方推出的管理redis集群的工具，集成在redis的源码src目录下，是基于redis提供的集群命令封装成简单、便捷、实用的操作工具，
redis-trib.rb是redis作者用ruby开发完成的，centos系统yum安装的ruby存在版本较低问题，需要自己下载源码包编译

wget https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.5.tar.gz
tar xf ruby-2.5.5.tar.gz
cd ruby-2.5.5
./configure
make -j 2
make install
gem install redis #https://rubygems.org/gems/redis
gem install -l redis-3.3.0.gem

安装完毕直接输入redis-trib.rb验证是否可用

create host1:port1 ... hostN:portN #创建集群
	--replicas <arg> #指定 master 的副本数量
check host:port #检查集群信息
info host:port #查看集群主机信息
fix host:port #修复集群
	--timeout <arg>
reshard host:port #在线热迁移集群指定主机的 slots 数据
	--from <arg>
	--to <arg>
	--slots <arg>
	--yes
	--timeout <arg>
	--pipeline <arg>
rebalance host:port #平衡集群中各主机的 slot 数量
	--weight <arg>
	--auto-weights
	--use-empty-masters
	--timeout <arg>
	--simulate
	--pipeline <arg>
	--threshold <arg>
add-node new_host:new_port existing_host:existing_port #添加主机到集群
	--slave
	--master-id <arg>
del-node host:port node_id #删除主机
set-timeout host:port milliseconds #设置节点的超时时间
call host:port command arg arg .. arg #在集群上的所有节点上执行命令
import host:port #导入外部 redis 服务器的数据到当前集群
	--from <arg>
	--copy
	--replace
help (show this help)

安装成功后修改下面文件的密码为redis登录密码

vim /usr/local/lib/ruby/gems/2.5.0/gems/redis-4.1.0/lib/redis/client.rb

创建集群

1.准备号服务器，这里一共6台服务器
192.168.1.10 192.168.1.11 192.168.1.12
192.168.1.20 192.168.1.21 192.168.1.22

2.在其中一台上使用命令创建
redis-trib.rb create --replicas 1 192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 192.168.1.20:6379 192.168.1.21:6379 192.168.1.22:6379

>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.1.20:6380 to 192.168.1.10:6379
Adding replica 192.168.1.21:6380 to 192.168.1.11:6379
Adding replica 192.168.1.22:6380 to 192.168.1.12:6379
>>> Trying to optimize slaves allocation for anti-affinity
[OK] Perfect anti-affinity obtained!
M: f4cfc5cf821c0d855016488d6fbfb62c03a14fda 192.168.1.10:6379 #带 M 的为 master
	slots:[0-5460] (5461 slots) master #当前 master 的槽位起始和结束位
M: 116c4c6de036fdbac5aaad25eb1a61ea262b64af 192.168.1.11:6379
	slots:[5461-10922] (5462 slots) master #当前 master 的槽位起始和结束位
M: 70de3821dde4701c647bd6c23b9dd3c5c9f24a62 192.168.1.12:6379
	slots:[10923-16383] (5461 slots) master #当前 master 的槽位起始和结束位
S: 2b6e5d9c3944d79a5b64a19e54e52f83d48438d6 192.168.1.20:6379 #带 S 的 slave
	replicates 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
S: 7186c6d03dd9a5e3be658f2d08e800bc55b04a09 192.168.1.21:6379
	replicates f4cfc5cf821c0d855016488d6fbfb62c03a14fda
S: 7eda0bcf0c01bb7343313b81267c42dd1b26c8a6 192.168.1.22:6379
	replicates 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Can I set the above configuration? (type 'yes' to accept): yes #输入 yes 自动创建集群

创建完使用redis-cli连上redis后使用INFO Replication可查看状态

查看集群node对应关系命令

cluster nodes

集群添加节点

准备工作：
需要配置相同版本的redis，切记不可使用不同版本

部署完之后开始添加节

Redis 4 添加方式：
redis-trib.rb add-node 192.168.1.30:6379 192.168.1.31:6379

Redis 5 添加方式：
redis-cli -a 123456 --cluster add-node 192.168.1.30:6379 192.168.1.31:6379

先添加master后续要添加slave也用这个命令
添加一个节点
redis-cli -a 123456 --cluster add-node 192.168.1.30:6379

给节点添加slave
redis-cli -a 123456 --cluster add-node 192.168.1.30:6379 192.168.1.31:6379

添加主机之后需要对添加至集群种的新主机重新分片否则其没有分片

验证当前状态：

Redis 4：
redis-trib.rb check 192.168.1.30:6379

Redis 5：
redis-cli -a 123456 --cluster check 192.168.1.30:6379

对新加的主机重新分配槽位

使用命令
redis-cli -a 123456 --cluster reshard 192.168.1.30:6379

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Performing Cluster Check (using node 192.168.1.30:6379)
M: 886338acd50c3015be68a760502b239f4509881c 192.168.1.30:6379
	slots: (0 slots) master
M: f4cfc5cf821c0d855016488d6fbfb62c03a14fda 192.168.1.10:6379
	slots:[0-5460] (5461 slots) master 
	1 additional replica(s)
M: 116c4c6de036fdbac5aaad25eb1a61ea262b64af 192.168.1.11:6379
	slots:[5461-10922] (5462 slots) master 
	1 additional replica(s)
M: 70de3821dde4701c647bd6c23b9dd3c5c9f24a62 192.168.1.12:6379
	slots:[10923-16383] (5461 slots) master 
	1 additional replica(s)
S: 7186c6d03dd9a5e3be658f2d08e800bc55b04a09 192.168.7.20:6379
	slots: (0 slots) slave 
	replicates f4cfc5cf821c0d855016488d6fbfb62c03a14fda
S: 7eda0bcf0c01bb7343313b81267c42dd1b26c8a6 192.168.7.21:6379
	slots: (0 slots) slave 
	replicates 116c4c6de036fdbac5aaad25eb1a61ea262b64af
S: 2b6e5d9c3944d79a5b64a19e54e52f83d48438d6 192.168.1.22:6379
	slots: (0 slots) slave 
	replicates 70de3821dde4701c647bd6c23b9dd3c5c9f24a62

[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096 #分配多少个槽位给192.168.1.30:6379
What is the receiving node ID? 886338acd50c3015be68a760502b239f4509881c #接收 slot的服务器 ID，手动输入192.168.1.30 的 node ID
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: all #将哪些源主机的槽位分配给 192.168.1.30:6379，all 是自动在所有的 redis node 选择划分，如果是从 redis cluster 删除主机可以使用此方式将主机上的槽位全部移动到别的 redis 主机
输入完选取的节点ID后输入done结束选取
………………………………
Moving slot 6823 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 6824 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 6825 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 6826 from 116c4c6de036fdbac5aaad25eb1a61ea262b64af
Moving slot 10923 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
Moving slot 10924 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
Moving slot 10925 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
Moving slot 10926 from 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
………………………………
Moving slot 1364 from f4cfc5cf821c0d855016488d6fbfb62c03a14fda
Do you want to proceed with the proposed reshard plan (yes/no)? yes #确认分配

集群手动修改节点状态为slave

1.登录到redis
redis-cli -h 192.168.1.30 -p 6379 -a 12345

2.查看集群状态找到目标ID
CLUSTER NODES

3.把节点设置为slave
CLUSTER REPLICATE 886338acd50c3015be68a760502b239f4509881c

设置完后再次查看集群状态确认是否变为slave

集群删除节点

添加节点的时候是先添加 node 节点到集群，然后分配槽位，删除节点的操作与添加节点的操作正好相反，是先将被删除的 Redis node 上的槽位迁移到集群中的其他 Redis node 节点上，然后再将其删除。如果一个 Redis node 节点上的槽位没有被完全迁移，删除该 node 的时候会提示有数据且无法删除。

案例：
现有master节点
192.168.1.10 192.168.1.11 192.168.1.12
slave节点
192.168.1.20 192.168.1.21 192.168.1.22
需要下线192.168.1.10，用192.168.1.30代替。
注意被迁移 Redis 服务器必须保证没有数据

在192.168.1.10上执行迁移命令：

Redis 4：
redis-trib.rb reshard 192.168.1.30:6379

Redis 5：
redis-cli -a 123456 --cluster reshard 192.168.1.30:6379

M: 116c4c6de036fdbac5aaad25eb1a61ea262b64af 192.168.1.11:6379
	slots:[6827-10922] (4096 slots) master
	1 additional replica(s)
M: 70de3821dde4701c647bd6c23b9dd3c5c9f24a62 192.168.1.12:6379
	slots:[12288-16383] (4096 slots) master
	1 additional replica(s)
M: 886338acd50c3015be68a760502b239f4509881c 192.168.1.30:6379
	slots:[0-1364],[5461-6826],[10923-12287] (4096 slots) master 
	1 additional replica(s)
S: 7eda0bcf0c01bb7343313b81267c42dd1b26c8a6 192.168.1.21:6379
	slots: (0 slots) slave
	replicates 116c4c6de036fdbac5aaad25eb1a61ea262b64af
S: b9a00d59fa3c2a322080a1c7d84f53a2c853b089 192.168.1.31:6379
	slots: (0 slots) slave
	replicates 886338acd50c3015be68a760502b239f4509881c
S: 7186c6d03dd9a5e3be658f2d08e800bc55b04a09 192.168.1.20:6379
	slots: (0 slots) slave
	replicates f4cfc5cf821c0d855016488d6fbfb62c03a14fda
S: 2b6e5d9c3944d79a5b64a19e54e52f83d48438d6 192.168.7.22:6379
	slots: (0 slots) slave
	replicates 70de3821dde4701c647bd6c23b9dd3c5c9f24a62
M: f4cfc5cf821c0d855016488d6fbfb62c03a14fda 192.168.7.10:6379
	slots:[1365-5460] (4096 slots) master
	1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096 #迁移 master 上的多少个槽位
What is the receiving node ID? 886338acd50c3015be68a760502b239f4509881c #接收槽位的服务器 ID
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: f4cfc5cf821c0d855016488d6fbfb62c03a14fda #从哪个服务器迁移 4096 个槽位
Source node #2: done #写 done，表示没有其他 master 了
Moving slot 5457 from f4cfc5cf821c0d855016488d6fbfb62c03a14fda
Moving slot 5458 from f4cfc5cf821c0d855016488d6fbfb62c03a14fda
Moving slot 5459 from f4cfc5cf821c0d855016488d6fbfb62c03a14fda
Moving slot 5460 from f4cfc5cf821c0d855016488d6fbfb62c03a14fda
Do you want to proceed with the proposed reshard plan (yes/no)? yes #是否继续

迁移完成下一步是删除服务器

从集群删除节点

使用命令删除节点

Redis 4：
redis-trib.rb  del-node 192.168.1.10:6379

Redis 5：
redis-cli -a 123456 --cluster del-node 192.168.1.10:6379

删除节点后，要为192.168.1.10的slave分配新的master

为192.168.1.20分配新的master
1.先登录目标节点
redis-cli -h 192.168.1.20 -p 6379 -a 123456

2.查看节点ID
CLUSTER NODES

3.分配mstart
从第二步得知192.168.1.30的ID是886338acd50c3015be68a760502b239f4509881c
把slave分配给指定ID
CLUSTER REPLICATE 886338acd50c3015be68a760502b239f4509881c

至此集群节点删除完毕

集群导入现有数据

集群不能与被导入的数据有重复的key名称，否则导入不成功或中断。

导入前的准备
关闭各 redis 服务器的密码，包括集群中的各 node 和源 Redis server，避免认证带来的环境不一致从而无法导入，可以加参数–cluster-replace 强制替换 Redis cluster 已有的 key。

执行数据导入

从外部集群192.168.1.30节点导入数据到集群
Redis 4：
redis-trib.rb import --from 192.168.1.10:6379 --replace 192.168.1.30:6379

Redis 5：
redis-cli --cluster import 192.168.1.10:6379 --cluster-from 192.168.1.30:6379 --cluster-copy

zerocdn

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
redis消息队列、redis其他命令、redis主从配置、redis主从复制过程、主从同步优化、哨兵配置、集群配置、集群添加节点、集群手动修改节点状态、集群删除节点、集群导入现有数据

redis消息队列消息队列主要分为两种，分别是生产者消费者模式和发布者订阅者模式，这两种模式 Redis 都支持1.生产者消费者模式在生产者消费者(Producer/Consumer)模式下，上层应用接收到的外部请求后开始处理其当前步骤的操作，在执行完成后将已经完成的操作发送至指定的频道(channel)当中，并由其下层的应用监听该频道并继续下一步的操作，如果其处理完成后没有下一步的操作就直接返回数据给外部请求，如果还有下一步的操作就再将任务发布到另外一个频道，由另外一个消费者继续监听和处理。生产者
复制链接

扫一扫