记录一次因为硬盘写满造成的redis无法连接

缘起:

今天早晨收到报警,服务不干活了,赶紧起来看问题。。。

为了尽快让服务可用,尝试重启服务,发现服务起不来,报错

redis connection failed!

看起来是redis挂了,但是发现redis的进程还在。进一步看服务的错误日志:

redis.clients.jedis.exceptions.JedisDataException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the d
ata set are disabled. Please check Redis logs for details about the error.

redis持久化失败,服务配置了redis rdb持久化方式,为啥失败呢?内存和硬盘看了下,果然硬盘满了。清理硬盘ok了。

redis持久化策略(RDB/AOF)

1、RDB快照(snapshots)

  缺省情况情况下,Redis把数据快照存放在磁盘上的二进制文件中,文件名为dump.rdb。你可以配置Redis的持久化策略,例如数据集中每N秒钟有超过M次更新,就将数据写入磁盘;或者你可以手工调用命令SAVEBGSAVE

记录一次因为硬盘写满造成的redis无法连接

数据保存的目录:

记录一次因为硬盘写满造成的redis无法连接

工作原理

  • Redis forks.
  • 子进程开始将数据写到临时RDB文件中。
  • 当子进程完成写RDB文件,用新文件替换老文件。
  • 这种方式可以使Redis使用copy-on-write技术。

写时复制(copy-on-write/COW)技术:

写入时复制(Copy-on-write)是一个被使用在程式设计领域的最佳化策略。其基础的观念是,如果有多个呼叫者(callers)同时要求相同资源,他们会共同取得相同的指标指向相同的资源,直到某个呼叫者(caller)尝试修改资源时,系统才会真正复制一个副本(private copy)给该呼叫者,以避免被修改的资源被直接察觉到,这过程对其他的呼叫只都是通透的(transparently)。此作法主要的优点是如果呼叫者并没有修改该资源,就不会有副本(private copy)被建立。

2、APPEND ONLY MODE(AOF)

快照模式并不十分健壮,当系统停止,或者无意中Redis被kill掉,最后写入Redis的数据就会丢失。这对某些应用也许不是大问题,但对于要求高可靠性的应用来说,Redis就不是一个合适的选择。
Append-only文件模式是另一种选择。
你可以在配置文件中打开AOF模式:

记录一次因为硬盘写满造成的redis无法连接

选项:

  1、appendfsync no

  当设置appendfsync为no的时候,Redis不会主动调用fsync去将AOF日志内容同步到磁盘,所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统,是每30秒进行一次fsync,将缓冲区中的数据写到磁盘上。

  2、appendfsync everysec

当设置appendfsync为everysec的时候,Redis会默认每隔一秒进行一次fsync调用,将缓冲区中的数据写到磁盘。但是当这一 次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略,再等一秒钟。也就是在两秒后再进行fsync,这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞,所以当前的写操作就会阻塞。

所以,结论就是:在绝大多数情况下,Redis会每隔一秒进行一次fsync。在最坏的情况下,两秒钟会进行一次fsync操作。

这一操作在大多数数据库系统中被称为group commit,就是组合多次写操作的数据,一次性将日志写到磁盘。

  3、appednfsync always

当设置appendfsync为always时,每一次写操作都会调用一次fsync,这时数据是最安全的,当然,由于每次都会执行fsync,所以其性能也会受到影响

   建议采用 appendfsync everysec(缺省方式)

  快照模式可以和AOF模式同时开启,互补影响

3、AOF重写

AOF文件是可识别的纯文本,它的内容就是一个个的Redis标准命令,
AOF日志也不是完全按客户端的请求来生成日志的,比如命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录,因为浮点数操作可能在不同的系统上会不同,所以为了避免同一份日志在不同的系统上生成不同的数据集,所以这里只将操作后的结果通过SET来记录。

每一条写命令都生成一条日志,AOF文件会很大。

AOF重写是重新生成一份AOF文件,新的AOF文件中一条记录的操作只会有一次,而不像一份老文件那样,可能记录了对同一个值的多次操作。其生成过程和RDB类似,也是fork一个进程,直接遍历数据,写入新的AOF临时文件。在写入新文件的过程中,所有的写操作日志还是会写到原来老的 AOF文件中,同时还会记录在内存缓冲区中。当重完操作完成后,会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件

命令:BGREWRITEAOF, 我们应该经常调用这个命令来来重写

数据恢复:

  • 如果只配置AOF,重启时加载AOF文件恢复数据;
  • 如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;
  • 如果只配置RBD,启动是讲加载dump文件恢复数据。

写数据的流程:

    1. 客户端向服务端发送写操作(数据在客户端的内存中)。
    2. 数据库服务端接收到写请求的数据(数据在服务端的内存中)。
    3. 服务端调用write这个系统调用,将数据往磁盘上写(数据在系统内存的缓冲区中)。
    4. 操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
    5. 磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。
上一篇:curl与wget区别


下一篇:Unix/Linux环境C编程入门教程(28) 日期时间那些事儿