Linux持久化之RDB操作【redis】

Redis持久化( 面试和工作持久化都是重点)！！！

Redis是内存数据库，如果不将内存中的数据库 状态保存到磁盘，那么一旦服务器进程退出，服务器的数据库状态也会消失
所以Redis提供了持久化操作

什么是RDB

在指定时间间隔后，将内存中的数据集快照写入磁盘 ；也就是行话说到Snapshot快照，它恢复时候直接读取快照文件到内存，进行数据的恢复 ；Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束，再用这个临时文件替换上次持久化好的文件，整个过程主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常铭感，那么RDB要比AOF方式更加高效，RDB的缺点是最后一次持久化的数据可能丢失，我们默认的就是RDB，一般情况不会修改这个配置！

默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。文件名可以在配置文件中进行自定义。（redis.config）

工作原理

在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，主线程会 fork 一个子线程来完成该操作；
Redis 调用forks。同时拥有父进程和子进程。子进程将数据集写入到一个临时 RDB 文件中。当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。)

触发机制

save的规则满足的情况下，会自动触发rdb原则
执行flushall命令，也会触发我们的rdb原则
退出redis，也会自动产生rdb文件

测试

来自配置文件(redis.conf)

save 900 1 # 每900秒修改一次就会触发save
save 300 10 # 每300秒修改10次会触发save
save 60 10000 # 每60秒修改10000次就会触发save

如果我把上面的代码进行修改

#save 900 1 # 每900秒修改一次就会触发save
#save 300 10 # 每300秒修改10次会触发save
#save 60 10000 # 每60秒修改10000次就会触发save
save 60 5     # 每60秒修改5次出发save

1.首先查看会话(Xshell里面的会话1 20001107)然后打开bin目录下的文件

[root@GongQlLong bin]# ls
dump.rdb 
redis-benchmark
redis-check-rdb  
redis.conf      
redis-server
gongconfig  
redis-check-aof  
redis-cli        
redis-sentinel

2.删除bin目录下的dump.rdb
（注意这个时候已经没有了(dump.rdb）

[root@GongQlLong bin]# rm -rf dump.rdb 
[root@GongQlLong bin]# ls
gongconfig 
redis-benchmark 
redis-check-aof  
redis-check-rdb 
redis-cli 
redis.conf
redis-sentinel  
redis-server

3.这个时候去启动另一个会话(2 20001107)我们在六十秒内完成以下Linux命令

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> set k6 v6
OK
127.0.0.1:6379> set k7 v7
OK
127.0.0.1:6379> shutdown

4.当我们再次打开会话1时候查看bin下的文件，会发现出现了一个新的

[root@GongQlLong bin]# ls
dump.rdb    
redis-benchmark  
redis-check-rdb  
redis.conf      
redis-server
gongconfig  
redis-check-aof  redis-cli        
redis-sentinel

这就说明我们触发了save规则，会自动产生rdb文件

这个时候我们就算是重启了redis，然后再打卡我们依然可以访问到，关掉之前的值(已经触发save)

127.0.0.1:6379> get k1
"v1"

save

• 使用 save 命令，会立刻对当前内存中的数据进行持久化 ,但是会阻塞，也就是不接受其他操作了；
• 由于 save 命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。

flushall命令
flushall 命令也会触发持久化 ；(可以自己尝试，就和之前一样先删除会话一的dump.rdb文件，然后打开会话2，执行flushall,就会发现bin目录重新生成新的dump.rdb)

触发持久化规则
满足配置条件中的触发条件 ；

可以通过配置文件对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动进行数据集保存操作。

如何恢复rdb文件

1. 只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据
2. 查看需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"

如果在这个目录下面存在dump.db文件，启动就会自动恢复其中的数据

优缺点

优点：

• 适合大规模的数据恢复
• 对数据的完整性要求不高

缺点：

• 需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次 修改的数据就没有了。
• fork进程的时候，会占用一定的内容空间。(其实大可不必在乎那么点内存吧)

一般生产环境会备份rdb文件！！！