redis.conf new features the new option, a minor typo preventing the compilation fixed

This commit is contained in:
antirez 2010-05-28 10:48:04 +02:00
parent b0bd87f60c
commit d5d23dabd7
2 changed files with 21 additions and 1 deletions

View File

@ -1386,7 +1386,7 @@ void backgroundRewriteDoneHandler(int statloc) {
/* If append only is actually enabled... */
close(server.appendfd);
server.appendfd = fd;
if (appendfsync != APPENDFSYNC_NO) aof_fsync(fd);
if (server.appendfsync != APPENDFSYNC_NO) aof_fsync(fd);
server.appendseldb = -1; /* Make sure it will issue SELECT */
redisLog(REDIS_NOTICE,"The new append only file was selected for future appends.");
} else {

View File

@ -195,6 +195,26 @@ appendonly no
appendfsync everysec
# 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", that in pratical terms means that it is
# possible to lost 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
################################ VIRTUAL MEMORY ###############################
# Virtual Memory allows Redis to work with datasets bigger than the actual