redis集群机器扩容机器的内存

生产上的redis使用一段使用后,数据量很大,redis的内存不足,需要扩容机器的内存。

教训1:这个扩容一定要尽早去做。在机器剩余内存在500M左右去做。我是剩余100M的时候做的迁移,就很有问题。我是先用bgsave保存下数据。发现机器的的内存直接使用99%,swap也被快用完了,备份的速度极其的慢。4百万的数据,dump.rdb的文件有2.7G大小。备份了7个小时,读写极其慢,而且这个时候redis机器还做了主从切换,数据完全同步不了,在从库上看主从状态是down的状态。
教训2:备份是检测机器的基础配置,备份完查看备份文件。我当时直接跑指令,看命令行也是成功的,但是没有检查备份的文件和日志。我扩容好了之后重启服务发现数据没有了,我再去看文件发现是空的,没有备份成功。还好是集群,我从其他的机器把这个文件拿过来,启动就好了

主要系统的文件打开数:

[root@redis1-roster ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63456
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63456
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

我在执行bgsave时日志报:

3852:S 14 Aug 2020 21:36:10.676 * Background saving started by pid 3890
3890:C 14 Aug 2020 21:36:10.691 * DB saved on disk
10694:S 14 Aug 21:07:23.100 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
10694:S 14 Aug 21:07:23.100 # Server can't set maximum open files to 10032 because of OS error: Operation not permitted.

这个显示已经开启保存,但是文件打开数不够,需要增加文件打开数。我当时没有看到,然后最后看到的情况就是:
在这里插入图片描述
dump.rdb 是空的。我从其他节点的机器cp过来这个文件,在启动下:
数据
数据量对的,正常。
但是因为主库正在备份,但是没有内存,同步不了,主从状态异常。
在这里插入图片描述
master_link_status状态是down的,获取不到。只有等主节点保存完毕,然后扩容完成。再去启动查看状态。
slave状态正常的。
在这里插入图片描述

### Redis 不同运行模式的工作原理 #### Redis 主从复制工作原理 在主从复制架构中,Redis 使用一个或多个从服务器来备份主服务器中的数据。当客户端向主服务器发送写请求时,主服务器会先执行命令并更新自己的状态,再将该操作记录到内存缓冲区,并通过网络传输给所有的从服务器[^1]。 为了实现这一过程,在配置文件 `redis.conf` 中设置端口、日志路径等基本信息之后,还需要指定主节点地址以建立连接关系: ```bash replicaof 172.0.0.1 8002 ``` 此指令使得当前实例成为另一台机器上监听于特定端口号的服务之副本[^2]。 #### Redis 哨兵机制工作原理 哨兵系统用于监控和管理 Redis 的高可用性。它能够自动检测主服务器是否失效,并触发故障转移流程,即挑选一个新的健康从服务器晋升为主服务器继续提供服务。这期间涉及到了一系列复杂的选举算法以及通知其他成员的过程。 具体来说,每个哨兵进程定期与其他哨兵通信,共享关于被监视的主服务器的信息;一旦发现某个主服务器不可达,则发起投票决定哪个从服务器应该升级为新的主服务器[^3]。 #### Redis 集群架构工作原理 集群是由一组相互独立却又协同工作的 Redis 节点构成的整体解决方案。这些节点之间可以相互通信,并且支持数据分区存储——即将整个键空间划分为若干片段分布至不同物理位置上的各个节点之中。 在一个典型的 Redis Cluster 设置里,除了基本的数据读写外,还实现了哈希槽的概念,共有 16384 个哈希槽,每条记录根据其 key 计算得到所属的具体编号范围内的某一位作为最终存放地点指示器。这种设计不仅提高了系统的扩展性和容错能力,而且允许水平分割负载压力,从而更好地应对大规模并发访问需求。 #### 各种模式之间的比较 | 特征 | 主从复制 | 哨兵机制 | 集群 | | --- | --- | --- | --- | | 数据冗余 | 是 | 是 | 是 | | 自动故障恢复 | 否 | 是 | 是 | | 扩展性 | 较差 (仅限垂直扩容) | 改善但有限 | 极佳 (水平扩容) | | 客户端复杂度 | 简单 | 中等 | 复杂 | 综上所述,对于不同的应用场景可以选择最适合的一种或多组合方式部署 Redis 来满足业务需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值