Redis "--protected-mode no"ディスク上の永続データではありません

Question

Redhatサーバーにredisをインストールしました。私は、コマンド

以下

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

と私は私のRedisサーバを再起動すると、その後のRedisに格納するすべてのデータが削除されるとRedisのサーバーを実行すると。しかし、正常なredis serverコマンドを実行して起動すると正常に動作します。

$ ./redis-server 

私はRedisの設定ががappendonly yesを持っていますが、私はプロテクトモードで、なぜその永続的ではなく、そのデータを知っていないファイルをチェックしています。 保護モードを使用し、データをディスクに保存する方法はありませんか？

私は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構成（つまりsave）が設定されていないように見えます。私は自由を取って、この効果のためにリポジトリに問題を開いた：https://github.com/antirez/redis/issues/4567