MyException - 我的异常网
当前位置:我的异常网» 数据库 » redis 配置文件 append only file(aof)一部分-数据

redis 配置文件 append only file(aof)一部分-数据持久化

www.myexceptions.net  网友分享于:2015-08-26  浏览:25次
redis 配置文件 append only file(aof)部分---数据持久化

上一篇翻译之后,发觉通过翻译虽然比较吃力(不熟悉,多练习应该可以更熟练),但是能够较好的帮助理解redis的功能,遂继续翻译了aof部分,如下

原文:

############################## APPEND ONLY MODE ###############################

# 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.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")
# appendfilename appendonly.aof

# The fsync() call tells the Operating System to actually write data on disk
# instead to wait 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.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync always

# appendfsync no

# 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.
no-appendfsync-on-rewrite no


# 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.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

译文:

############################## 仅追加方式 ###############################

#默认情况下Redis会异步的将数据导出到磁盘上。这种模式对许多应用程序已经足够了,
#但是如果断电或者redis进程出问题就会导致一段时间内的更新数据丢失(取决与配置项)
#
#这种只增文件是可选的能够提供更好的体验的数据持久化策略。
#举个例子,如果使用默认的配置数据fsync策略,在服务器意外断电的情况下redis只会丢失一秒中内的更新数据,
#或者当redis进程出问题但操作系统运转正常时,redis只会丢失一个数据更新操作。
#
#AOF 和 RDB 持久化方式可以同时启动并且无冲突。
#如果AOF开启,启动redis时会加载aof文件,这些文件能够提供更好的保证。
#请在 http://redis.io/topics/persistence 获取更多数据持久化信息。

appendonly no

# 只增文件的文件名称。(默认是appendonly.aof)
# appendfilename appendonly.aof

#调用fsync()函数会通知操作系统真正将数据写入磁盘,而不是等待缓冲区中有更多数据。
#有些操作系统会将数据输出到磁盘,有些操作系统只是ASAP。
#
#redis支持三种不同的方式:
#
#no:不调用,之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。
# always: 每次更新数据都写入仅增日志文件。慢,但是最安全。
# everysec: 每秒调用一次。折中。
#
#默认是每秒中一次,因为它往往是在速度和数据安全两者之间的折中选择。
#如果你可以接受让操作系统去自动清空缓存,你可以将这项配置降低到'no'(如果你可以接受一段时间的数据丢失,默认的rdb就足够了),
#这完全取决与你。如果你想要一个更好的体验或者从相反的角度,使用'always',这样会很慢,但是比'everysec'安全些。
#
#请在下面的文章中获取更多细节知识:
#  http://antirez.com/post/redis-persistence-demystified.html
#
#如果你不是很清楚这三项之间的区别,或者不知道哪种适合你的机器,就是用默认吧。

# appendfsync always
appendfsync always
# appendfsync no

#当AOF策略设置为'always'或者'everysec'的时候,后台的保存进程会进行很多磁盘I/O操作,
#在某些linux结构中redis会在调用sync()方法时阻塞很长时间。记住,现在还没办法解决这个问题,即使在不同进程中进行调用也会block。
#
#使用如下配置可能会缓解这个问题,这样会在存储大数据或者BIGREWRITEAOF的时候不会在主进程中调用fsync()方法。
#
# 这表示,如果另外一个子进程在进行保存操作,redis的表现如同配置为‘appendfsync no’。
#在实际应用中,这表示在最坏的情景下(使用linux默认配置)可能会丢失30秒日志。
# 
#如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no


#自动重写只增文件。
#redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件,如果日志文件增长了指定的百分比。
# 
#它是这样工作的:每次rewrite后redis会记录日志文件的大小。(如果重启后没有重写后的大小,就默认用日志文件大小)
#
# 这个基准日志大小和当前日志大小做比较。如果当前大小比指定的百分比,重写机制就会被触发。
#同时,你也要制定一个重写下线,用来避免增长百分比够了,但是日志文件还很小的情况。
#
#指定百分比为0可以注掉自动重写日志文件功能。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb



文章评论

Java 与 .NET 的平台发展之争
Java 与 .NET 的平台发展之争
 程序员的样子
程序员的样子
程序员都该阅读的书
程序员都该阅读的书
做程序猿的老婆应该注意的一些事情
做程序猿的老婆应该注意的一些事情
科技史上最臭名昭著的13大罪犯
科技史上最臭名昭著的13大罪犯
编程语言是女人
编程语言是女人
旅行,写作,编程
旅行,写作,编程
鲜为人知的编程真相
鲜为人知的编程真相
那些争议最大的编程观点
那些争议最大的编程观点
“肮脏的”IT工作排行榜
“肮脏的”IT工作排行榜
Google伦敦新总部 犹如星级庄园
Google伦敦新总部 犹如星级庄园
漫画:程序员的工作
漫画:程序员的工作
中美印日四国程序员比较
中美印日四国程序员比较
一个程序员的时间管理
一个程序员的时间管理
2013年美国开发者薪资调查报告
2013年美国开发者薪资调查报告
如何成为一名黑客
如何成为一名黑客
代码女神横空出世
代码女神横空出世
我跳槽是因为他们的显示器更大
我跳槽是因为他们的显示器更大
Web开发人员为什么越来越懒了?
Web开发人员为什么越来越懒了?
10个帮程序员减压放松的网站
10个帮程序员减压放松的网站
程序员应该关注的一些事儿
程序员应该关注的一些事儿
什么才是优秀的用户界面设计
什么才是优秀的用户界面设计
当下全球最炙手可热的八位少年创业者
当下全球最炙手可热的八位少年创业者
聊聊HTTPS和SSL/TLS协议
聊聊HTTPS和SSL/TLS协议
要嫁就嫁程序猿—钱多话少死的早
要嫁就嫁程序猿—钱多话少死的早
那些性感的让人尖叫的程序员
那些性感的让人尖叫的程序员
老美怎么看待阿里赴美上市
老美怎么看待阿里赴美上市
写给自己也写给你 自己到底该何去何从
写给自己也写给你 自己到底该何去何从
2013年中国软件开发者薪资调查报告
2013年中国软件开发者薪资调查报告
总结2014中国互联网十大段子
总结2014中国互联网十大段子
十大编程算法助程序员走上高手之路
十大编程算法助程序员走上高手之路
为啥Android手机总会越用越慢?
为啥Android手机总会越用越慢?
60个开发者不容错过的免费资源库
60个开发者不容错过的免费资源库
程序员最害怕的5件事 你中招了吗?
程序员最害怕的5件事 你中招了吗?
我是如何打败拖延症的
我是如何打败拖延症的
10个调试和排错的小建议
10个调试和排错的小建议
程序员的一天:一寸光阴一寸金
程序员的一天:一寸光阴一寸金
每天工作4小时的程序员
每天工作4小时的程序员
老程序员的下场
老程序员的下场
我的丈夫是个程序员
我的丈夫是个程序员
5款最佳正则表达式编辑调试器
5款最佳正则表达式编辑调试器
团队中“技术大拿”并非越多越好
团队中“技术大拿”并非越多越好
程序员周末都喜欢做什么?
程序员周末都喜欢做什么?
亲爱的项目经理,我恨你
亲爱的项目经理,我恨你
初级 vs 高级开发者 哪个性价比更高?
初级 vs 高级开发者 哪个性价比更高?
Java程序员必看电影
Java程序员必看电影
“懒”出效率是程序员的美德
“懒”出效率是程序员的美德
程序员眼里IE浏览器是什么样的
程序员眼里IE浏览器是什么样的
如何区分一个程序员是“老手“还是“新手“?
如何区分一个程序员是“老手“还是“新手“?
软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有