Redis持久化

发布时间：2020-12-16 04:36:13 所属栏目：安全来源：网络整理

导读：RDB 1.RDB介绍 ?? 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 Snapshot快照，它恢复时是将快照文件直接读到内存里。 ??Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用

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

127.0.0.1:6379> set k2 v2

127.0.0.1:6379> set k3 v3

127.0.0.1:6379> set k4 v4

127.0.0.1:6379> set k5 v5

127.0.0.1:6379> set k6 v6

127.0.0.1:6379> set k7 v7

127.0.0.1:6379> set k8 v8

127.0.0.1:6379> set k9 v9

127.0.0.1:6379> set k10 v10

127.0.0.1:6379> set k11 v11

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

127.0.0.1:6379> set k2 v2

127.0.0.1:6379> set k3 v3

127.0.0.1:6379> set k4 v4

127.0.0.1:6379> FLUSHALL

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文件，载入较新的那个。新浪微博就选用了这种架构

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!