redis配置数据持久化---APPEND ONLY MODE
Redis配置数据持久化---APPEND ONLY MODE
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的更多相关文章
- Redis之数据持久化RDB与AOF
Redis之数据持久化RDB与AOF https://www.cnblogs.com/zackku/p/10087701.html 大家都知道,Redis之所以性能好,读写快,是因为Redis是一个内 ...
- 进阶的Redis之数据持久化RDB与AOF
大家都知道,Redis之所以性能好,读写快,是因为Redis是一个内存数据库,它的操作都几乎基于内存.但是内存型数据库有一个很大的弊端,就是当数据库进程崩溃或系统重启的时候,如果内存数据不保存的话,里 ...
- redis的数据持久化方案
Redis的持久化方案有两种 1.Rdb方式:快照形式,定期将内存中的数据持久化到硬盘.是Redis默认的数据持久化的形式. Rdb:缺点是:数据还没有更新到磁盘上,突然断电,造成数据的不完整性. 在 ...
- redis的数据持久化策略
redis提供了两种不同的持久化方法来将数据存储到硬盘里面.一种方法叫快照,它可以将存在于某一时刻的所有数据都写入硬盘里面.另一种方法叫只追加文件(AOF),它会在执行写命令时,将被执行的写命令复制到 ...
- redis学习——数据持久化
一.概述 Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的,然而当Redis重启后,所有存储在内存中的数据将会丢失,在很多情况下是无法容忍这样的事情的.所以,我们需要将内存中的数据持久 ...
- redis学习 - 数据持久化
Redis提供了多种不同级别的持久化方式: RDB 持久化可以在指定的时间间隔内产生数据集的时间点快照(point-in-time snapshot) AOF持久化记录服务器执行的所有写操作命令,并在 ...
- redis的数据持久化存储
Redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到硬盘来保证持久化.Redis支持两种持久化方式: 一.snapshotting(快照)方式快照是默认的持久化方式. ...
- Docker:PostgreSQL-11配置数据持久化
卷的原理图: 主机中的本地目录作为Docker容器内的持久存储卷装载,以便在主机和Docker容器之间共享数据.如果主机希望访问或定期备份在Docker容器内运行的DB服务器写入文件夹的数据或数据库, ...
- Redis 4.x 安装及 发布/订阅实践和数据持久化设置
1.或者源码安装包 #wget http://download.redis.io/releases/redis-4.0.6.tar.gz 2.解压源码包 #tar -zxf redis-4.0.6.t ...
随机推荐
- [The 2019 Asia Yinchuan First Round Online Programming] D Take Your Seat
也许更好的阅读体验 \(\mathcal{Description}\) 原题链接 题目大意 该题目有两个问题 \(Task\ 1\),有\(n\)个人\(n\)个座位,每个人都有一个对应的座位,每个人 ...
- 题解-CSA Beta Round#1 Number Elimination
Problem CSA-Beta Round#3 题意概要:给定 \(n\) 个数组成的序列,定义一次操作: 在当前序列中选择两个数,将其中较小的数从序列中删除(若两个数相同,则删除在序列中更靠前的) ...
- 深度学习的激活函数 :sigmoid、tanh、ReLU 、Leaky Relu、RReLU、softsign 、softplus、GELU
深度学习的激活函数 :sigmoid.tanh.ReLU .Leaky Relu.RReLU.softsign .softplus.GELU 2019-05-06 17:56:43 wamg潇潇 阅 ...
- U盘安装Ubuntu14.04&配置远程win10远程连接
1.U盘安装Ubuntu:https://blog.csdn.net/baigoocn/article/details/26561473 2.win10远程访问Ubuntu系统:https://www ...
- Spring Boot整合Spring Session实战
传统java web应用session都是由应用服务器(如tomcat)保存在内存中,这对应但节点应用来说没问题:但对于应用集群来说会造成各节点之间的session无法共享,一个节点挂掉后,其他节点接 ...
- Java 之 字符缓冲流
一.字符缓冲输出流 java.io.BufferedWriter extends Writer BufferedWriter:字符缓冲输出流. 继承自父类的共性成员方法: void write(int ...
- phpstom激活
phpstom官网:https://www.jetbrains.com/phpstorm/download 激活方法:激活时选择License server 填入http://idea.imsxm.c ...
- orangepi设置vnc开机自启动
首先需要创建一个文件,执行以下命令,自动打开空白文件,在里面编辑内容即可 sudo gedit /etc/init.d/tightvncserver 把以下内容粘贴进去,然后点击保存即可. #!/bi ...
- mongodb副本集和分片存储理论整理
目录 理论概述 一.各种集群简述 二.原理 主从复制 Mongodb副本集 理论概述 一.各种集群简述 mongodb有三种集群搭建方式: 分片:sharding.指为处理大量数据,将数据分开存储,不 ...
- Python——getpass(密码不显示)
为了用户输入密码时,不被其他人员看到,可以使用getpass模块来将密码以不显示的形式来表达. import getpass pwd = getpass.getpass() #在PyCharm中,运行 ...