Redis "--protected-mode no"디스크의 영구 데이터가 아닙니다.

Question

redhat 서버에 redis를 설치했습니다. 내가 명령

아래

$ ./redis-server --protected-mode no 

그리고 난 내 레디 스 서버를 다시 시작할 때 다음 레디 스에 저장 한 모든 데이터가 삭제와 레디 스 서버를 실행합니다. 하지만 정상적인 redis 서버 명령을 실행하면 정상적으로 작동합니다.

$ ./redis-server 

나는 레디 스 설정은 파일 확인이 자사의 appendonly yes 가지고 있지만 내가 아는하지 않는 이유 금지 모드와의 영속 데이터. 보호 모드를 사용하고 redis와 함께 디스크에 데이터를 저장할 수있는 방법이 있습니까?

redis 4.0.1 버전을 사용하고 있는데 스크린 샷을 확인할 수 있습니다. 보호 모드를 사용하지 않고 실행됩니다. 내가 요청 닫을 때 그 데이터가 디스크

에 저장하지만 보호 모드로 실행하면 hapeen

그 디스크에 데이터를 저장하지 것을 확인했다.

내가 변경 한 설정 파일의 일부를 첨부했습니다. 나는 이미 appendonly yes을 사용하고 있는데, 내가 뭘 잘못하고 있는지 모르겠다.

################################ SNAPSHOTTING ################################ 
# 
# Save the DB on disk: 
# 
# save <seconds> <changes> 
# 
# Will save the DB if both the given number of seconds and the given 
# number of write operations against the DB occurred. 
# 
# In the example below the behaviour will be to save: 
# after 900 sec (15 min) if at least 1 key changed 
# after 300 sec (5 min) if at least 10 keys changed 
# after 60 sec if at least 10000 keys changed 
# 
# Note: you can disable saving completely by commenting out all "save" lines. 
# 
# It is also possible to remove all the previously configured save 
# points by adding a save directive with a single empty string argument 
# like in the following example: 
# 
# save "" 

save 900 1 
save 300 10 
save 60 10000 
save 1 1 

# By default Redis will stop accepting writes if RDB snapshots are enabled 
# (at least one save point) and the latest background save failed. 
# This will make the user aware (in a hard way) that data is not persisting 
# on disk properly, otherwise chances are that no one will notice and some 
# disaster will happen. 
# 
# If the background saving process will start working again Redis will 
# automatically allow writes again. 
# 
# However if you have setup your proper monitoring of the Redis server 
# and persistence, you may want to disable this feature so that Redis will 
# continue to work as usual even if there are problems with disk, 
# permissions, and so forth. 
stop-writes-on-bgsave-error yes 

# Compress string objects using LZF when dump .rdb databases? 
# For default that's set to 'yes' as it's almost always a win. 
# If you want to save some CPU in the saving child set it to 'no' but 
# the dataset will likely be bigger if you have compressible values or keys. 
rdbcompression yes 

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file. 
# This makes the format more resistant to corruption but there is a performance 
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it 
# for maximum performances. 
# 
# RDB files created with checksum disabled have a checksum of zero that will 
# tell the loading code to skip the check. 
rdbchecksum yes 

# The filename where to dump the DB 
dbfilename dump.rdb 

# The working directory. 
# 
# The DB will be written inside this directory, with the filename specified 
# above using the 'dbfilename' configuration directive. 
# 
# The Append Only File will also be created inside this directory. 
# 
# Note that you must specify a directory here, not a file name. 
dir ./ 

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

# 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 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. 
# 
# More details please check the following article: 
# http://antirez.com/post/redis-persistence-demystified.html 
# 
# If unsure, use "everysec". 

# appendfsync always 
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". 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 

# 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. 
aof-load-truncated yes 

# When rewriting the AOF file, Redis is able to use an RDB preamble in the 
# AOF file for faster rewrites and recoveries. When this option is turned 
# on the rewritten AOF file is composed of two different stanzas: 
# 
# [RDB file][AOF tail] 
# 
# When loading Redis recognizes that the AOF file starts with the "REDIS" 
# string and loads the prefixed RDB file, and continues loading the AOF 
# tail. 
# 
# This is currently turned off by default in order to avoid the surprise 
# of a format change, but will at some point be used as the default. 
aof-use-rdb-preamble no 

Answer 1

참고 : conf의 파일이 redis-server 과정에 대한 인수로 제공 한 경우 conf의 파일의 내용은사용된다.

conf 파일이없는 Redis를 시작할 때 기본 구성이 사용됩니다. 지속성 측면에서 기본 구성은 AOF를 사용하지 않으며 RDB 파일의 스냅 샷 지정을위한 save 지정 문을 가지고 있습니다. protected-mode 구성 지시문은 지속성에 영향을주지 않으며 Redis v4를 사용하여 위 예제의 청구 된 효과를 재현 할 수 없습니다.

문제에 대한 추가 정보를 제공하고 최소한의 재현 가능한 예를 만드십시오.

편집 : 예제에서 여전히 conf 파일을 사용하고 있지 않으므로 ./redis-server /path/to/conf/file을 사용해야합니다.

제 말대로이 문제를 재현 할 수 있습니다. 분명히 문제가 될 것 같습니다. 실제로 명령 줄 구성 인수를 사용하여 서버를 호출 할 때 기본 RDB 구성 (예 :)이 설정되지 않은 것 같습니다. 나는 자유를 가져 와서이 효과를 위해 저장소에 문제를 열었다 : https://github.com/antirez/redis/issues/4567