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

  • 相关阅读:
    IO多路复用
    Elasticsearch之打分机制、集群搭建、脑裂问题
    Elasticsearch之-映射管理,ik分词器
    Elasticsearch之高亮查询,聚合查询
    Elasticsearch之索引、文档、组合查询、排序查询、filter过滤操作
    Go 数组、切片、Maps
    Go if-else语句、for循环、switch语句
    Go 函数、包、mode模式
    毕业设计-1.05
    毕业设计-1.04
  • 原文地址:https://www.cnblogs.com/CSAH/p/13837751.html
Copyright © 2020-2023  润新知