Redis持久化

RDB

1.RDB介绍

  在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

  Redis会单首创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程当中，主进程是不进行任何IO操做的，这就确保了极高的性能若是须要进行大规模数据的恢复，且对于数据恢复的完整性不是很是敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

  Fork的做用是复制一个与当前进程同样的进程。新进程的全部数据（变量、环境变量、程序计数器等）数值都和原进程一致，可是是一个全新的进程，并做为原进程的子进程。

[root@pluto bin]# redis-server /myredis/redis.conf [root@pluto bin]# redis-cli -p 6379 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> set k8 v8 OK 127.0.0.1:6379> set k9 v9 OK 127.0.0.1:6379> set k10 v10 OK 127.0.0.1:6379> set k11 v11 OK 127.0.0.1:6379>

[root@pluto bin]# ls -l 总用量 15456 -rwxr-xr-x. 1 root root 4589115 7月  17 19:20 redis-benchmark -rwxr-xr-x. 1 root root   22177 7月  17 19:20 redis-check-aof -rwxr-xr-x. 1 root root   45387 7月  17 19:20 redis-check-dump -rwxr-xr-x. 1 root root 4693066 7月  17 19:20 redis-cli lrwxrwxrwx. 1 root root      12 7月  17 19:20 redis-sentinel -> redis-server -rwxr-xr-x. 1 root root 6466469 7月  17 19:20 redis-server [root@pluto bin]# ls -l 总用量 15460 -rw-r--r--. 1 root root     101 7月  19 16:19 dump.rdb -rwxr-xr-x. 1 root root 4589115 7月  17 19:20 redis-benchmark -rwxr-xr-x. 1 root root   22177 7月  17 19:20 redis-check-aof -rwxr-xr-x. 1 root root   45387 7月  17 19:20 redis-check-dump -rwxr-xr-x. 1 root root 4693066 7月  17 19:20 redis-cli lrwxrwxrwx. 1 root root      12 7月  17 19:20 redis-sentinel -> redis-server -rwxr-xr-x. 1 root root 6466469 7月  17 19:20 redis-server [root@pluto bin]#

 

[root@pluto bin]# redis-server /myredis/redis.conf [root@pluto bin]# redis-cli -p 6379 127.0.0.1:6379> keys *  1) "k4"  2) "k5"  3) "k3"  4) "k7"  5) "k9"  6) "k6"  7) "k2"  8) "k8"  9) "k10" 10) "k11" 11) "k1"

[root@pluto bin]# rm -f dump.rdb [root@pluto bin]# cp dump_bk.rdb dump.rdb

 

2触发RDB快照

 

3如何恢复

 

3)优劣势

 

4如何中止

动态全部中止RDB保存规则的方法：redis-cli config set save ""

5总结

 

  AOF

1.AOF简介

  以日志的形式来记录每一个写操做，将Redis执行过的全部写指令记录下来(读操做不记录)，只许追加文件但不能够改写文件，redis启动之初会读取该文件从新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工做。

2. 开启AOF

 

[root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379 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> FLUSHALL OK 127.0.0.1:6379> SHUTDOWN not connected> exit   [root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379>   #若是想要获取上一次的k1 k2 k3 k4只须要编辑appendonly.aof移到末尾删除FLUSHALL便可

[root@pluto bin]# ll

3.修复

[root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379 Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected> exit [root@pluto bin]# redis-check-aof --fix appendonly.aof 0x              b4: Expected prefix 'a', got: '*' AOF analyzed: size=236, ok_up_to=180, diff=56 This will shrink the AOF from 236 bytes, with 56 bytes, to 180 bytes Continue? [y/N]: y Successfully truncated AOF [root@pluto bin]# redis-server /myredis/redis_aof.conf [root@pluto bin]# redis-cli -p 6379

4.Rewrite

 

5.优劣势

 

6.总结

 

总结

 

由于RDB文件只用做后备用途，建议只在Slave上持久化RDB文件，并且只要15分钟备份一次就够了，只保留save 900 1这条规则。   若是Enalbe AOF，好处是在最恶劣状况下也只会丢失不超过两秒数据，启动脚本较简单只load本身的AOF文件就能够了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程当中产生的新数据写到新文件形成的阻塞几乎是不可避免的。只要硬盘许可，应该尽可能减小AOF rewrite的频率，AOF重写的基础大小默认值64M过小了，能够设到5G以上。默认超过原大小100%大小时重写能够改到适当的数值。   若是不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也能够。能省掉一大笔IO也减小了rewrite时带来的系统波动。代价是若是Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构