Redis配置数据持久化---APPEND ONLY MODE
2016年04月01日 19:05:11

阅读数:9918

Redis可以实现数据的持久化存储,即将数据保存到磁盘上。
Redis的持久化存储提供两种方式:RDB与AOF。RDB是默认配置。AOF需要手动开启。
现在Redis的配置中默认是关闭AOF模式的。
如果要开启AOF模式,修改Redis的配置文件redis.conf。

相关的配置项:

appendonly yes  #开启AOF模式 原文1
appendfilename "appendonly.aof" #保存数据的AOF文件名称 原文1 # appendfsync always
appendfsync everysec #fsync模式 原文2
# appendfsync no no-appendfsync-on-rewrite no #原文3 auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #原文4 aof-load-truncated yes #原文5

原文1:

By default Redis asynchronously dumps the dataset on disk. This mode is good enough in many applications, but an issue with the Redis process or a power outage may result into a few minutes of writes lost (depending on the configured save points).

The Append Only File is an alternative persistence mode that provides much better durability. For instance using the default data fsync policy (see later in the config file) Redis can lose just one second of writes in a dramatic event like a server power outage, or a single write if something wrong with the Redis process itself happens, but the operating system is still running correctly.

AOF and RDB persistence can be enabled at the same time without problems. If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.

译文1:
Redis默认采用异步的方式将数据存放到磁盘上,这个模式对大部份应用来说是足够好的,但是在Redis进程或电源发生故障的情况下,可能会造成小部份的数据丢失,这取决于配置的保存时间点。
Appendonly是一种能够提供非常好的持久化的模式,例如使用默认的Fsync方案,Redis能在发生服务器电源故障或操作系统仍然正常运行但Redis进程莫名挂掉的情况下,只丢失1秒的数据。
AOF与RDB模式可以同时启用,这并不冲突。如果AOF是可用的,那Redis启动时将自动加载AOF,这个文件能够提供更好的持久性保障。

原文2:

The fsync() call tells the Operating System to actually write data on
disk instead of waiting for more data in the output buffer. Some OS
will really flush data on disk, some other OS will just try to do it
ASAP.

Redis supports three different modes:

no: don’t fsync, just let the OS flush the data when it wants. Faster.
always: fsync after every write to the append only log. Slow, Safest.
everysec: fsync only one time every second. Compromise.

The default is “everysec”, as that’s usually the right compromise
between speed and data safety. It’s up to you to understand if you can
relax this to “no” that will let the operating system flush the output
buffer when it wants, for better performances (but if you can live with
the idea of some data loss consider the default persistence mode that’s
snapshotting), or on the contrary, use “always” that’s very slow but a
bit safer than everysec.

If unsure, use “everysec”.

译文2:
fsync()调用告诉操作系统将数据真实的写入磁盘而不是放到缓冲区中,一些操作系统会真实的执行请求,还有一些操作系统只会尽力的尝试。

Redis支持3种不同的模式:
no:不即时同步,由操作系统控制何时刷写到磁盘上,这种模式速度最快;
always:每次只写日志,速度较慢,但最安全;
everysec:每秒钟同步一次,折中的方案。

默认的模式是“everysec”,它通常是在速度和数据安全之间折中的方法。如果你可以控制操作系统在Redis需要的时候去刷写缓冲区那可以使用“no”模式,能够提供更好的性能(但如果你能接受一些数据丢失,可以考虑默认的持久化模式–快照方式),相反,使用“always”模式很慢,但是它比“everysec”模式要安全一点。

如果不确定,就使用“everysec”。

原文3:

When the AOF fsync policy is set to always or everysec, and a
background saving process (a background save or AOF log background
rewriting) is performing a lot of I/O against the disk, in some Linux
configurations Redis may block too long on the fsync() call. Note that
there is no fix for this currently, as even performing fsync in a
different thread will block our synchronous write(2) call.

In order to mitigate this problem it’s possible to use the following
option that will prevent fsync() from being called in the main process
while a BGSAVE or BGREWRITEAOF is in progress.

This means that while another child is saving, the durability of
Redis is the same as “appendfsync none”. In practical terms, this means
that it is possible to lose up to 30 seconds of log in the worst
scenario (with the default Linux settings).

If you have latency problems turn this to “yes”. Otherwise leave it
as “no” that is the safest pick from the point of view of durability.

译文3:
当使用AOF的fsync方案设置为“always”或“everysec”时,后台的存储进程会执行大量的磁盘I/O操作,在一些Linux架构中,Redis在fsync()调用时可能会阻塞很久。这个问题当前并没有修复,即使是在一个不同的线程执行fsync也将会阻塞我们的同步写调用。

为了缓解这个问题,可以使用以下选项,它将会在有一个BGSAVE或BGREWRITEAOF正在运行时,阻止主进程调用fsync()。

这意味着有另一个子进程在存储时,Redis的持久性等同于“appendfsync none”。在实践中,意味着在最坏的情况下它可能丢失多达30秒的日志(默认的Linux设置)。

如果你有潜在的问题需要更改它为“yes”。否则从持久性的观点来看“no”是最安全的选择。

原文4:

Automatic rewrite of the append only file.
Redis is able to automatically rewrite the log file implicitly calling
BGREWRITEAOF when the AOF log size grows by the specified percentage.

This is how it works: Redis remembers the size of the AOF file after
the latest rewrite (if no rewrite has happened since the restart, the
size of the AOF at startup is used).

This base size is compared to the current size. If the current size
is bigger than the specified percentage, the rewrite is triggered. Also
you need to specify a minimal size for the AOF file to be rewritten,
this is useful to avoid rewriting the AOF file even if the percentage
increase is reached but it is still pretty small.

Specify a percentage of zero in order to disable the automatic AOF rewrite feature.

译文4:
自动重写append only文件。
当AOF日志的大小根据指定的百分比增长时,Redis会暗中调用BGREWRITEAOF去自动重写日志文件。

工作原理:Redis记忆AOF文件最后一次重写的大小(如果重启后没有重写发生,AOF的大小在启动时会被使用)。

基本大小对比当前大小。如果当前大小比指定的百分比大,触发重写。并且你要为AOF文件指定一个最小的尺寸去重写,这对于避免重写AOF文件是有用的,即使达到了百分比增长率但它仍然是非常小的。

指定百分比为0以便禁用自动AOF重写。

原文5:

An AOF file may be found to be truncated at the end during the Redis
startup process, when the AOF data gets loaded back into memory.
This may happen when the system where Redis is running crashes,
especially when an ext4 filesystem is mounted without the data=ordered
option (however this can’t happen when Redis itself crashes or aborts
but the operating system still works correctly).

Redis can either exit with an error when this happens, or load as
much data as possible (the default now) and start if the AOF file is
found to be truncated at the end. The following option controls this
behavior.

If aof-load-truncated is set to yes, a truncated AOF file is loaded
and the Redis server starts emitting a log to inform the user of the
event. Otherwise if the option is set to no, the server aborts with an
error and refuses to start. When the option is set to no, the user
requires to fix the AOF file using the “redis-check-aof” utility before
to restart the server.

Note that if the AOF file will be found to be corrupted in the middle
the server will still exit with an error. This option only applies when
Redis will try to read more data from the AOF file but not enough bytes
will be found.

译文5:
可能发现一个AOF文件在Redis启动过程中被截断,当AOF数据被加载回内存时。
这可能发生在系统中Redis运行崩溃,尤其是挂载一个EXT4文件系统而没有使用“data=ordered”选项时(但是这不会发生在Redis自身崩溃或中断而操作系统仍然正常运行的时候)。

当有一个错误发生时Redis要么退出,要么加载尽可能多的数据(当前默认)启动,如果AOF文件最后发现被截断。以下选项控制这个行为。

如果aof-load-truncated被设置为“yes”,一个被截断的AOF文件将会被加载,Redis服务启动发出一个日志告知用户这个事件。如果这个选项设置为“no”,服务器中止一个错误并拒绝启动。当选项被设置为“no”,用户需要在重启服务之前使用“redis-check-aof”功能确定AOF文件。

需要注意的是如果AOF文件被发现是损坏的,那服务器仍然会以一个错误退出。这个选项仅适用于Redis希望读取更多的数据但是没有发现足够的字节时。

redis配置数据持久化---APPEND ONLY MODE的更多相关文章

  1. Redis之数据持久化RDB与AOF

    Redis之数据持久化RDB与AOF https://www.cnblogs.com/zackku/p/10087701.html 大家都知道,Redis之所以性能好,读写快,是因为Redis是一个内 ...

  2. 进阶的Redis之数据持久化RDB与AOF

    大家都知道,Redis之所以性能好,读写快,是因为Redis是一个内存数据库,它的操作都几乎基于内存.但是内存型数据库有一个很大的弊端,就是当数据库进程崩溃或系统重启的时候,如果内存数据不保存的话,里 ...

  3. redis的数据持久化方案

    Redis的持久化方案有两种 1.Rdb方式:快照形式,定期将内存中的数据持久化到硬盘.是Redis默认的数据持久化的形式. Rdb:缺点是:数据还没有更新到磁盘上,突然断电,造成数据的不完整性. 在 ...

  4. redis的数据持久化策略

    redis提供了两种不同的持久化方法来将数据存储到硬盘里面.一种方法叫快照,它可以将存在于某一时刻的所有数据都写入硬盘里面.另一种方法叫只追加文件(AOF),它会在执行写命令时,将被执行的写命令复制到 ...

  5. redis学习——数据持久化

    一.概述 Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的,然而当Redis重启后,所有存储在内存中的数据将会丢失,在很多情况下是无法容忍这样的事情的.所以,我们需要将内存中的数据持久 ...

  6. redis学习 - 数据持久化

    Redis提供了多种不同级别的持久化方式: RDB 持久化可以在指定的时间间隔内产生数据集的时间点快照(point-in-time snapshot) AOF持久化记录服务器执行的所有写操作命令,并在 ...

  7. redis的数据持久化存储

    Redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到硬盘来保证持久化.Redis支持两种持久化方式: 一.snapshotting(快照)方式快照是默认的持久化方式. ...

  8. Docker:PostgreSQL-11配置数据持久化

    卷的原理图: 主机中的本地目录作为Docker容器内的持久存储卷装载,以便在主机和Docker容器之间共享数据.如果主机希望访问或定期备份在Docker容器内运行的DB服务器写入文件夹的数据或数据库, ...

  9. Redis 4.x 安装及 发布/订阅实践和数据持久化设置

    1.或者源码安装包 #wget http://download.redis.io/releases/redis-4.0.6.tar.gz 2.解压源码包 #tar -zxf redis-4.0.6.t ...

随机推荐

  1. AtCoder Grand Contest 034

    A:如果C在D左侧,显然先让B到达终点再让A走即可,否则先判断一下A是否可以在某处超过B.也就是先判断一下起点与终点之间是否有连续的障碍,若有则无解:然后若C在D左侧输出Yes,否则判断B和D之间是否 ...

  2. Feign 客户端调用错误

    1.@RequestBody 必须要写在实现接口中 2.Feign 客户端调用的时候如果有参数的话,默认是发送post请求 3.服务接口中的请求参数必须要加上@RequestParam("r ...

  3. idea下spring boot jpa写原生sql的时候,报Cannot resolve table错误

    错误如图 打开View→Tool Windows→Persistence选项 在弹出的Persistence窗口的项目上右键,选择Generate Persistence Mapping→By Dat ...

  4. cmake用法及常用命令总结(全)

    CMakeLists.txt 的语法比较简单,由命令.注释和空格组成,其中命令是不区分大小写的.指令是大小写无关的,参数和变量是大小写相关的.但推荐全部使用大写指令.符号 # 后面的内容被认为是注释. ...

  5. Python基本数据类型及实例详解

    Python 中的变量不需要声明.每个变量在使用前都必须赋值,变量赋值以后该变量才会被创建. 在 Python 中,变量就是变量,它没有类型,我们所说的"类型"是变量所指的内存中对 ...

  6. 【转载】Asp.Net MVC网站提交富文本HTML标签内容抛出异常

    今天开发一个ASP.NET MVC网站时,有个页面使用到了FCKEditor富文本编辑器,通过Post方式提交内容时候抛出异常,仔细分析后得出应该是服务器阻止了带有HTML标签内容的提交操作,ASP. ...

  7. dvaJS Model之间的调用

    const Model: ModelType = { namespace: 'namesps', state: { data: {} }, effects: { *fetch({ payload, c ...

  8. React Native 开发豆瓣评分(一)环境搭建&配置模拟器

    详细可参考 官方文档,这里进记录一些重要过程. 安装环境 下载 Android Studio 选择 Custom 进行安装: Android SDK Android SDK Platform Perf ...

  9. Android NDK 学习之接受Java传入的字符串

    本博客主要是在Ubuntu 下开发,且默认你已经安装了Eclipse,Android SDK, Android NDK, CDT插件. 在Eclipse中添加配置NDK,路径如下Eclipse-> ...

  10. arm9的操作模式,寄存器,寻址方式

    工作模式 Arm有7种工作模式: 名称 简称 简介 User Usr 正常用户程序执行的模式(linux下用户程序就是在这一模式执行的.) FIQ Fiq 快速中断模式 IRQ Irq 普通中断模式 ...