环境简述及需求(这里不考虑主从,此文是自己的小笔记,大佬勿喷):
正在运行的Redis的持久化方案采用系统默认的RDB;而RDB无法满足准实时的数据落盘的要求(一般为300秒大于10次写操作才执行fork操作,而如果在下一次fork操作触发前发生故障会导致15分钟内的数据丢失);而AOF的出现解决了RDB的问题,能够实现准实时或秒级数据落盘的功能(AOF采用的日志记录的方式将发生的写操作记录到appendonly.aof文件中);
问题点(坑):
因为当前正在运行的Redis库中已经有数据了,如果通过vi修改redis.conf配置文件开启AOF的重启服务的话,Redis启动时会优先从appendonly.aof中读取数据,但此时aof文件是空的进而导致Redis此时为空库,如果你之前又没有备份dump.rdb的话,那么可以看看如何跑路吧!
解决思路: 在服务运行的情况下,热状态开启AOF
大致过程:
1, 查看库中数据并关闭服务
[root@ansible ~]# redis-cli -p 6379
127.0.0.1:6379> KEYS *
- "k4"
- "k5"
- "k3"
- "k1"
- "k2"
127.0.0.1:6379> SHUTDOWN
not connected> exit
2, 修改配置文件开启AOF
[root@ansible 6379]# vim /myredis/redis.conf
appendonly yes
3, 启动服务并查看库中数据
[root@ansible ~]# redis-server /myredis/redis.conf
[root@ansible ~]# redis-cli -p 6379
127.0.0.1:6379> KEYS *
(empty list or set)
好了,库已经空了;可以下班了...
所以, 运维要养成两个好习惯,
一, 不要轻易使用rm命令(可以将要删除的文件通过mv命令移动到tmp目录下,核对无误后去tmp目录下执行删除命令);
二, 备份!备份!!还是备份!!!
4, 通过备份dump.rdb恢复数据
[root@ansible 6379]# mv appendonly.aof /tmp/
[root@ansible 6379]# mv dump.rdb /tmp/
[root@ansible 6379]# cp /data/backup/redis/6379/dump.rdb ./
[root@ansible ~]# redis-server /myredis/redis.conf
[root@ansible ~]# redis-cli -p 6379
127.0.0.1:6379> KEYS *
- "k1"
- "k3"
- "k4"
- "k2"
可以看到我用来恢复数据的dump.rdb文件中没有k5的数据,如果这是个热点数据可能会引发缓存击穿的情况发生(库都停了早就雪崩了...)
5, 热状态开启AOF
127.0.0.1:6379> CONFIG set appendonly yes
OK
把配置信息修改持久化
127.0.0.1:6379> CONFIG REWRITE
OK
可以看到aof文件已经生成
[root@ansible 6379]# ll
total 8
-rw-r--r-- 1 root root 196 Apr 16 10:10 appendonly.aof
-rw-r--r-- 1 root root 54 Apr 16 10:10 dump.rdb
最后,还是要提前规划化好要采用的持久化方案,主备已经哨兵模式(后期我应该会写主从和多哨兵部署过程,至于缓存穿透\缓存击穿\雪崩等相关知识等我搞明白再说吧-);
写给自己:少摸鱼,多学习中年人!!!
