Redis持久化

发布时间:2018-11-15  栏目:NoSQL  评论:0 Comments

Redis持久化

常规配置Redis.conf

  1. Redis默认不是因守护线程启动的,可用通过部署,使用yes启用守护线程启动

    daemonize no

  2. 当Redis使用守护进程运行时,Redis会把pid写入/var/run/redis.pid文件,可以经过pidfile指定

    pidfile /var/run/redis.pid

  3. 指定Redis监听端口,默认是6379

    port 6379

  4. 绑定主机地址

    bind 127.0.0.1

  5. 当客户端闲置多长时间后关闭连接,如果指定为0.表示关闭该功功能

    timeout 300

  6. 点名日志记录级别,Redis总共支持级别:debug、verbose、notice、warning,默认是verbose

    loglevel verbose

  7. 日志记录道,默认为业内输出,若果配置Redis为护理线程方式运行,而这边还要布置也日志记录道吧规范输出,则日志会发送至、/dev/null

    logfile stdout

  8. 点名在多长时间内,有稍许次创新操作,就用数据并到数据文件中,可以多独规范相当

    save <seconds> <changes>
    Redis默认配置文件被提供三单原则:
    save 900 1
    save 300 10
    save 60 10000
    个别表示900秒(15分钟)内产生一个翻新。。。。。。。
    若是想手动保存 命令(save)

  9. 指定地方数据库存放目录

    dir ./

  10. 装密码,如果安了密码,AUTH <password>命令提供密码

    requirepass foocared

  11. 安同一时间最要命之客户端连接数,默认无界定,如果超过设置数,Redis会关闭新的连接冰向客户端返回max
    number of clients reached 错误

    maxclients 128
    17 .
    指定Redis最可怜莫抱限制,Redis在开行时见面以数据加载到外存中,达到极端酷内存后,Redis会首先尝试清除到期或即将到期的key,当是方式处理后,仍然高达内存设置,将无法以进展摹写操作,但照样可以进行读取操作。Redis新的VM机制,会拿key存放在内存,value存放在Swap区
    maxmemory <bytes>

因Redis是内存数据库,它将团结的数据库状态储存在内存里面,所以要未思量方法用储存在内存中之数据库状态保存及磁盘里面,那么要服务器进程退出,服务器中之数据库状态也会见磨不见。

Redis的持久化

Redis支持少数种持久化方式外存快照RDB(Redis
DataBase)和日志AOF(Append-only file)。

RDB(Redis DataBase)

 

优点

  • RDB是一个充分严密的文书
  • RDB于保存RDB文件时大人进程唯一用做的哪怕是fork出一个经过,接下的做事满由子进程来做,父进程不需举行其他IO操作,所以RDB持久化方式可最大化Redis的性。
  • 及AOF相比,再回复很的数据集的时刻,RDB方式会重快一些。

一、RDB

缺点

  • 数据丢失风险特别
  • RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较深之时段,fork的长河是雅耗时的,可能会见招致Redis在一些毫秒级不能够响应客户端请求

为化解者问题,Redis提供了RDB持久化功能,这个效应可以将Redis在内存中之数据库状态保存及磁盘里面,避免数据竟然遗失。RDB持久化既好手动执行,也堪依据服务器配置选定期执行,该功能可以以某时刻接触达到之数据库状态保存及一个RDB文件被,RDB持久化功能所生成的RDB文件是一个透过压缩的二进制文件,通过该公文可以还原生成RDB文件时之数据库状态。

AOF(Append Only File)

  • 修复aof文件

    redis-check-aop -fix appendonly.aop

  • 开启AOF持久化数据

    appendonly = yes

  • 持久化文件名称

    appendfilename

  • appendfsync (持久化策略)

    • Always
      同步持久化,每次发生多少变更会被及时记录到磁盘,性能于差而数额的完整性比较好
    • Everysec:出厂默认推荐,异步操作,每秒记录,如果同秒内宕机,有数量丢失
    • NO
  • NO-appendfsync-on-rewrite:
  • 优势
    • AOF文件是一个展开追加的日志文件
    • Redis可以于AOF文件体积变得过深时,自动的以后台对AOF进行重写
    • AOF文件有序的保留了针对数据库执行之备写操作,这些写入操作以Redis共商的格式保存,因此AOF文件的情非常容易被人读懂,对文件进行分析也异常自在
  • 缺点
    • 对同一之数据集来说,AOF文件之体积通常如果超过RDB文件之体积
    • 尤其就所有以的点子fsync策略,AOF的进度或会见慢吃RDB
  • 法定建议
    • RDB持久化方式能够当指定的年华间隔会针对你的数量开展快照存储
    • AOF持久化方式记录每次对服务器写的操作,当服务器又开的当儿会重新履行这些命令来恢复原始之数量,AOF命令以Redis协议追加保存每次写的操作及文件的结尾。
    • Redis还能针对AOF文件进行后台重写,是的AOF文件之体积不至于过十分
    • 惟有做缓存:如果你独自希望你的数以服务器运行的时是,你吧得不适用其他持久化方式
    • 还要拉开俩栽持久化方式:
      • 这种景象下,当redis重开的时刻会先行载入AOF文件来平复原始之数目,因为当日常情况下AOF文件保留之数码集要比RDB文件保留的数额集要完整。
      • RDB的数量不实时,同时使用两者时服务器又开时为就见面寻找AOF文件,那若无使才行使AOF呢?建议不要,应为RDB更同步适用于备份数据库(AOF在相连变动不好备份),快速又开,而且不见面出AOF可能潜在的bug,留着当一个而底招数。
  • RDB文件之开创

出少数只Redis命令可以用来生成RDB文件,一个凡是SAVE,另一个凡是BGSAVE。

  1)SAVE命令会阻塞Redis服务器进程,直到RDB文件创建完毕了,在服务器进程阻塞期间,服务器无可知处理任何命令请求。

缔造RDB文件之实际工作由rdb.c/rdbSave函数完成,SAVE命令和BGSAVE命令会以不同的主意调用这个函数:

 

int rdbSave(char *filename, rdbSaveInfo *rsi) {
    #创建RDB文件
    char tmpfile[256];
    char cwd[MAXPATHLEN]; /* Current working dir path for error messages. */
    FILE *fp;
    rio rdb;
    int error = 0;
    snprintf(tmpfile,256,"temp-%d.rdb", (int) getpid());
    fp = fopen(tmpfile,"w");
    if (!fp) {
        char *cwdp = getcwd(cwd,MAXPATHLEN);
        serverLog(LL_WARNING,
            "Failed opening the RDB file %s (in server root dir %s) "
            "for saving: %s",
            filename,
            cwdp ? cwdp : "unknown",
            strerror(errno));
        return C_ERR;
  }
  /* Make sure data will not remain on the OS's output buffers */
  if (fflush(fp) == EOF) goto werr;
  if (fsync(fileno(fp)) == -1) goto werr;
  if (fclose(fp) == EOF) goto werr;
  /* Use RENAME to make sure the DB file is changed atomically only if the generate DB file is ok. */
  if (rename(tmpfile,filename) == -1) {
      char *cwdp = getcwd(cwd,MAXPATHLEN);
      serverLog(LL_WARNING,"Error moving temp DB file %s on the final " 
      "destination %s (in server root dir %s): %s",tmpfile,filename,cwdp ? cwdp : "unknown",strerror(errno));
      unlink(tmpfile);
      return C_ERR;
   }
  serverLog(LL_NOTICE,"DB saved on disk");
      server.dirty = 0;
      server.lastsave = time(NULL);
      server.lastbgsave_status = C_OK;
      return C_OK;
  werr:
      serverLog(LL_WARNING,"Write error saving DB on disk: %s", strerror(errno));
      fclose(fp);
      unlink(tmpfile);
      return C_ERR;
}

 

  2)和SAVE命令直接阻塞服务器进程的做法各异,BGSAVE命令会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程(父进程)继续处理命令请求。

  #创建子进程
    pid = fork()
    if pid == 0:
        #子进程负责创建RDB文件
        rdbSave()
        #完成之后向父进程发送信号
        signal_parent()
    elif pid > 0:
        #父进程继续处理命令请求,并通过轮询等待子进程的信号
        handle_request_and_wait_signal()
    else:
        #处理出错情况
        handle_fork_error()

int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
    pid_t childpid;
    long long start;

    if (server.aof_child_pid != -1 || server.rdb_child_pid != -1) return C_ERR;

    server.dirty_before_bgsave = server.dirty;
    server.lastbgsave_try = time(NULL);
    openChildInfoPipe();

    start = ustime();
    if ((childpid = fork()) == 0) {
        int retval;
    /* Child */
        closeListeningSockets(0);
        redisSetProcTitle("redis-rdb-bgsave");
        retval = rdbSave(filename,rsi);
        if (retval == C_OK) {
            size_t private_dirty = zmalloc_get_private_dirty(-1);

            if (private_dirty) {
                serverLog(LL_NOTICE,
                    "RDB: %zu MB of memory used by copy-on-write",
                    private_dirty/(1024*1024));
            }

            server.child_info_data.cow_size = private_dirty;
            sendChildInfo(CHILD_INFO_TYPE_RDB);
        }
        exitFromChild((retval == C_OK) ? 0 : 1);
    } else {
    /* Parent */
        server.stat_fork_time = ustime()-start;
        server.stat_fork_rate = (double) zmalloc_used_memory() * 1000000 / server.stat_fork_time / (1024*1024*1024); /* GB per second. */
        latencyAddSampleIfNeeded("fork",server.stat_fork_time/1000);
        if (childpid == -1) {
            closeChildInfoPipe();
            server.lastbgsave_status = C_ERR;
            serverLog(LL_WARNING,"Can't save in background: fork: %s",
                strerror(errno));
            return C_ERR;
        }
    serverLog(LL_NOTICE,"Background saving started by pid %d",childpid);
        server.rdb_save_time_start = time(NULL);
        server.rdb_child_pid = childpid;
        server.rdb_child_type = RDB_CHILD_TYPE_DISK;
        updateDictResizePolicy();
        return C_OK;
    }
  return C_OK; /* unreached */

 

  • RDB文件之载入

和采用SAVE命令或者BGSAVE命令创建RDB文件不同,RDB文件之载入工作是当服务器启动时自动执行之,所以Redis并没专门用于载入RDB文件之命令,只要Redis服务器在起步时检测及RDB文件是,它就是见面自动载入RDB文件。

manbet手机客户端3.0 1

 

为AOF文件的创新频率通常比RDB文件之换代频率高,所以:

❑如果服务器被了AOF持久化功能,那么服务器会先利用AOF文件来回复数据库状态。

❑只有当AOF持久化功能处于倒闭状态时,服务器才会使RDB文件来还原数据库状态。

 

  • RDB执行时系统状态

  a)         SAVE命令执行时的服务器状态

  前面提到了,当SAVE命令执行时,Redis服务器会叫堵塞,所以当SAVE命令在履行时,客户端发送的装有命令请求都见面于拒。

除非在服务器执行完SAVE命令、重新开接受命令请求后,客户端发送的指令才会为处理。

  b)         BGSAVE命令执行时之服务器状态

  因为BGSAVE命令的保存工作是由子进程执行之,所以在子进程创造RDB文件的长河中,Redis服务器仍然可继续处理客户端的吩咐请求。

  1. 客户端发送的SAVE命令会被服务器拒绝
  2. 客户端发送的BGSAVE命令会让服务器拒绝
  3. BGREWRITEAOF和BGSAVE两单指令不能够而且实行
  4. RDB文件载入时的服务器状态

服务器在载入RDB文件中,会直接处于阻塞状态,直到载入工作到位为止。

 

  • 自动间隔性保存 

坐BGSAVE命令可以以无封堵服务器进程的场面下实行,所以Redis允许用户通过设置服务器配置的save选项,让服务器每隔一段时间自动执行同样差BGSAVE命令。用户可以由此save选项设置多只保存条件,但万一其中擅自一个规范让满足,服务器即会执行BGSAVE命令。saveparams属性是一个频繁组,数组中的每个元素还是一个saveparam结构,每个saveparam结构还保存了一个save选项设置的保留条件:

 manbet手机客户端3.0 2

  除了saveparams数组之外,redisServer服务器状态还保持在一个dirty计数器,以及一个lastsave属性:

  1. dirty计数器记录距离达到一致不成中标施行SAVE命令或者BGSAVE命令后,服务器对数据库状态(服务器被之拥有数据库)进行了稍稍坏修改(包括写副、删除、更新等操作)。
  2. lastsave属性是一个UNIX时间戳,记录了服务器上等同赖成功实行SAVE命令或者BGSAVE命令的岁月。

  3. RDB文件结构

 

manbet手机客户端3.0 3

  1.每个非空数据库在RDB文件被还好保存也SELECTDB、db_number、key_value_pairs三单部分

 manbet手机客户端3.0 4

  2.RDB文书中之每个key_value_pairs部分还封存了一个或者上述数量的键值对,如果键值对含蓄过期时的话,那么键值对之超时时啊会见给封存在内。不带来过时之键值对在RDB文件被由于TYPE、key、value三有些组成,

manbet手机客户端3.0 5

  3.RDB文书被的每个value部分都保留了一个价值对象,每个值对象的项目且出于同的相应的TYPE记录,根据项目的不比,value部分的布局、长度为会见迥然不同

 

  • 分析RDB文件$ od -c

 

二、AOF

AOF持久化是透过保存Redis服务器所执的描摹命令来记录数据库状态的,被描写入AOF文件之所有命令还是以Redis的授命请求协议格式保存之,因为Redis的吩咐请求协议是彻头彻尾文本格式AOF文件通过保留有修改数据库的描绘命令请求来记录服务器的数据库状态。

  • AOF文件的描摹副与一头

AOF持久化功能处于打开状态时,服务器在实行完毕一个写命令下,会坐商格式将于实践之描写命令追加到服务器状态的aof_buf缓冲区之最终:

def eventLoop():  
  while True:  
    # 处理文件事件,接收命令请求以及发送命令回复  
    # 处理命令请求时可能会有新内容被追加到aof_buf缓冲区中  
    processFileEvents()  
    # 处理时间事件  
    processTimeEvents()  
    # 考虑是否要将aof_buf中的内容写入和保存到AOF文件里面  
    flushAppendOnlyFile()  
  • AOF文件的载入与数据恢复

  • 创建一个无牵动​网络连接的伪客户端(fake
    client):因为redis的授命只能在客户端上下文中执行,而载入AOF文件时所用的一声令下直接源于AOF文件要不是网络连接。

  • 自打AOF文件被分析并宣读来同长写命令。
  • 用伪客户端执行于读来的勾命令。
  • 直白实行步骤2和手续3,直到AOF文件中之有写命令还受处理完毕为止。

manbet手机客户端3.0 6

  • AOF重写

为化解AOF文件体积膨胀问题,redis提出了AOF文件再度写功能,通过该意义,redis服务器可以创建一个初的AOF文件来顶替现有的AOF文件。AOF文件重写并不需要对现有的AOF文件进行其它读取、分析或写入操作,这个力量是透过读取服务器时的数据库状态来兑现之。AOF重写功能的兑现原理:首先从数据库中读取键现在的价值,然后据此同样长长的命令去记录键值对,代替之前记录者键值对的大半漫长命令。

aof触发的机会:

         1)用户调用BGREWRITEAOF命令

         2)aof日志大小超过预设的限额

https://blog.csdn.net/chosen0ne/article/details/44461497

void bgrewriteaofCommand(client *c) {
    //如果当前正在进行aof rewrite,则返回客户端错误
    if (server.aof_child_pid != -1) {
        addReplyError(c,"Background append only file rewriting already in progress");
    } else if (server.rdb_child_pid != -1) {
    //如果当前正在进行rdb dump,为了避免对磁盘造成压力,将aof_rewrite_scheduled置为1,随后在没有进行aof rewrite和rdb dump时,再开启rewrite
        server.aof_rewrite_scheduled = 1;
        addReplyStatus(c,"Background append only file rewriting scheduled");
    } else if (rewriteAppendOnlyFileBackground() == C_OK) {
    //如果当前没有aof rewrite和rdb dump在进行,则调用rewriteAppendOnlyFileBackground进行aof rewrite
        addReplyStatus(c,"Background append only file rewriting started");
    } else {
    //异常情况,直接返回错误
        addReply(c,shared.err);
    }
}

  rewrite的横流程是:

  1.   创建子进程,获取当前快照,同时以随后的命令记录及aof_rewrite_buf中;
  2.   子进程遍历db生成aof 临时文件,然后退出;
  3.   父进程wait子进程,待了晚,将aof_rewrite_buf中的多寡多至该aof文件中;
  4.   最后重命名该临时文件为标准的aof文件。

    id_t childpid;
    long long start;

    //
    // 避免同时多个进程进行rewrite
    //

    if (server.aof_child_pid != -1) return REDIS_ERR;

    start = ustime();
    if ((childpid = fork()) == 0) {

    char tmpfile[256];  
    
    /* Child */  
    // <MM>  
    // 子进程不能接受连接  
    // </MM>  
    closeListeningSockets(0);  
    redisSetProcTitle("redis-aof-rewrite");  
    
    // <MM>  
    // 生成临时aof文件名  
    // </MM>  
    snprintf(tmpfile,256,"temp-rewriteaof-bg-%d.aof", (int) getpid());  
    if (rewriteAppendOnlyFile(tmpfile) == REDIS_OK) {  
        size_t private_dirty = zmalloc_get_private_dirty();  
    
        if (private_dirty) {  
            redisLog(REDIS_NOTICE,  
                "AOF rewrite: %zu MB of memory used by copy-on-write",  
                private_dirty/(1024*1024));  
        }  
        exitFromChild(0);  
    } else {  
        exitFromChild(1);  
    }  
    

笔录时时刻,用于统计fork耗时。然后调用fork,进入子进程的流水线。子进程首先关闭监听socket,避免接收客户端连接。同时安装过程的title。然后,生成rewirte要写副的临时文件名。接下来调用rewriteAppendOnlyFile进行rewrite。如果rewrite成功,统计copy-on-write的脏页并记下日志,然后为退出码0退出过程。如果rewrite失败,则退过程并赶回1当作退出码。

} else {  
    /* Parent */  
    server.stat_fork_time = ustime()-start;  
    server.stat_fork_rate = (double) zmalloc_used_memory() * 1000000 / server.stat_fork_time / (1024*1024*1024); /* GB per second. */  
    latencyAddSampleIfNeeded("fork",server.stat_fork_time/1000);  
    if (childpid == -1) {  
        redisLog(REDIS_WARNING,  
            "Can't rewrite append only file in background: fork: %s",  
            strerror(errno));  
        return REDIS_ERR;  
    }  
    redisLog(REDIS_NOTICE,  
        "Background append only file rewriting started by pid %d",childpid);  
    server.aof_rewrite_scheduled = 0;  
    server.aof_rewrite_time_start = time(NULL);  
    server.aof_child_pid = childpid;  
    updateDictResizePolicy();  
    /* We set appendseldb to -1 in order to force the next call to the 
     * feedAppendOnlyFile() to issue a SELECT command, so the differences 
     * accumulated by the parent into server.aof_rewrite_buf will start 
     * with a SELECT statement and it will be safe to merge. */  
    server.aof_selected_db = -1;  
    replicationScriptCacheFlush();  
    return REDIS_OK;  
}  

  父进程首先统计fork耗时并采样。如果fork失败,记录日志并回错误。如果fork成功,对aof_rewrite_scheduled清零,记录rewrite开始时和aof_child_pid(redis通过者特性判断是否发aof
rewrite在拓展)。调用updateDictResizePolicy调整db的key
space的rehash策略,由于创建了子进程,避免copy-on-write复制大量内存页,这里见面禁止dict的rehash。将aof_selected_db置为-1,目的是,下一条aof会首士人化作一长长的select
db的日志,同时会刻画及aof_rewrite_buf中,这样便可将aof_rewrite_buf正常的增多到rewrite之后的文书。

} else {  
    /* Parent */  
    server.stat_fork_time = ustime()-start;  
    server.stat_fork_rate = (double) zmalloc_used_memory() * 1000000 / server.stat_fork_time / (1024*1024*1024); /* GB per second. */  
    latencyAddSampleIfNeeded("fork",server.stat_fork_time/1000);  
    if (childpid == -1) {  
        redisLog(REDIS_WARNING,  
            "Can't rewrite append only file in background: fork: %s",  
            strerror(errno));  
        return REDIS_ERR;  
    }  
    redisLog(REDIS_NOTICE,  
        "Background append only file rewriting started by pid %d",childpid);  
    server.aof_rewrite_scheduled = 0;  
    server.aof_rewrite_time_start = time(NULL);  
    server.aof_child_pid = childpid;  
    updateDictResizePolicy();  
    /* We set appendseldb to -1 in order to force the next call to the 
     * feedAppendOnlyFile() to issue a SELECT command, so the differences 
     * accumulated by the parent into server.aof_rewrite_buf will start 
     * with a SELECT statement and it will be safe to merge. */  
    server.aof_selected_db = -1;  
    replicationScriptCacheFlush();  
    return REDIS_OK;  
}  

支行进程展开aof
rewrite的过程,进入rewriteAppendOnlyFile函数。遍历所有key,进行序列化,然后记录到aof文件被:

dictIterator *di = NULL;  
dictEntry *de;  
rio aof;  
FILE *fp;  
char tmpfile[256];  
int j;  
long long now = mstime();  

/* Note that we have to use a different temp name here compared to the 
 * one used by rewriteAppendOnlyFileBackground() function. */  
snprintf(tmpfile,256,"temp-rewriteaof-%d.aof", (int) getpid());  
fp = fopen(tmpfile,"w");  
if (!fp) {  
    redisLog(REDIS_WARNING, "Opening the temp file for AOF rewrite in rewriteAppendOnlyFile(): %s", strerror(errno));  
    return REDIS_ERR;  
}  
//获取当前时间,生成临时文件名并创建该文件。
rioInitWithFile(&aof,fp);  
if (server.aof_rewrite_incremental_fsync)  
    rioSetAutoSync(&aof,REDIS_AOF_AUTOSYNC_BYTES);  
//循环,用于遍历redis的每个db,对其进行rewirte
char selectcmd[] = "*2\r\n$6\r\nSELECT\r\n";  
redisDb *db = server.db+j;  
dict *d = db->dict;  
if (dictSize(d) == 0) continue;  
di = dictGetSafeIterator(d);  
if (!di) {  
    fclose(fp);  
    return REDIS_ERR;  
}  

//首先,生成对应db的select命令,然后查看如果db为空的话,就跳过,rewrite下一个db。然后获取该db的迭代器,如果获取失败,直接返回错误。最后将select db的命令写入文件。  
if (rioWrite(&aof,selectcmd,sizeof(selectcmd)-1) == 0) goto werr;  
if (rioWriteBulkLongLong(&aof,j) == 0) goto werr;  
//循环,用于遍历db的每一个key
while ((de = dictNext(di)) != NULL) {  
    // ...  
}  
dictReleaseIterator(di);  

AOF Rewrite
Buffer追加到文件,将临时文件重命名为最终之aof文件。最后,更新状态,异步关闭前的aof文件。

 

(1)AOF后令还写提出的因

        
因为redis服务器是行使单线程来拍卖命令请求的,如果由服务器直接调用aof_rewrite函数的讲话,那么在重写AOF文件里,服务器将无法处理客户端发来之一声令下请求,所以,redis决定以AOF重写序在子进程里执行,这样就算得又上一定量个目的。             

  1. 一致凡是分支进程执行AOF重写期间,服务器进程(父进程)可以继承处理命令请求。
  2. 其次凡分支进程带有服务器进程的数码副本,使用子进程而未是线程,可以免采取锁之情下,保证数据的安全性。

(2)​AOF重写是的题材和解决方案

        
存在的题目:因为子进程在以展开AOF重写期间,服务器进程还需要连续处理命令请求,而新的指令可能会见指向现有的数据库状态进行修改,从而使得服务器时底数据库状态及重写后的AOF文件所保存之数据库状态不均等。

        
解决方式:redis服务器设置了一个AOF重写缓冲区,这个缓冲区在服务器创建子进程之后开动,当redis服务器执行完毕一个写命令后,它会同时以之写命令发送给AOF缓冲区和AOF重写缓冲区。

(3)子进程执行AOF重写期间,服务器进程需要做的作业:​

  1. 实践客户端发来的一声令下。
  2. 将实行后的刻画命令追加至AOF缓冲区。
  3. 拿履行后的勾勒命令追加至AOF重写缓冲区。

 

 

总结:

❑RDB文件用于保存及还原Redis服务器所有数据库被的有所键值对数据。

❑SAVE命令由服务器进程一直实施保存操作,所以该命令会阻塞服务器。

❑BGSAVE令由子进程执行保存操作,所以该令不会见堵塞服务器。

❑服务器状态中见面保留有用save选项设置的保留条件,当任意一个保存条件被满足时,服务器会活动执行BGSAVE命令。

❑RDB文件是一个通过压缩的二进制文件,由多个组成部分组成。

❑对于不同类别的键值对,RDB文件会用不同之方法来保存其。

 

❑AOF文件通过保留有修改数据库的写命令请求来记录服务器的数据库状态。

❑AOF文件中之持有命令还以Redis命令请求协议的格式保存。

❑命令请求会优先保存至AOF缓冲区里面,之后再度定期写入并伙同到AOF文件。

appendfsync选项的不比值对AOF持久化功能的安全性与Redis服务器的性质有异常要命之震慑。

❑服务器如果载入并更履行保存在AOF文件中之一声令下,就足以恢复数据库本来的状态。

❑AOF重写好起一个新的AOF文件,这个新的AOF文件与原有的AOF文件所保存之数据库状态一样,但体积更小。

❑AOF重写是一个出歧义的名字,该功能是透过读取数据库中之键值对落实的,程序无须对现有的AOF文件进行其它读入、分析或写入操作。

于推行BGREWRITEAOF命令时,Redis服务器会维护一个AOF重写缓冲区,该缓冲区会于分层进程创造新AOF文件里,记录服务器执行的装有命令。当子进程就创建新AOF文件的行事以后,服务器会将还写缓冲区中的保有内容充实到新AOF文件之尾声,使得新老片单AOF文件所保存之数据库状态一样。最后,服务器用新的AOF文件替换原有的AOF文件,以这来就AOF文件的重写操作。

 

留下评论

网站地图xml地图