2013-04-04 08:30:05 -04:00
|
|
|
# Redis configuration for testing.
|
2010-05-14 11:31:11 -04:00
|
|
|
|
2016-12-19 10:49:58 -05:00
|
|
|
always-show-logo yes
|
2013-01-25 11:34:52 -05:00
|
|
|
notify-keyspace-events KEA
|
2010-05-14 11:31:11 -04:00
|
|
|
daemonize no
|
2011-01-09 10:49:52 -05:00
|
|
|
pidfile /var/run/redis.pid
|
2010-05-14 11:31:11 -04:00
|
|
|
port 6379
|
2013-02-05 06:02:36 -05:00
|
|
|
timeout 0
|
2012-12-10 12:21:10 -05:00
|
|
|
bind 127.0.0.1
|
2010-05-14 11:31:11 -04:00
|
|
|
loglevel verbose
|
2013-05-15 04:14:36 -04:00
|
|
|
logfile ''
|
2010-05-14 11:31:11 -04:00
|
|
|
databases 16
|
2014-07-10 09:04:34 -04:00
|
|
|
latency-monitor-threshold 1
|
Set repl-diskless-sync to yes by default, add repl-diskless-sync-max-replicas (#10092)
1. enable diskless replication by default
2. add a new config named repl-diskless-sync-max-replicas that enables
replication to start before the full repl-diskless-sync-delay was
reached.
3. put replica online sooner on the master (see below)
4. test suite uses repl-diskless-sync-delay of 0 to be faster
5. a few tests that use multiple replica on a pre-populated master, are
now using the new repl-diskless-sync-max-replicas
6. fix possible timing issues in a few cluster tests (see below)
put replica online sooner on the master
----------------------------------------------------
there were two tests that failed because they needed for the master to
realize that the replica is online, but the test code was actually only
waiting for the replica to realize it's online, and in diskless it could
have been before the master realized it.
changes include two things:
1. the tests wait on the right thing
2. issues in the master, putting the replica online in two steps.
the master used to put the replica as online in 2 steps. the first
step was to mark it as online, and the second step was to enable the
write event (only after getting ACK), but in fact the first step didn't
contains some of the tasks to put it online (like updating good slave
count, and sending the module event). this meant that if a test was
waiting to see that the replica is online form the point of view of the
master, and then confirm that the module got an event, or that the
master has enough good replicas, it could fail due to timing issues.
so now the full effect of putting the replica online, happens at once,
and only the part about enabling the writes is delayed till the ACK.
fix cluster tests
--------------------
I added some code to wait for the replica to sync and avoid race
conditions.
later realized the sentinel and cluster tests where using the original 5
seconds delay, so changed it to 0.
this means the other changes are probably not needed, but i suppose
they're still better (avoid race conditions)
2022-01-17 07:11:11 -05:00
|
|
|
repl-diskless-sync-delay 0
|
2010-05-14 11:31:11 -04:00
|
|
|
|
2022-05-09 06:37:49 -04:00
|
|
|
# Note the infrastructure in server.tcl uses a dict, we can't provide several save directives
|
2010-05-14 11:31:11 -04:00
|
|
|
save 900 1
|
|
|
|
|
|
|
|
|
|
rdbcompression yes
|
|
|
|
|
dbfilename dump.rdb
|
2011-01-09 10:49:52 -05:00
|
|
|
dir ./
|
2010-05-14 11:31:11 -04:00
|
|
|
|
2011-01-09 10:49:52 -05:00
|
|
|
slave-serve-stale-data yes
|
2010-05-14 11:31:11 -04:00
|
|
|
appendonly no
|
|
|
|
|
appendfsync everysec
|
2011-01-09 10:49:52 -05:00
|
|
|
no-appendfsync-on-rewrite no
|
2010-05-14 11:31:11 -04:00
|
|
|
activerehashing yes
|
Protected configs and sensitive commands (#9920)
Block sensitive configs and commands by default.
* `enable-protected-configs` - block modification of configs with the new `PROTECTED_CONFIG` flag.
Currently we add this flag to `dbfilename`, and `dir` configs,
all of which are non-mutable configs that can set a file redis will write to.
* `enable-debug-command` - block the `DEBUG` command
* `enable-module-command` - block the `MODULE` command
These have a default value set to `no`, so that these features are not
exposed by default to client connections, and can only be set by modifying the config file.
Users can change each of these to either `yes` (allow all access), or `local` (allow access from
local TCP connections and unix domain connections)
Note that this is a **breaking change** (specifically the part about MODULE command being disabled by default).
I.e. we don't consider DEBUG command being blocked as an issue (people shouldn't have been using it),
and the few configs we protected are unlikely to have been set at runtime anyway.
On the other hand, it's likely to assume some users who use modules, load them from the config file anyway.
Note that's the whole point of this PR, for redis to be more secure by default and reduce the attack surface on
innocent users, so secure defaults will necessarily mean a breaking change.
2021-12-19 03:46:16 -05:00
|
|
|
|
|
|
|
|
enable-protected-configs yes
|
|
|
|
|
enable-debug-command yes
|
|
|
|
|
enable-module-command yes
|
Set replicas to panic on disk errors, and optionally panic on replication errors (#10504)
* Till now, replicas that were unable to persist, would still execute the commands
they got from the master, now they'll panic by default, and we add a new
`replica-ignore-disk-errors` config to change that.
* Till now, when a command failed on a replica or AOF-loading, it only logged a
warning and a stat, we add a new `propagation-error-behavior` config to allow
panicking in that state (may become the default one day)
Note that commands that fail on the replica can either indicate a bug that could
cause data inconsistency between the replica and the master, or they could be
in some cases (specifically in previous versions), a result of a command (e.g. EVAL)
that failed on the master, but still had to be propagated to fail on the replica as well.
2022-04-26 06:25:33 -04:00
|
|
|
|
|
|
|
|
propagation-error-behavior panic
|
