Redis---测试配置及添加slave主机

news/2024/11/30 9:51:08/

一、测试集群功能

测试高可用

1、停止 master 主机的 redis 服务

master 宕机后对应的 slave 自动被选举为 master，原 master 启动后，会自动配置为当前 master 的 slave

2、检测集群

mgm68管理主机，查看集群信息
主服务器地址和端口(ID值) ——> 存储变量的个数 | 占用槽的个数 | 从服务器个数

[root@mgm68 ~]# redis-trib.rb info 192.168.4.63:6379		#选择任何节点均可，结果相同
[root@mgm68 ~]# redis-trib.rb check 192.168.4.65:6379

3、停止主节点服务，在redisC上操作

[root@redisC ~]# redis-cli -h 192.168.4.63 -p 6379 shutdown

mgm68管理主机，查看集群信息

[root@mgm68 ~]# redis-trib.rb info 192.168.4.61:6379	#4.64从服务器成为主服务器，从服务为0
192.168.4.64:6379 (28ff0eaf...) -> 0 keys | 5461 slots | 0 slaves.[root@mgm68 ~]# redis-trib.rb check 192.168.4.61:6379		#从服务器剩下两台

4、host50客户端访问集群存入数据

[root@host50 ~]# redis-cli -c -h 192.168.4.64 -p 6379
192.168.4.64:6379> keys *
192.168.4.64:6379> set v1 101
192.168.4.61:6379> set v2 102
192.168.4.61:6379> exit

5、重新启动redis服务，在redisC上操作，会成为redisD的从服务器

[root@redisC ~]# /etc/init.d/redis_6379 start
查看redis服务端口和集群端口是否开启
[root@redisC ~]# ss -ntulp | grep redis

6、mgm68查看集群状态信息

[root@mgm68 ~]# redis-trib.rb info 192.168.4.63:6379
[root@mgm68 ~]# redis-trib.rb check 192.168.4.61:6379		#4.63主机为4.64的从服务器

7、redis53查看数据是否同步

[root@redis ~]# redis-cli -c -h 192.168.4.63 -p 6379
192.168.4.63:6379> keys *			#数据同步，高可用验证成功

8、测试分布式存储、同步数据

客户端连接集群中任意服务器存/取数据

查看master节点上的数据，在redisA,redisB,redisD上操作
所有节点上的数据加起来，就是整个redis集群中的数据

[root@redis ~]# redis-cli -c -h 192.168.4.61 -p 6379
192.168.4.61:6379> keys *[root@redis ~]# redis-cli -c -h 192.168.4.62 -p 6379
192.168.4.62:6379> keys *[root@redis ~]# redis-cli -c -h 192.168.4.64 -p 6379
192.168.4.64:6379> keys *

9、工作原理

redisA       槽数:5461      范围:0-5460
redisB       槽数:5462      范围: 5461-10922
redisD       槽数:5461      范围: 10923-16383

CRC16算法：
存储数据时，对存入数据的变量名进行hash计算，用得到的数值和16384进行取余运算，看余数在那个范围之内，则将数据存储到对应的master节点上。

例如：存入变量bob,值为777, 对bob进行hash计算，值和16384取余后的值为10930, 在redisB的槽数范围内，bob变量就会被存储到redisB的master节点上。

在redis集群中，一对主从中，至少得有一个服务器处于正常的状态，才可以取出数据，否则集群中的数据会发生缺失。

10、添加主机，环境准备：

要添加的slave      主机名：redis71     IP地址：192.168.4.71/24
要添加的master     主机名：redis69     IP地址：192.168.4.69/24

redis71和redis69主机安装redis服务，开启集群功能

11、开启集群功能，以redis71为例，redis69同样操作，监听地址写本机的即可

[root@redis71 ~]# /etc/init.d/redis_6379 stop
[root@redis71 ~]# vim /etc/redis/6379.conf
70 bind 192.168.4.71			#修改客户端访问的地址，为本机物理网卡的地址
815  cluster-enabled yes					#取消注释，启用集群功能
823  cluster-config-file nodes-6379.conf		#取消注释，存储集群信息相关文件
829  cluster-node-timeout 5000				#设置集群通信的超时时间(5000秒)
[root@redis71 ~]# /etc/init.d/redis_6379 start
[root@redis71 ~]# ss -ntulp | grep redis
[root@redis71 ~]# redis-cli -h 192.168.4.71 -p 6379
192.168.4.71:6379> keys *		#做redis集群时，要保证所有的节点的数据为空
(empty list or set)
192.168.4.71:6379> cluster info		#查看集群的相关信息
cluster_state:fail          			#集群状态,失败

12、添加 slave 角色服务器

在管理服务器添加 slave 角色主机，添加时不指定主机角色，默认新主机被选为 master
–master-id id值：指定新添加的节点，作为哪个主服务器的slave；
如果不指定 master节点的id值，则会在集群中查看哪个主服务器的slave最少，将新添加的节点作为哪个主服务器的slave；
如果所有主服务器拥有slave数量相同，则将新添加的节点随机作为某个主服务器的slave；
ip地址:端口 指要添加的slave的地址和端口

192.168.4.61:6379 代指集群，可以是集群中的任意节点
[root@localhost ~]# redis-trib.rb  add-node  --slave 【--master-id  id值】  ip地址:端口   192.168.4.61:6379

13、给主服务器4.61再添加一个从服务器4.71，在mgm68上操作

check 查看集群的详细信息，获取4.61 master节点的ID值

[root@mgm68 ~]# redis-trib.rb check 192.168.4.61:6379
[root@mgm68 ~]# redis-trib.rb add-node --slave  --master-id  c1198049c748cd11daff4a2477bd9dcdb3358fba   192.168.4.71:6379  192.168.4.61:6379	# 192.168.4.61:6379 代指集群，可以是集群中的任意节点的IP和端口

14、查看集群信息：在管理主机查看信息，存取数据测试

[root@mgm68 ~]# redis-trib.rb info 192.168.4.61:6379	#主服务器4.61拥有两台从服务器
192.168.4.61:6379 (c1198049...) -> 4 keys | 5461 slots | 2 slaves.
[root@mgm68 ~]# redis-trib.rb check 192.168.4.61:6379

15、查看集群信息，在redis71上操作

[root@redis71 ~]# redis-cli -h 192.168.4.71 -p 6379
192.168.4.71:6379> cluster info		#节点内查看集群的状态信息
cluster_state:ok           				#集群状态OK
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:7      	#集群中节点的数量为7台
cluster_size:3   					#集群中主服务器的个数为3台
192.168.4.71:6379> keys *		#数据同步成功

二、管理集群之添加master主机

添加 master 角色服务器 (当集群中内存不足时添加)
这里使用redis69主机做此实验，环境已经准备完成

添加 master 主机步骤：添加 master 主机，分配 hash 槽（slots）

在管理主机向集群添加新主机：添加时不指定主机角色，默认新主机被选为 master

1、将4.69作为master服务器添加到redis的集群中

[root@mgm68 ~]# redis-trib.rb add-node 192.168.4.69:6379  192.168.4.66:6379		#192.168.4.66:6379 代指集群，可以是集群中的任意节点的IP和端口
[root@mgm68 ~]# redis-trib.rb info 192.168.4.61:6379

4.69 已经成为了主服务器，但是slots(hash槽)的数量为0，而redis集群存储数据是根据slots进行的，所有数据不会被存储到4.69上，需要重新分配hash槽

重新分片：移出 hash 槽个数，接收 hash 槽主机 ID，移出 hash 槽主机 ID，同意配置
reshard 对hash槽进行重新分配; 最后的IP和端口可以选择集群中任意主机

[root@mgm68 ~]# redis-trib.rb reshard 192.168.4.61:6379

计算四个主服务器，每个服务器平均的槽数为：16384/4 = 4096
从集群中要移出多少个槽：4096个(用于给新的master服务器)
How many slots do you want to move (from 1 to 16384)? 4096
ID 指定集群中的节点, 哪个节点将接收从集群中移出的4096个hash槽
这里给4.69主机(新的master节点)分配hash槽
What is the receiving node ID? d4d193c429616a95f2b1a4a5dacb26b9a88be549
选择从所有master节点拿出hash槽，还是从单一的master节点拿出hash槽，用于分配给新的master节点4.69
如果要从单个master中拿出hash槽，后面写master对应的ID值
这里选择all,从所有的master节点拿出hash槽，总数为4096个

Please enter all the source  node IDS.Type 'all'  to user all the nodes as source  nodes  for the hash slots.Type 'done' once you  entered  all the source nodes IDs.
Source node #1: all      
...
Do you want to proceed with the proposed reshard plan (yes/no)? yes

2、测试配置：管理主机查看集群信息，连接新 master 主机存取数据

mgm68重新查看redis集群信息，每个主服务器都有4096个hash槽
[root@mgm68 ~]# redis-trib.rb info 192.168.4.61:6379
[root@mgm68 ~]# redis-trib.rb check 192.168.4.61:6379

3、host50测试，连接新的master,存取数据

[root@redis ~]# redis-cli -c -h 192.168.4.69 -p 6379
192.168.4.69:6379> keys *
192.168.4.69:6379> set k1 99
192.168.4.64:6379> set k2 199
192.168.4.69:6379> keys *

三、管理集群之删除主机

移除 slave 主机：从服务器没有 hash 槽，直接移除即可；移除时指定从服务器 id 值
移除slave从服务器4.65，在mgm68上操作
移除slave主机，需要获取4.65主机的ID值，可以通过check 获取

[root@mgm68 ~]# redis-trib.rb check 192.168.4.61:6379
S: 5aab79c9c6c27420884203a3bf2f86697354c31a 192.168.4.65:6379
[root@mgm68 ~]# redis-trib.rb  del-node  192.168.4.61:6379 5aab79c9c6c27420884203a3bf2f86697354c31a		#del-node 根据4.65的ID值，删除集群中的slave 4.65，192.168.4.61:6379 指定集群，可以是集群中任意节点SHUTDOWN the node.         #会停止被移除主机的redis服务
[root@mgm68 ~]# redis-trib.rb info 192.168.4.61:6379	#4.69主机的从服务器4.65被移除
192.168.4.69:6379 (d4d193c4...) -> 6 keys | 4096 slots | 0 slaves.
[root@redis65 ~]# ss -ntulp | grep redis		#服务被停止

移除 master 服务器：释放占用的 hash 槽，移除主机
释放占用的 slots
指定移出 slots 个数
指定接收 slots 主机ID
指定移出 slots 主机ID

释放4.61主服务器占用的hash槽给到64主机，在mgm68上操作

[root@mgm68 ~]# redis-trib.rb info 192.168.4.61:6379	#获取要被移除主机的槽数(slots)
192.168.4.61:6379 (c1198049...) -> 2 keys | 4096 slots | 0 slaves.

reshard  重新分配hash槽数
[root@mgm68 ~]# redis-trib.rb  reshard  192.168.4.61:6379这里写要被移除的master节点的槽数(slots):4094
How many slots do you want to move (from 1 to 16384)?  4096移除的4096个hash槽分配给哪个主机，写主机的ID号
这里分配给master节点4.64
What is the receiving node ID?  28ff0eaf0da4a8f256d6e57453d7fdbd2ae591e1
选择从所有master节点拿出hash槽，还是从单一的master节点拿出hash槽
如果要从单个master中拿出hash槽，后面写master对应的ID值
这里选择all,从所有的master节点拿出hash槽，总数为4096个
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.
这里是从4.61主机中移除hash槽,如果只从一台主机中移除，后面写done即可  
Source node #1:c1198049c748cd11daff4a2477bd9dcdb3358fba
Source node #2:done
Do you want to proceed with the proposed reshard plan (yes/no)?yes[root@mgm68 ~]# redis-trib.rb info 192.168.4.61:6379		#要被移除的master节点4.61, hash槽数为0
192.168.4.61:6379 (c1198049...) -> 0 keys | 0 slots | 0 slaves.
[root@mgm68 ~]# redis-trib.rb check 192.168.4.61:6379		#移除master主机，需要获取4.61主机的ID值
M: c1198049c748cd11daff4a2477bd9dcdb3358fba 192.168.4.61:6379[root@mgm68 ~]# redis-trib.rb del-node 192.168.4.61:6379 c1198049c748cd11daff4a2477bd9dcdb3358fba		#del-node 根据4.61的ID值，删除集群中的master节点4.61，192.168.4.61:6379 指定集群，可以是集群中任意节点
SHUTDOWN the node.       #会停止被移除主机的redis服务将hash槽数平均分配到所有master服务器上
[root@mgm68 ~]# redis-trib.rb info 192.168.4.62:6379
rebalance  将hash槽数平均分配到所有master服务器上
[root@mgm68 ~]#  redis-trib.rb rebalance 192.168.4.62:6379
[root@mgm68 ~]# redis-trib.rb info 192.168.4.62:6379	#所有master节点slots平均分配

把移除的redis服务器重新加入到redis集群中

当集群中的节点被移除后，该节点主机的默认数据目录下的文件 nodes-6379.conf 依然保存着集群信息，所以当重复添加时会报错，需要将其删除或通过集群命令重置

[root@redisA ~]# /etc/init.d/redis_6379 start 
[root@redisA ~]# ss -ntulp | grep redis

验证集群信息，并通过集群命令，重置集群配置文件

[root@redisA ~]# redis-cli -h 192.168.4.61
192.168.4.61:6379> cluster info     #查看集群信息
cluster_state:ok                    #已经被移除，但还是OK状态
192.168.4.61:6379> cluster reset    	#重置集群配置文件内的信息
192.168.4.61:6379> cluster info      #查看集群信息
cluster_state:fail                   #fail状态，重置成功
192.168.4.61:6379> cluster nodes		#查看集群节点信息，只有本机，清除成功
c1198049c748cd11daff4a2477bd9dcdb3358fba 192.168.4.61:6379@16379 myself,master - 0 1601368935353 1 connected

将4.61作为master服务器添加到redis的集群中

[root@mgm68 ~]# redis-trib.rb add-node 192.168.4.61:6379  192.168.4.62:6379

4.61 master节点添加成功，hash槽数目前为0,需要重新分配

[root@mgm68 ~]# redis-trib.rb info 192.168.4.62:6379
192.168.4.61:6379 (c1198049...) -> 0 keys | 0 slots    | 0 slaves.

重新分配hash槽 (slots)

[root@mgm68 ~]# redis-trib.rb  reshard  192.168.4.62:6379
#获取4.61主服务器的ID号，用于接收hash槽
M: c1198049c748cd11daff4a2477bd9dcdb3358fba 192.168.4.61:6379#从集群中要移出20个槽，用于给新的master服务器
How many slots do you want to move (from 1 to 16384)?  20
#ID 指定集群中的节点, 哪个节点将接收从集群中移出的20个hash槽
#这里给4.61主机(新的master节点)分配hash槽
What is the receiving node ID? c1198049c748cd11daff4a2477bd9dcdb3358fba#这里是从4.62节点上拿出20个hash槽，done为结束
Source node #1:c503c5db7fe80512cfc990b793f67af675ba4370
Source node #2:done   
Do you want to proceed with the proposed reshard plan (yes/no)? yes

查看集群信息，集群中hash槽(slots)的数量不平均，数据被存储到 4.61节点上的几率很低，需要平均分配hash槽(slots)

[root@mgm68 ~]# redis-trib.rb info 192.168.4.62:6379
平均分配hash槽 (slots)， slots 平均分配的前提，是所有的 master 都必须有hash槽
[root@mgm68 ~]# redis-trib.rb rebalance 192.168.4.62:6379
[root@mgm68 ~]# redis-trib.rb info 192.168.4.62:6379		#再次查看，已经平均分配

http://www.ppmy.cn/news/47564.html

相关文章

python笔记：datetime

python笔记：datetime

处理日期和时间 1 常量 MINYEAR datetime允许的最小年份 MAXYEAR datetime允许的最大年份 2 数据类型 datetime.date带有属性year,month,daydatetime.time带有属性hour,minute,second,microsecond,tzinfodatetime.datetime带有属性year,month,day,hour,minute,second,…
阅读更多...
22勤于思考：gRPC都有哪些优势和不足？

22勤于思考：gRPC都有哪些优势和不足？

如果你能从专栏的开篇词开始读到这篇文章并且能够在过程中认真思考，那么我相信你目前已经能够对gRPC有了较为充分了解。在专栏的最后几节中，我们抽出一篇文章。来探讨一下gRPC有哪些优势和不足，因为只有这样我们才能取其精华，去其糟粕，学习gRPC框架设计的优点，还能反观出…
阅读更多...
Nacos服务端健康检查-篇五

Nacos服务端健康检查-篇五

Nacos服务端健康检查-篇五 🕐Nacos 客户端服务注册源码分析-篇一 🕑Nacos 客户端服务注册源码分析-篇二 🕒Nacos 客户端服务注册源码分析-篇三 🕓Nacos 服务端服务注册源码分析-篇四 上篇分析l服务端的注册服务的整个流程&…
阅读更多...
大四的告诫

大四的告诫

👂 LOCK OUT - $atori Zoom/KALONO - 单曲 - 网易云音乐 👂 喝了一口星光酒（我只想爱爱爱爱你一万年） - 木小雅 - 单曲 - 网易云音乐 其实不是很希望这篇文章火，不然就更卷了。。 从大一开始，每天10小时…
阅读更多...
mysql 事务的 ACID 特征与使用

mysql 事务的 ACID 特征与使用

事务的四大特征： A 原子性：事务是最小的单位，不可以再分割；C 一致性：要求同一事务中的 SQL 语句，必须保证同时成功或者失败；I 隔离性：事务1 和 事务2 之间是具有隔离性的&#xff1…
阅读更多...
【性能测试】5年测试老鸟，总结性能测试基础到指标，进阶性能测试专项......

【性能测试】5年测试老鸟，总结性能测试基础到指标，进阶性能测试专项......

目录：导读 前言一、Python编程入门到精通二、接口自动化项目实战三、Web自动化项目实战四、App自动化项目实战五、一线大厂简历六、测试开发DevOps体系七、常用自动化测试工具八、JMeter性能测试九、总结（尾部小惊喜） 前言 性能测试是为了评…
阅读更多...
软文推广：真实有效提升软文排名与收录的三大方法！

软文推广：真实有效提升软文排名与收录的三大方法！

软文是一种具有良好传播效果的文体，可以通过在搜索引擎中排名靠前的方式，为品牌或企业带来更多曝光。但是，如何让软文在搜索引擎中得到更好的收录和排名呢？在本文中，我们将讨论如何提升软文的收录和排名，以…
阅读更多...
Unity记录3.4-地图-柏林噪声生成 1D 地图及过渡地图

Unity记录3.4-地图-柏林噪声生成 1D 地图及过渡地图

文章首发及后续更新：https://mwhls.top/4489.html，无图/无目录/格式错误/更多相关请至首发页查看。 新的更新内容请到mwhls.top查看。 欢迎提出任何疑问及批评，非常感谢！ 汇总：Unity 记录 摘要：柏林噪声生成…
阅读更多...
最新文章

Copyright @ 2022~2023