| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This feature is useful, especially in deployments using Sentinel in
order to setup Redis HA, where the slave is executed with NAT or port
forwarding, so that the auto-detected port/ip addresses, as listed in
the "INFO replication" output of the master, or as provided by the
"ROLE" command, don't match the real addresses at which the slave is
reachable for connections.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An exposed Redis instance on the internet can be cause of serious
issues. Since Redis, by default, binds to all the interfaces, it is easy
to forget an instance without any protection layer, for error.
Protected mode try to address this feature in a soft way, providing a
layer of protection, but giving clues to Redis users about why the
server is not accepting connections.
When protected mode is enabeld (the default), and if there are no
minumum hints about the fact the server is properly configured (no
"bind" directive is used in order to restrict the server to certain
interfaces, nor a password is set), clients connecting from external
intefaces are refused with an error explaining what to do in order to
fix the issue.
Clients connecting from the IPv4 and IPv6 lookback interfaces are still
accepted normally, similarly Unix domain socket connections are not
restricted in any way.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| | |
Just so it's extra official :smile:
|
| |/
|
|
| |
An user changed the behavior via a PR without upgrading the doc.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's hard to pick a good approach here. A few arguments:
1) There are many exposed instances on the internet.
2) Changing the default when "bind" is not given is very dangerous,
after an upgrade the server changes a fundamental behavior.
3) Usually Redis, when used in a proper way, will be protected *and*
accessed often from other computers, so this new default is likely
not what most people want.
4) However if users end with this default, they are using the example
redis.conf: likely they are reading what is inside, and they'll see
the warning.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Adds configuration option 'supervised [no | upstart | systemd | auto]'
Also removed 'bzero' from the previous implementation because it's 2015.
(We could actually statically initialize those structs, but clang
throws an invalid warning when we try, so it looks bad even though it
isn't bad.)
Fixes #2264
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This removes:
- list-max-ziplist-entries
- list-max-ziplist-value
This adds:
- list-max-ziplist-size
- list-compress-depth
Also updates config file with new sections and updates
tests to use quicklist settings instead of old list settings.
|
| |\
| |
| | |
Typo fixes in redis.conf
|
| | |
| |
| |
| |
| |
| | |
Fix two typos in redis.conf:
- "trnasfers" --> "transfers"
- "enalbed" --> "enabled"
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
:smile:
Closes #2034
|
| |
|
|
|
|
|
|
|
|
| |
- Remove trailing newlines from redis.conf
- Fix comment misspelling
- Clarifies zipEncodeLength usage and a C API mention (#1243, #1242)
- Fix cluster typos (inspired by @papanikge #1507)
- Fix rewite -> rewrite in a few places (inspired by #682)
Closes #1243, #1242, #1507
|
| |
|
|
| |
Closes #1441
|
| |
|
|
| |
Closes #1713
|
| |
|
|
| |
Closes #1897
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
According to unix manuals, "Connecting to the socket object requires
read/write permission." -- mode 755 is useless for anybody
other than the owner.
Fixes #1696
|
| | |
|
| | |
|
| |
|
|
| |
This commit adds both support for redis.conf and CONFIG SET/GET.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of output buffer limits Redis internals had this idea of type of
clients: normal, pubsub, slave. It is possible to set different output
buffer limits for the three kinds of clients.
However all the macros and API were named after output buffer limit
classes, while the idea of a client type is a generic one that can be
reused.
This commit does two things:
1) Rename the API and defines with more general names.
2) Change the class of clients executing the MONITOR command from "slave"
to "normal".
"2" is a good idea because you want to have very special settings for
slaves, that are not a good idea for MONITOR clients that are instead
normal clients even if they are conceptually slave-alike (since it is a
push protocol).
The backward-compatibility breakage resulting from "2" is considered to
be minimal to care, since MONITOR is a debugging command, and because
anyway this change is not going to break the format or the behavior, but
just when a connection is closed on big output buffer issues.
|
| |
|
|
| |
Check the commit changes in the example redis.conf for more information.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is safer as by default maxmemory should just set a memory limit
without any key to be deleted, unless the policy is set to something
more relaxed.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is especially important since we already have a concept of backlog
(the replication backlog).
|
| |
|
|
|
|
| |
In high RPS environments, the default listen backlog is not sufficient, so
giving users the power to configure it is the right approach, especially
since it requires only minor modifications to the code.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It is possible to configure the min number of additional working slaves
a master should be left with, for a slave to migrate to an orphaned
master.
|
| | |
|
| |
|
|
|
|
| |
Those options will be thrown without this patch:
include, rename-command, min-slaves-to-write, min-slaves-max-lag,
appendfilename.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
