diff options
author | Yi Zhao <yi.zhao@windriver.com> | 2024-10-10 09:58:45 +0800 |
---|---|---|
committer | Khem Raj <raj.khem@gmail.com> | 2024-10-10 12:53:49 -0700 |
commit | c25df5ad4976ffb196a13c8171db87432bf36f80 (patch) | |
tree | a1038daf50e6692f6106072749e3cd7c8ebdd7f5 /meta-oe/recipes-extended/redis/redis-7.2.6 | |
parent | f702405fe9c24f66e8bf38b8801cd7e87ddd2f55 (diff) | |
download | meta-openembedded-c25df5ad4976ffb196a13c8171db87432bf36f80.tar.gz |
redis: upgrade 7.2.5 -> 7.2.6
ChangeLog:
Security fixes
==============
* (CVE-2024-31449) Lua library commands may lead to stack overflow and
potential RCE.
* (CVE-2024-31227) Potential Denial-of-service due to malformed ACL
selectors.
* (CVE-2024-31228) Potential Denial-of-service due to unbounded pattern
matching.
Bug fixes
=========
* Fixed crashes in cluster mode (#13315)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Diffstat (limited to 'meta-oe/recipes-extended/redis/redis-7.2.6')
9 files changed, 1670 insertions, 0 deletions
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/0001-hiredis-use-default-CC-if-it-is-set.patch b/meta-oe/recipes-extended/redis/redis-7.2.6/0001-hiredis-use-default-CC-if-it-is-set.patch new file mode 100644 index 000000000..63bf40341 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/0001-hiredis-use-default-CC-if-it-is-set.patch | |||
@@ -0,0 +1,37 @@ | |||
1 | From af4fc632c03b2a68be4206b4896f27fc4bb865ae Mon Sep 17 00:00:00 2001 | ||
2 | From: Venture Research <tech@ventureresearch.com> | ||
3 | Date: Fri, 8 Feb 2013 17:39:52 -0600 | ||
4 | Subject: [PATCH] hiredis: use default CC if it is set | ||
5 | MIME-Version: 1.0 | ||
6 | Content-Type: text/plain; charset=UTF-8 | ||
7 | Content-Transfer-Encoding: 8bit | ||
8 | |||
9 | Instead of trying to automagically figure out CC, which breaks with OE | ||
10 | as CC has spaces in it, just skip it if one was already passed in. | ||
11 | |||
12 | Upstream-Status: Pending | ||
13 | |||
14 | Signed-off-by: Venture Research <tech@ventureresearch.com> | ||
15 | |||
16 | Update to work with 4.0.8 | ||
17 | Signed-off-by: Alistair Francis <alistair.francis@wdc.com> | ||
18 | |||
19 | Reworked for 6.0.4 | ||
20 | Signed-off-by: Andreas Müller <schnitzeltony@gmail.com> | ||
21 | --- | ||
22 | deps/hiredis/Makefile | 2 -- | ||
23 | 1 file changed, 2 deletions(-) | ||
24 | |||
25 | diff --git a/deps/hiredis/Makefile b/deps/hiredis/Makefile | ||
26 | index bd2106b..9ce768d 100644 | ||
27 | --- a/deps/hiredis/Makefile | ||
28 | +++ b/deps/hiredis/Makefile | ||
29 | @@ -36,8 +36,6 @@ endef | ||
30 | export REDIS_TEST_CONFIG | ||
31 | |||
32 | # Fallback to gcc when $CC is not in $PATH. | ||
33 | -CC:=$(shell sh -c 'type $${CC%% *} >/dev/null 2>/dev/null && echo $(CC) || echo gcc') | ||
34 | -CXX:=$(shell sh -c 'type $${CXX%% *} >/dev/null 2>/dev/null && echo $(CXX) || echo g++') | ||
35 | OPTIMIZATION?=-O3 | ||
36 | WARNINGS=-Wall -Wextra -Werror -Wstrict-prototypes -Wwrite-strings -Wno-missing-field-initializers | ||
37 | DEBUG_FLAGS?= -g -ggdb | ||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/0002-lua-update-Makefile-to-use-environment-build-setting.patch b/meta-oe/recipes-extended/redis/redis-7.2.6/0002-lua-update-Makefile-to-use-environment-build-setting.patch new file mode 100644 index 000000000..46330f506 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/0002-lua-update-Makefile-to-use-environment-build-setting.patch | |||
@@ -0,0 +1,77 @@ | |||
1 | From 45ae5eb5c3482054073e06ab1a78e0aa9b96447f Mon Sep 17 00:00:00 2001 | ||
2 | From: Venture Research <tech@ventureresearch.com> | ||
3 | Date: Fri, 8 Feb 2013 20:22:19 -0600 | ||
4 | Subject: [PATCH] lua: update Makefile to use environment build settings | ||
5 | |||
6 | OE-specific parameters, instead of overriding all of these simply use | ||
7 | the ones that are already passed in. Also configure for only Linux... | ||
8 | |||
9 | Upstream-Status: Pending | ||
10 | |||
11 | Signed-off-by: Venture Research <tech@ventureresearch.com> | ||
12 | |||
13 | Updated to work with 3.0.x | ||
14 | |||
15 | Signed-off-by: Armin Kuster <akust808@gmail.com> | ||
16 | |||
17 | updated to work wtih 6.2.1 | ||
18 | Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com> | ||
19 | --- | ||
20 | deps/Makefile | 1 - | ||
21 | deps/lua/Makefile | 1 - | ||
22 | deps/lua/src/Makefile | 16 ++++++---------- | ||
23 | 3 files changed, 6 insertions(+), 12 deletions(-) | ||
24 | |||
25 | diff --git a/deps/Makefile b/deps/Makefile | ||
26 | index 3bf0363..fd8765a 100644 | ||
27 | --- a/deps/Makefile | ||
28 | +++ b/deps/Makefile | ||
29 | @@ -94,7 +94,6 @@ endif | ||
30 | # lua's Makefile defines AR="ar rcu", which is unusual, and makes it more | ||
31 | # challenging to cross-compile lua (and redis). These defines make it easier | ||
32 | # to fit redis into cross-compilation environments, which typically set AR. | ||
33 | -AR=ar | ||
34 | ARFLAGS=rc | ||
35 | |||
36 | lua: .make-prerequisites | ||
37 | diff --git a/deps/lua/Makefile b/deps/lua/Makefile | ||
38 | index 209a132..72f4b2b 100644 | ||
39 | --- a/deps/lua/Makefile | ||
40 | +++ b/deps/lua/Makefile | ||
41 | @@ -33,7 +33,6 @@ INSTALL_DATA= $(INSTALL) -m 0644 | ||
42 | |||
43 | # Utilities. | ||
44 | MKDIR= mkdir -p | ||
45 | -RANLIB= ranlib | ||
46 | |||
47 | # == END OF USER SETTINGS. NO NEED TO CHANGE ANYTHING BELOW THIS LINE ========= | ||
48 | |||
49 | diff --git a/deps/lua/src/Makefile b/deps/lua/src/Makefile | ||
50 | index f3bba2f..1555ec0 100644 | ||
51 | --- a/deps/lua/src/Makefile | ||
52 | +++ b/deps/lua/src/Makefile | ||
53 | @@ -5,18 +5,14 @@ | ||
54 | # == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT ======================= | ||
55 | |||
56 | # Your platform. See PLATS for possible values. | ||
57 | -PLAT= none | ||
58 | +PLAT= linux | ||
59 | |||
60 | -CC?= gcc | ||
61 | -CFLAGS= -O2 -Wall $(MYCFLAGS) | ||
62 | -AR= ar rcu | ||
63 | -RANLIB= ranlib | ||
64 | -RM= rm -f | ||
65 | -LIBS= -lm $(MYLIBS) | ||
66 | - | ||
67 | -MYCFLAGS= | ||
68 | +MYCFLAGS=-DLUA_USE_LINUX | ||
69 | MYLDFLAGS= | ||
70 | -MYLIBS= | ||
71 | +MYLIBS=-Wl,-E -ldl -lreadline -lhistory -lncurses | ||
72 | + | ||
73 | +CFLAGS += $(MYCFLAGS) | ||
74 | +LIBS += -lm $(MYLIBS) | ||
75 | |||
76 | # == END OF USER SETTINGS. NO NEED TO CHANGE ANYTHING BELOW THIS LINE ========= | ||
77 | |||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/0003-hack-to-force-use-of-libc-malloc.patch b/meta-oe/recipes-extended/redis/redis-7.2.6/0003-hack-to-force-use-of-libc-malloc.patch new file mode 100644 index 000000000..1f97f9783 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/0003-hack-to-force-use-of-libc-malloc.patch | |||
@@ -0,0 +1,35 @@ | |||
1 | From 7a98e3ac480413ce7db3a5edd5dc70458b921b29 Mon Sep 17 00:00:00 2001 | ||
2 | From: Venture Research <tech@ventureresearch.com> | ||
3 | Date: Wed, 6 Feb 2013 20:51:02 -0600 | ||
4 | Subject: [PATCH] hack to force use of libc malloc | ||
5 | |||
6 | Hack to force libc usage as it seems the option to pass it in has been | ||
7 | removed in favor of magic. | ||
8 | |||
9 | Note that this of course doesn't allow tcmalloc and jemalloc, however | ||
10 | jemalloc wasn't building correctly. | ||
11 | |||
12 | Upstream-Status: Pending | ||
13 | |||
14 | Signed-off-by: Venture Research <tech@ventureresearch.com> | ||
15 | |||
16 | Update to work with 4.0.8 | ||
17 | Signed-off-by: Alistair Francis <alistair.francis@wdc.com> | ||
18 | --- | ||
19 | src/Makefile | 3 ++- | ||
20 | 1 file changed, 2 insertions(+), 1 deletion(-) | ||
21 | |||
22 | diff --git a/src/Makefile b/src/Makefile | ||
23 | index ecbd275..39decee 100644 | ||
24 | --- a/src/Makefile | ||
25 | +++ b/src/Makefile | ||
26 | @@ -13,7 +13,8 @@ | ||
27 | # Just use 'make dep', but this is only needed by developers. | ||
28 | |||
29 | release_hdr := $(shell sh -c './mkreleasehdr.sh') | ||
30 | -uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not') | ||
31 | +# use fake uname option to force use of generic libc | ||
32 | +uname_S := "USE_LIBC_MALLOC" | ||
33 | uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not') | ||
34 | CLANG := $(findstring clang,$(shell sh -c '$(CC) --version | head -1')) | ||
35 | OPTIMIZATION?=-O3 | ||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/0004-src-Do-not-reset-FINAL_LIBS.patch b/meta-oe/recipes-extended/redis/redis-7.2.6/0004-src-Do-not-reset-FINAL_LIBS.patch new file mode 100644 index 000000000..974cf5169 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/0004-src-Do-not-reset-FINAL_LIBS.patch | |||
@@ -0,0 +1,30 @@ | |||
1 | From 50fc46a12f6cf97e7b927d3ea29eecc9ebdea34d Mon Sep 17 00:00:00 2001 | ||
2 | From: Khem Raj <raj.khem@gmail.com> | ||
3 | Date: Tue, 10 Sep 2019 20:04:26 -0700 | ||
4 | Subject: [PATCH] src: Do not reset FINAL_LIBS | ||
5 | |||
6 | This helps case where additional libraries are needed to be passed from | ||
7 | environment to get it going | ||
8 | |||
9 | e.g. -latomic is needed on clang/x86 to provide for 64bit atomics | ||
10 | |||
11 | Upstream-Status: Pending | ||
12 | |||
13 | Signed-off-by: Khem Raj <raj.khem@gmail.com> | ||
14 | --- | ||
15 | src/Makefile | 2 +- | ||
16 | 1 file changed, 1 insertion(+), 1 deletion(-) | ||
17 | |||
18 | diff --git a/src/Makefile b/src/Makefile | ||
19 | index 39decee..f5efe82 100644 | ||
20 | --- a/src/Makefile | ||
21 | +++ b/src/Makefile | ||
22 | @@ -119,7 +119,7 @@ endif | ||
23 | |||
24 | FINAL_CFLAGS=$(STD) $(WARN) $(OPT) $(DEBUG) $(CFLAGS) $(REDIS_CFLAGS) | ||
25 | FINAL_LDFLAGS=$(LDFLAGS) $(REDIS_LDFLAGS) $(DEBUG) | ||
26 | -FINAL_LIBS=-lm | ||
27 | +FINAL_LIBS+=-lm | ||
28 | DEBUG=-g -ggdb | ||
29 | |||
30 | # Linux ARM32 needs -latomic at linking time | ||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/0005-Define-_GNU_SOURCE-to-get-PTHREAD_MUTEX_INITIALIZER.patch b/meta-oe/recipes-extended/redis/redis-7.2.6/0005-Define-_GNU_SOURCE-to-get-PTHREAD_MUTEX_INITIALIZER.patch new file mode 100644 index 000000000..8e5f30993 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/0005-Define-_GNU_SOURCE-to-get-PTHREAD_MUTEX_INITIALIZER.patch | |||
@@ -0,0 +1,29 @@ | |||
1 | From acd832d76002a1916b3128ac05bc0296425aea6d Mon Sep 17 00:00:00 2001 | ||
2 | From: Khem Raj <raj.khem@gmail.com> | ||
3 | Date: Sat, 21 Dec 2019 12:09:51 -0800 | ||
4 | Subject: [PATCH] Define _GNU_SOURCE to get PTHREAD_MUTEX_INITIALIZER | ||
5 | |||
6 | Fixes | ||
7 | | zmalloc.c:87:37: error: 'PTHREAD_MUTEX_DEFAULT' undeclared here (not in a function) | ||
8 | | 87 | pthread_mutex_t used_memory_mutex = PTHREAD_MUTEX_INITIALIZER; | ||
9 | | | ^~~~~~~~~~~~~~~~~~~~~~~~~ | ||
10 | |||
11 | Upstream-Status: Pending | ||
12 | |||
13 | Signed-off-by: Khem Raj <raj.khem@gmail.com> | ||
14 | --- | ||
15 | src/zmalloc.c | 1 + | ||
16 | 1 file changed, 1 insertion(+) | ||
17 | |||
18 | diff --git a/src/zmalloc.c b/src/zmalloc.c | ||
19 | index bbfa386..93e07ff 100644 | ||
20 | --- a/src/zmalloc.c | ||
21 | +++ b/src/zmalloc.c | ||
22 | @@ -32,6 +32,7 @@ | ||
23 | #include "config.h" | ||
24 | #include "solarisfixes.h" | ||
25 | |||
26 | +#define _GNU_SOURCE | ||
27 | #include <stdio.h> | ||
28 | #include <stdlib.h> | ||
29 | #include <stdint.h> | ||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/0006-Define-correct-gregs-for-RISCV32.patch b/meta-oe/recipes-extended/redis/redis-7.2.6/0006-Define-correct-gregs-for-RISCV32.patch new file mode 100644 index 000000000..700904817 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/0006-Define-correct-gregs-for-RISCV32.patch | |||
@@ -0,0 +1,60 @@ | |||
1 | From dd3ecb07bbf80b986b8f2c656ea11d1346e212f6 Mon Sep 17 00:00:00 2001 | ||
2 | From: Khem Raj <raj.khem@gmail.com> | ||
3 | Date: Mon, 26 Oct 2020 21:32:22 -0700 | ||
4 | Subject: [PATCH] Define correct gregs for RISCV32 | ||
5 | |||
6 | Upstream-Status: Pending | ||
7 | |||
8 | Signed-off-by: Khem Raj <raj.khem@gmail.com> | ||
9 | |||
10 | Updated patch for 6.2.8 | ||
11 | Signed-off-by: Changqing Li <changqing.li@windriver.com> | ||
12 | --- | ||
13 | src/debug.c | 26 ++++++++++++++++++++++++-- | ||
14 | 1 file changed, 24 insertions(+), 2 deletions(-) | ||
15 | |||
16 | diff --git a/src/debug.c b/src/debug.c | ||
17 | index 684f692..2ee151f 100644 | ||
18 | --- a/src/debug.c | ||
19 | +++ b/src/debug.c | ||
20 | @@ -1215,7 +1215,9 @@ static void* getAndSetMcontextEip(ucontext_t *uc, void *eip) { | ||
21 | #endif | ||
22 | #elif defined(__linux__) | ||
23 | /* Linux */ | ||
24 | - #if defined(__i386__) || ((defined(__X86_64__) || defined(__x86_64__)) && defined(__ILP32__)) | ||
25 | + #if defined(__riscv) && __riscv_xlen == 32 | ||
26 | + return (void*) uc->uc_mcontext.__gregs[REG_PC]; | ||
27 | + #elif defined(__i386__) || ((defined(__X86_64__) || defined(__x86_64__)) && defined(__ILP32__)) | ||
28 | GET_SET_RETURN(uc->uc_mcontext.gregs[14], eip); | ||
29 | #elif defined(__X86_64__) || defined(__x86_64__) | ||
30 | GET_SET_RETURN(uc->uc_mcontext.gregs[16], eip); | ||
31 | @@ -1401,8 +1403,28 @@ void logRegisters(ucontext_t *uc) { | ||
32 | #endif | ||
33 | /* Linux */ | ||
34 | #elif defined(__linux__) | ||
35 | + /* Linux RISCV32 */ | ||
36 | + #if defined(__riscv) && __riscv_xlen == 32 | ||
37 | + serverLog(LL_WARNING, | ||
38 | + "\n" | ||
39 | + "RA:%08lx S0:%08lx S1:%08lx S2:%08lx\n" | ||
40 | + "SP:%08lx PC:%08lx A0:%08lx A1:%08lx\n" | ||
41 | + "A2 :%08lx A3:%08lx A4:%08lx", | ||
42 | + (unsigned long) uc->uc_mcontext.__gregs[REG_RA], | ||
43 | + (unsigned long) uc->uc_mcontext.__gregs[REG_S0], | ||
44 | + (unsigned long) uc->uc_mcontext.__gregs[REG_S1], | ||
45 | + (unsigned long) uc->uc_mcontext.__gregs[REG_S2], | ||
46 | + (unsigned long) uc->uc_mcontext.__gregs[REG_SP], | ||
47 | + (unsigned long) uc->uc_mcontext.__gregs[REG_PC], | ||
48 | + (unsigned long) uc->uc_mcontext.__gregs[REG_A0 + 0], | ||
49 | + (unsigned long) uc->uc_mcontext.__gregs[REG_A0 + 1], | ||
50 | + (unsigned long) uc->uc_mcontext.__gregs[REG_A0 + 2], | ||
51 | + (unsigned long) uc->uc_mcontext.__gregs[REG_A0 + 3], | ||
52 | + (unsigned long) uc->uc_mcontext.__gregs[REG_A0 + 4] | ||
53 | + ); | ||
54 | + logStackContent((void**)uc->uc_mcontext.__gregs[REG_SP]); | ||
55 | /* Linux x86 */ | ||
56 | - #if defined(__i386__) || ((defined(__X86_64__) || defined(__x86_64__)) && defined(__ILP32__)) | ||
57 | + #elif defined(__i386__) || ((defined(__X86_64__) || defined(__x86_64__)) && defined(__ILP32__)) | ||
58 | serverLog(LL_WARNING, | ||
59 | "\n" | ||
60 | "EAX:%08lx EBX:%08lx ECX:%08lx EDX:%08lx\n" | ||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/init-redis-server b/meta-oe/recipes-extended/redis/redis-7.2.6/init-redis-server new file mode 100644 index 000000000..c5f335f57 --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/init-redis-server | |||
@@ -0,0 +1,71 @@ | |||
1 | #!/bin/sh | ||
2 | # | ||
3 | ### BEGIN INIT INFO | ||
4 | # Provides: redis-server | ||
5 | # Required-Start: $network | ||
6 | # Required-Stop: $network | ||
7 | # Default-Start: S 2 3 4 5 | ||
8 | # Default-Stop: 0 1 6 | ||
9 | # Short-Description: Redis, a key-value store | ||
10 | # Description: Redis is an open source, advanced key-value store. | ||
11 | # http://redis.io | ||
12 | ### END INIT INFO | ||
13 | |||
14 | test -f /usr/bin/redis-server || exit 0 | ||
15 | |||
16 | ARGS="/etc/redis/redis.conf" | ||
17 | |||
18 | case "$1" in | ||
19 | start) | ||
20 | echo "Starting redis-server..." | ||
21 | start-stop-daemon --start --quiet --exec /usr/bin/redis-server -- $ARGS | ||
22 | ;; | ||
23 | stop) | ||
24 | echo "Stopping redis-server..." | ||
25 | start-stop-daemon --stop --quiet --exec /usr/bin/redis-server | ||
26 | ;; | ||
27 | restart) | ||
28 | echo "Stopping redis-server..." | ||
29 | start-stop-daemon --stop --quiet --exec /usr/bin/redis-server | ||
30 | |||
31 | # Since busybox implementation ignores --retry arguments repeatedly check | ||
32 | # if the process is still running and try another signal after a timeout, | ||
33 | # efectively simulating a stop with --retry=TERM/5/KILL/5 schedule. | ||
34 | waitAfterTerm=5000000 # us / 5000 ms / 5 s | ||
35 | waitAfterKill=5000000 # us / 5000 ms / 5 s | ||
36 | waitStep=100000 # us / 100 ms / 0.1 s | ||
37 | waited=0 | ||
38 | start-stop-daemon --stop --test --quiet --exec /usr/bin/redis-server | ||
39 | processOff=$? | ||
40 | while [ $processOff -eq 0 ] && [ $waited -le $waitAfterTerm ] ; do | ||
41 | usleep ${waitStep} | ||
42 | ((waited+=${waitStep})) | ||
43 | start-stop-daemon --stop --test --quiet --exec /usr/bin/redis-server | ||
44 | processOff=$? | ||
45 | done | ||
46 | if [ $processOff -eq 0 ] ; then | ||
47 | start-stop-daemon --stop --signal KILL --exec /usr/bin/redis-server | ||
48 | start-stop-daemon --stop --test --quiet --exec /usr/bin/redis-server | ||
49 | processOff=$? | ||
50 | fi | ||
51 | waited=0 | ||
52 | while [ $processOff -eq 0 ] && [ $waited -le $waitAfterKill ] ; do | ||
53 | usleep ${waitStep} | ||
54 | ((waited+=${waitStep})) | ||
55 | start-stop-daemon --stop --test --quiet --exec /usr/bin/redis-server | ||
56 | processOff=$? | ||
57 | done | ||
58 | # Here $processOff will indicate if waiting and retrying according to | ||
59 | # the schedule ended in a successfull stop or not. | ||
60 | |||
61 | echo "Starting redis-server..." | ||
62 | start-stop-daemon --start --quiet --exec /usr/bin/redis-server -- $ARGS | ||
63 | ;; | ||
64 | *) | ||
65 | echo "Usage: /etc/init.d/redis-server {start|stop|restart}" | ||
66 | exit 1 | ||
67 | ;; | ||
68 | esac | ||
69 | |||
70 | exit 0 | ||
71 | |||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/redis.conf b/meta-oe/recipes-extended/redis/redis-7.2.6/redis.conf new file mode 100644 index 000000000..75037d6dc --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/redis.conf | |||
@@ -0,0 +1,1314 @@ | |||
1 | # Redis configuration file example. | ||
2 | # | ||
3 | # Note that in order to read the configuration file, Redis must be | ||
4 | # started with the file path as first argument: | ||
5 | # | ||
6 | # ./redis-server /path/to/redis.conf | ||
7 | |||
8 | # Note on units: when memory size is needed, it is possible to specify | ||
9 | # it in the usual form of 1k 5GB 4M and so forth: | ||
10 | # | ||
11 | # 1k => 1000 bytes | ||
12 | # 1kb => 1024 bytes | ||
13 | # 1m => 1000000 bytes | ||
14 | # 1mb => 1024*1024 bytes | ||
15 | # 1g => 1000000000 bytes | ||
16 | # 1gb => 1024*1024*1024 bytes | ||
17 | # | ||
18 | # units are case insensitive so 1GB 1Gb 1gB are all the same. | ||
19 | |||
20 | ################################## INCLUDES ################################### | ||
21 | |||
22 | # Include one or more other config files here. This is useful if you | ||
23 | # have a standard template that goes to all Redis servers but also need | ||
24 | # to customize a few per-server settings. Include files can include | ||
25 | # other files, so use this wisely. | ||
26 | # | ||
27 | # Notice option "include" won't be rewritten by command "CONFIG REWRITE" | ||
28 | # from admin or Redis Sentinel. Since Redis always uses the last processed | ||
29 | # line as value of a configuration directive, you'd better put includes | ||
30 | # at the beginning of this file to avoid overwriting config change at runtime. | ||
31 | # | ||
32 | # If instead you are interested in using includes to override configuration | ||
33 | # options, it is better to use include as the last line. | ||
34 | # | ||
35 | # include /path/to/local.conf | ||
36 | # include /path/to/other.conf | ||
37 | |||
38 | ################################## MODULES ##################################### | ||
39 | |||
40 | # Load modules at startup. If the server is not able to load modules | ||
41 | # it will abort. It is possible to use multiple loadmodule directives. | ||
42 | # | ||
43 | # loadmodule /path/to/my_module.so | ||
44 | # loadmodule /path/to/other_module.so | ||
45 | |||
46 | ################################## NETWORK ##################################### | ||
47 | |||
48 | # By default, if no "bind" configuration directive is specified, Redis listens | ||
49 | # for connections from all the network interfaces available on the server. | ||
50 | # It is possible to listen to just one or multiple selected interfaces using | ||
51 | # the "bind" configuration directive, followed by one or more IP addresses. | ||
52 | # | ||
53 | # Examples: | ||
54 | # | ||
55 | # bind 192.168.1.100 10.0.0.1 | ||
56 | # bind 127.0.0.1 ::1 | ||
57 | # | ||
58 | # ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the | ||
59 | # internet, binding to all the interfaces is dangerous and will expose the | ||
60 | # instance to everybody on the internet. So by default we uncomment the | ||
61 | # following bind directive, that will force Redis to listen only into | ||
62 | # the IPv4 lookback interface address (this means Redis will be able to | ||
63 | # accept connections only from clients running into the same computer it | ||
64 | # is running). | ||
65 | # | ||
66 | # IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES | ||
67 | # JUST COMMENT THE FOLLOWING LINE. | ||
68 | # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
69 | bind 127.0.0.1 | ||
70 | |||
71 | # Protected mode is a layer of security protection, in order to avoid that | ||
72 | # Redis instances left open on the internet are accessed and exploited. | ||
73 | # | ||
74 | # When protected mode is on and if: | ||
75 | # | ||
76 | # 1) The server is not binding explicitly to a set of addresses using the | ||
77 | # "bind" directive. | ||
78 | # 2) No password is configured. | ||
79 | # | ||
80 | # The server only accepts connections from clients connecting from the | ||
81 | # IPv4 and IPv6 loopback addresses 127.0.0.1 and ::1, and from Unix domain | ||
82 | # sockets. | ||
83 | # | ||
84 | # By default protected mode is enabled. You should disable it only if | ||
85 | # you are sure you want clients from other hosts to connect to Redis | ||
86 | # even if no authentication is configured, nor a specific set of interfaces | ||
87 | # are explicitly listed using the "bind" directive. | ||
88 | protected-mode yes | ||
89 | |||
90 | # Accept connections on the specified port, default is 6379 (IANA #815344). | ||
91 | # If port 0 is specified Redis will not listen on a TCP socket. | ||
92 | port 6379 | ||
93 | |||
94 | # TCP listen() backlog. | ||
95 | # | ||
96 | # In high requests-per-second environments you need an high backlog in order | ||
97 | # to avoid slow clients connections issues. Note that the Linux kernel | ||
98 | # will silently truncate it to the value of /proc/sys/net/core/somaxconn so | ||
99 | # make sure to raise both the value of somaxconn and tcp_max_syn_backlog | ||
100 | # in order to get the desired effect. | ||
101 | tcp-backlog 511 | ||
102 | |||
103 | # Unix socket. | ||
104 | # | ||
105 | # Specify the path for the Unix socket that will be used to listen for | ||
106 | # incoming connections. There is no default, so Redis will not listen | ||
107 | # on a unix socket when not specified. | ||
108 | # | ||
109 | # unixsocket /tmp/redis.sock | ||
110 | # unixsocketperm 700 | ||
111 | |||
112 | # Close the connection after a client is idle for N seconds (0 to disable) | ||
113 | timeout 0 | ||
114 | |||
115 | # TCP keepalive. | ||
116 | # | ||
117 | # If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence | ||
118 | # of communication. This is useful for two reasons: | ||
119 | # | ||
120 | # 1) Detect dead peers. | ||
121 | # 2) Take the connection alive from the point of view of network | ||
122 | # equipment in the middle. | ||
123 | # | ||
124 | # On Linux, the specified value (in seconds) is the period used to send ACKs. | ||
125 | # Note that to close the connection the double of the time is needed. | ||
126 | # On other kernels the period depends on the kernel configuration. | ||
127 | # | ||
128 | # A reasonable value for this option is 300 seconds, which is the new | ||
129 | # Redis default starting with Redis 3.2.1. | ||
130 | tcp-keepalive 300 | ||
131 | |||
132 | ################################# GENERAL ##################################### | ||
133 | |||
134 | # OE: run as a daemon. | ||
135 | daemonize yes | ||
136 | |||
137 | # If you run Redis from upstart or systemd, Redis can interact with your | ||
138 | # supervision tree. Options: | ||
139 | # supervised no - no supervision interaction | ||
140 | # supervised upstart - signal upstart by putting Redis into SIGSTOP mode | ||
141 | # supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET | ||
142 | # supervised auto - detect upstart or systemd method based on | ||
143 | # UPSTART_JOB or NOTIFY_SOCKET environment variables | ||
144 | # Note: these supervision methods only signal "process is ready." | ||
145 | # They do not enable continuous liveness pings back to your supervisor. | ||
146 | supervised no | ||
147 | |||
148 | # If a pid file is specified, Redis writes it where specified at startup | ||
149 | # and removes it at exit. | ||
150 | # | ||
151 | # When the server runs non daemonized, no pid file is created if none is | ||
152 | # specified in the configuration. When the server is daemonized, the pid file | ||
153 | # is used even if not specified, defaulting to "/var/run/redis.pid". | ||
154 | # | ||
155 | # Creating a pid file is best effort: if Redis is not able to create it | ||
156 | # nothing bad happens, the server will start and run normally. | ||
157 | |||
158 | # When running daemonized, Redis writes a pid file in /var/run/redis.pid by | ||
159 | # default. You can specify a custom pid file location here. | ||
160 | pidfile /var/run/redis.pid | ||
161 | |||
162 | # Specify the server verbosity level. | ||
163 | # This can be one of: | ||
164 | # debug (a lot of information, useful for development/testing) | ||
165 | # verbose (many rarely useful info, but not a mess like the debug level) | ||
166 | # notice (moderately verbose, what you want in production probably) | ||
167 | # warning (only very important / critical messages are logged) | ||
168 | loglevel notice | ||
169 | |||
170 | # Specify the log file name. Also the empty string can be used to force | ||
171 | # Redis to log on the standard output. Note that if you use standard | ||
172 | # output for logging but daemonize, logs will be sent to /dev/null | ||
173 | logfile "" | ||
174 | |||
175 | # To enable logging to the system logger, just set 'syslog-enabled' to yes, | ||
176 | # and optionally update the other syslog parameters to suit your needs. | ||
177 | syslog-enabled yes | ||
178 | |||
179 | # Specify the syslog identity. | ||
180 | syslog-ident redis | ||
181 | |||
182 | # Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7. | ||
183 | # syslog-facility local0 | ||
184 | |||
185 | # Set the number of databases. The default database is DB 0, you can select | ||
186 | # a different one on a per-connection basis using SELECT <dbid> where | ||
187 | # dbid is a number between 0 and 'databases'-1 | ||
188 | databases 16 | ||
189 | |||
190 | # By default Redis shows an ASCII art logo only when started to log to the | ||
191 | # standard output and if the standard output is a TTY. Basically this means | ||
192 | # that normally a logo is displayed only in interactive sessions. | ||
193 | # | ||
194 | # However it is possible to force the pre-4.0 behavior and always show a | ||
195 | # ASCII art logo in startup logs by setting the following option to yes. | ||
196 | always-show-logo yes | ||
197 | |||
198 | ################################ SNAPSHOTTING ################################ | ||
199 | # | ||
200 | # Save the DB on disk: | ||
201 | # | ||
202 | # save <seconds> <changes> | ||
203 | # | ||
204 | # Will save the DB if both the given number of seconds and the given | ||
205 | # number of write operations against the DB occurred. | ||
206 | # | ||
207 | # In the example below the behaviour will be to save: | ||
208 | # after 900 sec (15 min) if at least 1 key changed | ||
209 | # after 300 sec (5 min) if at least 10 keys changed | ||
210 | # after 60 sec if at least 10000 keys changed | ||
211 | # | ||
212 | # Note: you can disable saving completely by commenting out all "save" lines. | ||
213 | # | ||
214 | # It is also possible to remove all the previously configured save | ||
215 | # points by adding a save directive with a single empty string argument | ||
216 | # like in the following example: | ||
217 | # | ||
218 | # save "" | ||
219 | |||
220 | #save 900 1 | ||
221 | #save 300 10 | ||
222 | #save 60 10000 | ||
223 | |||
224 | # OE: tune for a small embedded system with a limited # of keys. | ||
225 | save 120 1 | ||
226 | save 60 100 | ||
227 | save 30 1000 | ||
228 | |||
229 | # By default Redis will stop accepting writes if RDB snapshots are enabled | ||
230 | # (at least one save point) and the latest background save failed. | ||
231 | # This will make the user aware (in a hard way) that data is not persisting | ||
232 | # on disk properly, otherwise chances are that no one will notice and some | ||
233 | # disaster will happen. | ||
234 | # | ||
235 | # If the background saving process will start working again Redis will | ||
236 | # automatically allow writes again. | ||
237 | # | ||
238 | # However if you have setup your proper monitoring of the Redis server | ||
239 | # and persistence, you may want to disable this feature so that Redis will | ||
240 | # continue to work as usual even if there are problems with disk, | ||
241 | # permissions, and so forth. | ||
242 | stop-writes-on-bgsave-error yes | ||
243 | |||
244 | # Compress string objects using LZF when dump .rdb databases? | ||
245 | # For default that's set to 'yes' as it's almost always a win. | ||
246 | # If you want to save some CPU in the saving child set it to 'no' but | ||
247 | # the dataset will likely be bigger if you have compressible values or keys. | ||
248 | rdbcompression yes | ||
249 | |||
250 | # Since version 5 of RDB a CRC64 checksum is placed at the end of the file. | ||
251 | # This makes the format more resistant to corruption but there is a performance | ||
252 | # hit to pay (around 10%) when saving and loading RDB files, so you can disable it | ||
253 | # for maximum performances. | ||
254 | # | ||
255 | # RDB files created with checksum disabled have a checksum of zero that will | ||
256 | # tell the loading code to skip the check. | ||
257 | rdbchecksum yes | ||
258 | |||
259 | # The filename where to dump the DB | ||
260 | dbfilename dump.rdb | ||
261 | |||
262 | # The working directory. | ||
263 | # | ||
264 | # The DB will be written inside this directory, with the filename specified | ||
265 | # above using the 'dbfilename' configuration directive. | ||
266 | # | ||
267 | # The Append Only File will also be created inside this directory. | ||
268 | # | ||
269 | # Note that you must specify a directory here, not a file name. | ||
270 | dir /var/lib/redis/ | ||
271 | |||
272 | ################################# REPLICATION ################################# | ||
273 | |||
274 | # Master-Slave replication. Use slaveof to make a Redis instance a copy of | ||
275 | # another Redis server. A few things to understand ASAP about Redis replication. | ||
276 | # | ||
277 | # 1) Redis replication is asynchronous, but you can configure a master to | ||
278 | # stop accepting writes if it appears to be not connected with at least | ||
279 | # a given number of slaves. | ||
280 | # 2) Redis slaves are able to perform a partial resynchronization with the | ||
281 | # master if the replication link is lost for a relatively small amount of | ||
282 | # time. You may want to configure the replication backlog size (see the next | ||
283 | # sections of this file) with a sensible value depending on your needs. | ||
284 | # 3) Replication is automatic and does not need user intervention. After a | ||
285 | # network partition slaves automatically try to reconnect to masters | ||
286 | # and resynchronize with them. | ||
287 | # | ||
288 | # slaveof <masterip> <masterport> | ||
289 | |||
290 | # If the master is password protected (using the "requirepass" configuration | ||
291 | # directive below) it is possible to tell the slave to authenticate before | ||
292 | # starting the replication synchronization process, otherwise the master will | ||
293 | # refuse the slave request. | ||
294 | # | ||
295 | # masterauth <master-password> | ||
296 | |||
297 | # When a slave loses its connection with the master, or when the replication | ||
298 | # is still in progress, the slave can act in two different ways: | ||
299 | # | ||
300 | # 1) if slave-serve-stale-data is set to 'yes' (the default) the slave will | ||
301 | # still reply to client requests, possibly with out of date data, or the | ||
302 | # data set may just be empty if this is the first synchronization. | ||
303 | # | ||
304 | # 2) if slave-serve-stale-data is set to 'no' the slave will reply with | ||
305 | # an error "SYNC with master in progress" to all the kind of commands | ||
306 | # but to INFO and SLAVEOF. | ||
307 | # | ||
308 | slave-serve-stale-data yes | ||
309 | |||
310 | # You can configure a slave instance to accept writes or not. Writing against | ||
311 | # a slave instance may be useful to store some ephemeral data (because data | ||
312 | # written on a slave will be easily deleted after resync with the master) but | ||
313 | # may also cause problems if clients are writing to it because of a | ||
314 | # misconfiguration. | ||
315 | # | ||
316 | # Since Redis 2.6 by default slaves are read-only. | ||
317 | # | ||
318 | # Note: read only slaves are not designed to be exposed to untrusted clients | ||
319 | # on the internet. It's just a protection layer against misuse of the instance. | ||
320 | # Still a read only slave exports by default all the administrative commands | ||
321 | # such as CONFIG, DEBUG, and so forth. To a limited extent you can improve | ||
322 | # security of read only slaves using 'rename-command' to shadow all the | ||
323 | # administrative / dangerous commands. | ||
324 | slave-read-only yes | ||
325 | |||
326 | # Replication SYNC strategy: disk or socket. | ||
327 | # | ||
328 | # ------------------------------------------------------- | ||
329 | # WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY | ||
330 | # ------------------------------------------------------- | ||
331 | # | ||
332 | # New slaves and reconnecting slaves that are not able to continue the replication | ||
333 | # process just receiving differences, need to do what is called a "full | ||
334 | # synchronization". An RDB file is transmitted from the master to the slaves. | ||
335 | # The transmission can happen in two different ways: | ||
336 | # | ||
337 | # 1) Disk-backed: The Redis master creates a new process that writes the RDB | ||
338 | # file on disk. Later the file is transferred by the parent | ||
339 | # process to the slaves incrementally. | ||
340 | # 2) Diskless: The Redis master creates a new process that directly writes the | ||
341 | # RDB file to slave sockets, without touching the disk at all. | ||
342 | # | ||
343 | # With disk-backed replication, while the RDB file is generated, more slaves | ||
344 | # can be queued and served with the RDB file as soon as the current child producing | ||
345 | # the RDB file finishes its work. With diskless replication instead once | ||
346 | # the transfer starts, new slaves arriving will be queued and a new transfer | ||
347 | # will start when the current one terminates. | ||
348 | # | ||
349 | # When diskless replication is used, the master waits a configurable amount of | ||
350 | # time (in seconds) before starting the transfer in the hope that multiple slaves | ||
351 | # will arrive and the transfer can be parallelized. | ||
352 | # | ||
353 | # With slow disks and fast (large bandwidth) networks, diskless replication | ||
354 | # works better. | ||
355 | repl-diskless-sync no | ||
356 | |||
357 | # When diskless replication is enabled, it is possible to configure the delay | ||
358 | # the server waits in order to spawn the child that transfers the RDB via socket | ||
359 | # to the slaves. | ||
360 | # | ||
361 | # This is important since once the transfer starts, it is not possible to serve | ||
362 | # new slaves arriving, that will be queued for the next RDB transfer, so the server | ||
363 | # waits a delay in order to let more slaves arrive. | ||
364 | # | ||
365 | # The delay is specified in seconds, and by default is 5 seconds. To disable | ||
366 | # it entirely just set it to 0 seconds and the transfer will start ASAP. | ||
367 | repl-diskless-sync-delay 5 | ||
368 | |||
369 | # Slaves send PINGs to server in a predefined interval. It's possible to change | ||
370 | # this interval with the repl_ping_slave_period option. The default value is 10 | ||
371 | # seconds. | ||
372 | # | ||
373 | # repl-ping-slave-period 10 | ||
374 | |||
375 | # The following option sets the replication timeout for: | ||
376 | # | ||
377 | # 1) Bulk transfer I/O during SYNC, from the point of view of slave. | ||
378 | # 2) Master timeout from the point of view of slaves (data, pings). | ||
379 | # 3) Slave timeout from the point of view of masters (REPLCONF ACK pings). | ||
380 | # | ||
381 | # It is important to make sure that this value is greater than the value | ||
382 | # specified for repl-ping-slave-period otherwise a timeout will be detected | ||
383 | # every time there is low traffic between the master and the slave. | ||
384 | # | ||
385 | # repl-timeout 60 | ||
386 | |||
387 | # Disable TCP_NODELAY on the slave socket after SYNC? | ||
388 | # | ||
389 | # If you select "yes" Redis will use a smaller number of TCP packets and | ||
390 | # less bandwidth to send data to slaves. But this can add a delay for | ||
391 | # the data to appear on the slave side, up to 40 milliseconds with | ||
392 | # Linux kernels using a default configuration. | ||
393 | # | ||
394 | # If you select "no" the delay for data to appear on the slave side will | ||
395 | # be reduced but more bandwidth will be used for replication. | ||
396 | # | ||
397 | # By default we optimize for low latency, but in very high traffic conditions | ||
398 | # or when the master and slaves are many hops away, turning this to "yes" may | ||
399 | # be a good idea. | ||
400 | repl-disable-tcp-nodelay no | ||
401 | |||
402 | # Set the replication backlog size. The backlog is a buffer that accumulates | ||
403 | # slave data when slaves are disconnected for some time, so that when a slave | ||
404 | # wants to reconnect again, often a full resync is not needed, but a partial | ||
405 | # resync is enough, just passing the portion of data the slave missed while | ||
406 | # disconnected. | ||
407 | # | ||
408 | # The bigger the replication backlog, the longer the time the slave can be | ||
409 | # disconnected and later be able to perform a partial resynchronization. | ||
410 | # | ||
411 | # The backlog is only allocated once there is at least a slave connected. | ||
412 | # | ||
413 | # repl-backlog-size 1mb | ||
414 | |||
415 | # After a master has no longer connected slaves for some time, the backlog | ||
416 | # will be freed. The following option configures the amount of seconds that | ||
417 | # need to elapse, starting from the time the last slave disconnected, for | ||
418 | # the backlog buffer to be freed. | ||
419 | # | ||
420 | # Note that slaves never free the backlog for timeout, since they may be | ||
421 | # promoted to masters later, and should be able to correctly "partially | ||
422 | # resynchronize" with the slaves: hence they should always accumulate backlog. | ||
423 | # | ||
424 | # A value of 0 means to never release the backlog. | ||
425 | # | ||
426 | # repl-backlog-ttl 3600 | ||
427 | |||
428 | # The slave priority is an integer number published by Redis in the INFO output. | ||
429 | # It is used by Redis Sentinel in order to select a slave to promote into a | ||
430 | # master if the master is no longer working correctly. | ||
431 | # | ||
432 | # A slave with a low priority number is considered better for promotion, so | ||
433 | # for instance if there are three slaves with priority 10, 100, 25 Sentinel will | ||
434 | # pick the one with priority 10, that is the lowest. | ||
435 | # | ||
436 | # However a special priority of 0 marks the slave as not able to perform the | ||
437 | # role of master, so a slave with priority of 0 will never be selected by | ||
438 | # Redis Sentinel for promotion. | ||
439 | # | ||
440 | # By default the priority is 100. | ||
441 | slave-priority 100 | ||
442 | |||
443 | # It is possible for a master to stop accepting writes if there are less than | ||
444 | # N slaves connected, having a lag less or equal than M seconds. | ||
445 | # | ||
446 | # The N slaves need to be in "online" state. | ||
447 | # | ||
448 | # The lag in seconds, that must be <= the specified value, is calculated from | ||
449 | # the last ping received from the slave, that is usually sent every second. | ||
450 | # | ||
451 | # This option does not GUARANTEE that N replicas will accept the write, but | ||
452 | # will limit the window of exposure for lost writes in case not enough slaves | ||
453 | # are available, to the specified number of seconds. | ||
454 | # | ||
455 | # For example to require at least 3 slaves with a lag <= 10 seconds use: | ||
456 | # | ||
457 | # min-slaves-to-write 3 | ||
458 | # min-slaves-max-lag 10 | ||
459 | # | ||
460 | # Setting one or the other to 0 disables the feature. | ||
461 | # | ||
462 | # By default min-slaves-to-write is set to 0 (feature disabled) and | ||
463 | # min-slaves-max-lag is set to 10. | ||
464 | |||
465 | # A Redis master is able to list the address and port of the attached | ||
466 | # slaves in different ways. For example the "INFO replication" section | ||
467 | # offers this information, which is used, among other tools, by | ||
468 | # Redis Sentinel in order to discover slave instances. | ||
469 | # Another place where this info is available is in the output of the | ||
470 | # "ROLE" command of a master. | ||
471 | # | ||
472 | # The listed IP and address normally reported by a slave is obtained | ||
473 | # in the following way: | ||
474 | # | ||
475 | # IP: The address is auto detected by checking the peer address | ||
476 | # of the socket used by the slave to connect with the master. | ||
477 | # | ||
478 | # Port: The port is communicated by the slave during the replication | ||
479 | # handshake, and is normally the port that the slave is using to | ||
480 | # list for connections. | ||
481 | # | ||
482 | # However when port forwarding or Network Address Translation (NAT) is | ||
483 | # used, the slave may be actually reachable via different IP and port | ||
484 | # pairs. The following two options can be used by a slave in order to | ||
485 | # report to its master a specific set of IP and port, so that both INFO | ||
486 | # and ROLE will report those values. | ||
487 | # | ||
488 | # There is no need to use both the options if you need to override just | ||
489 | # the port or the IP address. | ||
490 | # | ||
491 | # slave-announce-ip 5.5.5.5 | ||
492 | # slave-announce-port 1234 | ||
493 | |||
494 | ################################## SECURITY ################################### | ||
495 | |||
496 | # Require clients to issue AUTH <PASSWORD> before processing any other | ||
497 | # commands. This might be useful in environments in which you do not trust | ||
498 | # others with access to the host running redis-server. | ||
499 | # | ||
500 | # This should stay commented out for backward compatibility and because most | ||
501 | # people do not need auth (e.g. they run their own servers). | ||
502 | # | ||
503 | # Warning: since Redis is pretty fast an outside user can try up to | ||
504 | # 150k passwords per second against a good box. This means that you should | ||
505 | # use a very strong password otherwise it will be very easy to break. | ||
506 | # | ||
507 | # requirepass foobared | ||
508 | |||
509 | # Command renaming. | ||
510 | # | ||
511 | # It is possible to change the name of dangerous commands in a shared | ||
512 | # environment. For instance the CONFIG command may be renamed into something | ||
513 | # hard to guess so that it will still be available for internal-use tools | ||
514 | # but not available for general clients. | ||
515 | # | ||
516 | # Example: | ||
517 | # | ||
518 | # rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 | ||
519 | # | ||
520 | # It is also possible to completely kill a command by renaming it into | ||
521 | # an empty string: | ||
522 | # | ||
523 | # rename-command CONFIG "" | ||
524 | # | ||
525 | # Please note that changing the name of commands that are logged into the | ||
526 | # AOF file or transmitted to slaves may cause problems. | ||
527 | |||
528 | ################################### CLIENTS #################################### | ||
529 | |||
530 | # Set the max number of connected clients at the same time. By default | ||
531 | # this limit is set to 10000 clients, however if the Redis server is not | ||
532 | # able to configure the process file limit to allow for the specified limit | ||
533 | # the max number of allowed clients is set to the current file limit | ||
534 | # minus 32 (as Redis reserves a few file descriptors for internal uses). | ||
535 | # | ||
536 | # Once the limit is reached Redis will close all the new connections sending | ||
537 | # an error 'max number of clients reached'. | ||
538 | # | ||
539 | # maxclients 10000 | ||
540 | |||
541 | ############################## MEMORY MANAGEMENT ################################ | ||
542 | |||
543 | # Set a memory usage limit to the specified amount of bytes. | ||
544 | # When the memory limit is reached Redis will try to remove keys | ||
545 | # according to the eviction policy selected (see maxmemory-policy). | ||
546 | # | ||
547 | # If Redis can't remove keys according to the policy, or if the policy is | ||
548 | # set to 'noeviction', Redis will start to reply with errors to commands | ||
549 | # that would use more memory, like SET, LPUSH, and so on, and will continue | ||
550 | # to reply to read-only commands like GET. | ||
551 | # | ||
552 | # This option is usually useful when using Redis as an LRU or LFU cache, or to | ||
553 | # set a hard memory limit for an instance (using the 'noeviction' policy). | ||
554 | # | ||
555 | # WARNING: If you have slaves attached to an instance with maxmemory on, | ||
556 | # the size of the output buffers needed to feed the slaves are subtracted | ||
557 | # from the used memory count, so that network problems / resyncs will | ||
558 | # not trigger a loop where keys are evicted, and in turn the output | ||
559 | # buffer of slaves is full with DELs of keys evicted triggering the deletion | ||
560 | # of more keys, and so forth until the database is completely emptied. | ||
561 | # | ||
562 | # In short... if you have slaves attached it is suggested that you set a lower | ||
563 | # limit for maxmemory so that there is some free RAM on the system for slave | ||
564 | # output buffers (but this is not needed if the policy is 'noeviction'). | ||
565 | # | ||
566 | # maxmemory <bytes> | ||
567 | |||
568 | # MAXMEMORY POLICY: how Redis will select what to remove when maxmemory | ||
569 | # is reached. You can select among five behaviors: | ||
570 | # | ||
571 | # volatile-lru -> Evict using approximated LRU among the keys with an expire set. | ||
572 | # allkeys-lru -> Evict any key using approximated LRU. | ||
573 | # volatile-lfu -> Evict using approximated LFU among the keys with an expire set. | ||
574 | # allkeys-lfu -> Evict any key using approximated LFU. | ||
575 | # volatile-random -> Remove a random key among the ones with an expire set. | ||
576 | # allkeys-random -> Remove a random key, any key. | ||
577 | # volatile-ttl -> Remove the key with the nearest expire time (minor TTL) | ||
578 | # noeviction -> Don't evict anything, just return an error on write operations. | ||
579 | # | ||
580 | # LRU means Least Recently Used | ||
581 | # LFU means Least Frequently Used | ||
582 | # | ||
583 | # Both LRU, LFU and volatile-ttl are implemented using approximated | ||
584 | # randomized algorithms. | ||
585 | # | ||
586 | # Note: with any of the above policies, Redis will return an error on write | ||
587 | # operations, when there are no suitable keys for eviction. | ||
588 | # | ||
589 | # At the date of writing these commands are: set setnx setex append | ||
590 | # incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd | ||
591 | # sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby | ||
592 | # zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby | ||
593 | # getset mset msetnx exec sort | ||
594 | # | ||
595 | # The default is: | ||
596 | # | ||
597 | # maxmemory-policy noeviction | ||
598 | |||
599 | # LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated | ||
600 | # algorithms (in order to save memory), so you can tune it for speed or | ||
601 | # accuracy. For default Redis will check five keys and pick the one that was | ||
602 | # used less recently, you can change the sample size using the following | ||
603 | # configuration directive. | ||
604 | # | ||
605 | # The default of 5 produces good enough results. 10 Approximates very closely | ||
606 | # true LRU but costs more CPU. 3 is faster but not very accurate. | ||
607 | # | ||
608 | # maxmemory-samples 5 | ||
609 | |||
610 | ############################# LAZY FREEING #################################### | ||
611 | |||
612 | # Redis has two primitives to delete keys. One is called DEL and is a blocking | ||
613 | # deletion of the object. It means that the server stops processing new commands | ||
614 | # in order to reclaim all the memory associated with an object in a synchronous | ||
615 | # way. If the key deleted is associated with a small object, the time needed | ||
616 | # in order to execute the DEL command is very small and comparable to most other | ||
617 | # O(1) or O(log_N) commands in Redis. However if the key is associated with an | ||
618 | # aggregated value containing millions of elements, the server can block for | ||
619 | # a long time (even seconds) in order to complete the operation. | ||
620 | # | ||
621 | # For the above reasons Redis also offers non blocking deletion primitives | ||
622 | # such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and | ||
623 | # FLUSHDB commands, in order to reclaim memory in background. Those commands | ||
624 | # are executed in constant time. Another thread will incrementally free the | ||
625 | # object in the background as fast as possible. | ||
626 | # | ||
627 | # DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled. | ||
628 | # It's up to the design of the application to understand when it is a good | ||
629 | # idea to use one or the other. However the Redis server sometimes has to | ||
630 | # delete keys or flush the whole database as a side effect of other operations. | ||
631 | # Specifically Redis deletes objects independently of a user call in the | ||
632 | # following scenarios: | ||
633 | # | ||
634 | # 1) On eviction, because of the maxmemory and maxmemory policy configurations, | ||
635 | # in order to make room for new data, without going over the specified | ||
636 | # memory limit. | ||
637 | # 2) Because of expire: when a key with an associated time to live (see the | ||
638 | # EXPIRE command) must be deleted from memory. | ||
639 | # 3) Because of a side effect of a command that stores data on a key that may | ||
640 | # already exist. For example the RENAME command may delete the old key | ||
641 | # content when it is replaced with another one. Similarly SUNIONSTORE | ||
642 | # or SORT with STORE option may delete existing keys. The SET command | ||
643 | # itself removes any old content of the specified key in order to replace | ||
644 | # it with the specified string. | ||
645 | # 4) During replication, when a slave performs a full resynchronization with | ||
646 | # its master, the content of the whole database is removed in order to | ||
647 | # load the RDB file just transfered. | ||
648 | # | ||
649 | # In all the above cases the default is to delete objects in a blocking way, | ||
650 | # like if DEL was called. However you can configure each case specifically | ||
651 | # in order to instead release memory in a non-blocking way like if UNLINK | ||
652 | # was called, using the following configuration directives: | ||
653 | |||
654 | lazyfree-lazy-eviction no | ||
655 | lazyfree-lazy-expire no | ||
656 | lazyfree-lazy-server-del no | ||
657 | slave-lazy-flush no | ||
658 | |||
659 | ############################## APPEND ONLY MODE ############################### | ||
660 | |||
661 | # By default Redis asynchronously dumps the dataset on disk. This mode is | ||
662 | # good enough in many applications, but an issue with the Redis process or | ||
663 | # a power outage may result into a few minutes of writes lost (depending on | ||
664 | # the configured save points). | ||
665 | # | ||
666 | # The Append Only File is an alternative persistence mode that provides | ||
667 | # much better durability. For instance using the default data fsync policy | ||
668 | # (see later in the config file) Redis can lose just one second of writes in a | ||
669 | # dramatic event like a server power outage, or a single write if something | ||
670 | # wrong with the Redis process itself happens, but the operating system is | ||
671 | # still running correctly. | ||
672 | # | ||
673 | # AOF and RDB persistence can be enabled at the same time without problems. | ||
674 | # If the AOF is enabled on startup Redis will load the AOF, that is the file | ||
675 | # with the better durability guarantees. | ||
676 | # | ||
677 | # Please check http://redis.io/topics/persistence for more information. | ||
678 | |||
679 | # OE: changed default to enable this | ||
680 | appendonly yes | ||
681 | |||
682 | # The name of the append only file (default: "appendonly.aof") | ||
683 | |||
684 | appendfilename "appendonly.aof" | ||
685 | |||
686 | # The fsync() call tells the Operating System to actually write data on disk | ||
687 | # instead of waiting for more data in the output buffer. Some OS will really flush | ||
688 | # data on disk, some other OS will just try to do it ASAP. | ||
689 | # | ||
690 | # Redis supports three different modes: | ||
691 | # | ||
692 | # no: don't fsync, just let the OS flush the data when it wants. Faster. | ||
693 | # always: fsync after every write to the append only log. Slow, Safest. | ||
694 | # everysec: fsync only one time every second. Compromise. | ||
695 | # | ||
696 | # The default is "everysec", as that's usually the right compromise between | ||
697 | # speed and data safety. It's up to you to understand if you can relax this to | ||
698 | # "no" that will let the operating system flush the output buffer when | ||
699 | # it wants, for better performances (but if you can live with the idea of | ||
700 | # some data loss consider the default persistence mode that's snapshotting), | ||
701 | # or on the contrary, use "always" that's very slow but a bit safer than | ||
702 | # everysec. | ||
703 | # | ||
704 | # More details please check the following article: | ||
705 | # http://antirez.com/post/redis-persistence-demystified.html | ||
706 | # | ||
707 | # If unsure, use "everysec". | ||
708 | |||
709 | # appendfsync always | ||
710 | appendfsync everysec | ||
711 | # appendfsync no | ||
712 | |||
713 | # When the AOF fsync policy is set to always or everysec, and a background | ||
714 | # saving process (a background save or AOF log background rewriting) is | ||
715 | # performing a lot of I/O against the disk, in some Linux configurations | ||
716 | # Redis may block too long on the fsync() call. Note that there is no fix for | ||
717 | # this currently, as even performing fsync in a different thread will block | ||
718 | # our synchronous write(2) call. | ||
719 | # | ||
720 | # In order to mitigate this problem it's possible to use the following option | ||
721 | # that will prevent fsync() from being called in the main process while a | ||
722 | # BGSAVE or BGREWRITEAOF is in progress. | ||
723 | # | ||
724 | # This means that while another child is saving, the durability of Redis is | ||
725 | # the same as "appendfsync none". In practical terms, this means that it is | ||
726 | # possible to lose up to 30 seconds of log in the worst scenario (with the | ||
727 | # default Linux settings). | ||
728 | # | ||
729 | # If you have latency problems turn this to "yes". Otherwise leave it as | ||
730 | # "no" that is the safest pick from the point of view of durability. | ||
731 | |||
732 | no-appendfsync-on-rewrite no | ||
733 | |||
734 | # Automatic rewrite of the append only file. | ||
735 | # Redis is able to automatically rewrite the log file implicitly calling | ||
736 | # BGREWRITEAOF when the AOF log size grows by the specified percentage. | ||
737 | # | ||
738 | # This is how it works: Redis remembers the size of the AOF file after the | ||
739 | # latest rewrite (if no rewrite has happened since the restart, the size of | ||
740 | # the AOF at startup is used). | ||
741 | # | ||
742 | # This base size is compared to the current size. If the current size is | ||
743 | # bigger than the specified percentage, the rewrite is triggered. Also | ||
744 | # you need to specify a minimal size for the AOF file to be rewritten, this | ||
745 | # is useful to avoid rewriting the AOF file even if the percentage increase | ||
746 | # is reached but it is still pretty small. | ||
747 | # | ||
748 | # Specify a percentage of zero in order to disable the automatic AOF | ||
749 | # rewrite feature. | ||
750 | |||
751 | auto-aof-rewrite-percentage 100 | ||
752 | auto-aof-rewrite-min-size 64mb | ||
753 | |||
754 | # An AOF file may be found to be truncated at the end during the Redis | ||
755 | # startup process, when the AOF data gets loaded back into memory. | ||
756 | # This may happen when the system where Redis is running | ||
757 | # crashes, especially when an ext4 filesystem is mounted without the | ||
758 | # data=ordered option (however this can't happen when Redis itself | ||
759 | # crashes or aborts but the operating system still works correctly). | ||
760 | # | ||
761 | # Redis can either exit with an error when this happens, or load as much | ||
762 | # data as possible (the default now) and start if the AOF file is found | ||
763 | # to be truncated at the end. The following option controls this behavior. | ||
764 | # | ||
765 | # If aof-load-truncated is set to yes, a truncated AOF file is loaded and | ||
766 | # the Redis server starts emitting a log to inform the user of the event. | ||
767 | # Otherwise if the option is set to no, the server aborts with an error | ||
768 | # and refuses to start. When the option is set to no, the user requires | ||
769 | # to fix the AOF file using the "redis-check-aof" utility before to restart | ||
770 | # the server. | ||
771 | # | ||
772 | # Note that if the AOF file will be found to be corrupted in the middle | ||
773 | # the server will still exit with an error. This option only applies when | ||
774 | # Redis will try to read more data from the AOF file but not enough bytes | ||
775 | # will be found. | ||
776 | aof-load-truncated yes | ||
777 | |||
778 | # When rewriting the AOF file, Redis is able to use an RDB preamble in the | ||
779 | # AOF file for faster rewrites and recoveries. When this option is turned | ||
780 | # on the rewritten AOF file is composed of two different stanzas: | ||
781 | # | ||
782 | # [RDB file][AOF tail] | ||
783 | # | ||
784 | # When loading Redis recognizes that the AOF file starts with the "REDIS" | ||
785 | # string and loads the prefixed RDB file, and continues loading the AOF | ||
786 | # tail. | ||
787 | # | ||
788 | # This is currently turned off by default in order to avoid the surprise | ||
789 | # of a format change, but will at some point be used as the default. | ||
790 | aof-use-rdb-preamble no | ||
791 | |||
792 | ################################ LUA SCRIPTING ############################### | ||
793 | |||
794 | # Max execution time of a Lua script in milliseconds. | ||
795 | # | ||
796 | # If the maximum execution time is reached Redis will log that a script is | ||
797 | # still in execution after the maximum allowed time and will start to | ||
798 | # reply to queries with an error. | ||
799 | # | ||
800 | # When a long running script exceeds the maximum execution time only the | ||
801 | # SCRIPT KILL and SHUTDOWN NOSAVE commands are available. The first can be | ||
802 | # used to stop a script that did not yet called write commands. The second | ||
803 | # is the only way to shut down the server in the case a write command was | ||
804 | # already issued by the script but the user doesn't want to wait for the natural | ||
805 | # termination of the script. | ||
806 | # | ||
807 | # Set it to 0 or a negative value for unlimited execution without warnings. | ||
808 | lua-time-limit 5000 | ||
809 | |||
810 | ################################ REDIS CLUSTER ############################### | ||
811 | # | ||
812 | # ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | ||
813 | # WARNING EXPERIMENTAL: Redis Cluster is considered to be stable code, however | ||
814 | # in order to mark it as "mature" we need to wait for a non trivial percentage | ||
815 | # of users to deploy it in production. | ||
816 | # ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | ||
817 | # | ||
818 | # Normal Redis instances can't be part of a Redis Cluster; only nodes that are | ||
819 | # started as cluster nodes can. In order to start a Redis instance as a | ||
820 | # cluster node enable the cluster support uncommenting the following: | ||
821 | # | ||
822 | # cluster-enabled yes | ||
823 | |||
824 | # Every cluster node has a cluster configuration file. This file is not | ||
825 | # intended to be edited by hand. It is created and updated by Redis nodes. | ||
826 | # Every Redis Cluster node requires a different cluster configuration file. | ||
827 | # Make sure that instances running in the same system do not have | ||
828 | # overlapping cluster configuration file names. | ||
829 | # | ||
830 | # cluster-config-file nodes-6379.conf | ||
831 | |||
832 | # Cluster node timeout is the amount of milliseconds a node must be unreachable | ||
833 | # for it to be considered in failure state. | ||
834 | # Most other internal time limits are multiple of the node timeout. | ||
835 | # | ||
836 | # cluster-node-timeout 15000 | ||
837 | |||
838 | # A slave of a failing master will avoid to start a failover if its data | ||
839 | # looks too old. | ||
840 | # | ||
841 | # There is no simple way for a slave to actually have an exact measure of | ||
842 | # its "data age", so the following two checks are performed: | ||
843 | # | ||
844 | # 1) If there are multiple slaves able to failover, they exchange messages | ||
845 | # in order to try to give an advantage to the slave with the best | ||
846 | # replication offset (more data from the master processed). | ||
847 | # Slaves will try to get their rank by offset, and apply to the start | ||
848 | # of the failover a delay proportional to their rank. | ||
849 | # | ||
850 | # 2) Every single slave computes the time of the last interaction with | ||
851 | # its master. This can be the last ping or command received (if the master | ||
852 | # is still in the "connected" state), or the time that elapsed since the | ||
853 | # disconnection with the master (if the replication link is currently down). | ||
854 | # If the last interaction is too old, the slave will not try to failover | ||
855 | # at all. | ||
856 | # | ||
857 | # The point "2" can be tuned by user. Specifically a slave will not perform | ||
858 | # the failover if, since the last interaction with the master, the time | ||
859 | # elapsed is greater than: | ||
860 | # | ||
861 | # (node-timeout * slave-validity-factor) + repl-ping-slave-period | ||
862 | # | ||
863 | # So for example if node-timeout is 30 seconds, and the slave-validity-factor | ||
864 | # is 10, and assuming a default repl-ping-slave-period of 10 seconds, the | ||
865 | # slave will not try to failover if it was not able to talk with the master | ||
866 | # for longer than 310 seconds. | ||
867 | # | ||
868 | # A large slave-validity-factor may allow slaves with too old data to failover | ||
869 | # a master, while a too small value may prevent the cluster from being able to | ||
870 | # elect a slave at all. | ||
871 | # | ||
872 | # For maximum availability, it is possible to set the slave-validity-factor | ||
873 | # to a value of 0, which means, that slaves will always try to failover the | ||
874 | # master regardless of the last time they interacted with the master. | ||
875 | # (However they'll always try to apply a delay proportional to their | ||
876 | # offset rank). | ||
877 | # | ||
878 | # Zero is the only value able to guarantee that when all the partitions heal | ||
879 | # the cluster will always be able to continue. | ||
880 | # | ||
881 | # cluster-slave-validity-factor 10 | ||
882 | |||
883 | # Cluster slaves are able to migrate to orphaned masters, that are masters | ||
884 | # that are left without working slaves. This improves the cluster ability | ||
885 | # to resist to failures as otherwise an orphaned master can't be failed over | ||
886 | # in case of failure if it has no working slaves. | ||
887 | # | ||
888 | # Slaves migrate to orphaned masters only if there are still at least a | ||
889 | # given number of other working slaves for their old master. This number | ||
890 | # is the "migration barrier". A migration barrier of 1 means that a slave | ||
891 | # will migrate only if there is at least 1 other working slave for its master | ||
892 | # and so forth. It usually reflects the number of slaves you want for every | ||
893 | # master in your cluster. | ||
894 | # | ||
895 | # Default is 1 (slaves migrate only if their masters remain with at least | ||
896 | # one slave). To disable migration just set it to a very large value. | ||
897 | # A value of 0 can be set but is useful only for debugging and dangerous | ||
898 | # in production. | ||
899 | # | ||
900 | # cluster-migration-barrier 1 | ||
901 | |||
902 | # By default Redis Cluster nodes stop accepting queries if they detect there | ||
903 | # is at least an hash slot uncovered (no available node is serving it). | ||
904 | # This way if the cluster is partially down (for example a range of hash slots | ||
905 | # are no longer covered) all the cluster becomes, eventually, unavailable. | ||
906 | # It automatically returns available as soon as all the slots are covered again. | ||
907 | # | ||
908 | # However sometimes you want the subset of the cluster which is working, | ||
909 | # to continue to accept queries for the part of the key space that is still | ||
910 | # covered. In order to do so, just set the cluster-require-full-coverage | ||
911 | # option to no. | ||
912 | # | ||
913 | # cluster-require-full-coverage yes | ||
914 | |||
915 | # In order to setup your cluster make sure to read the documentation | ||
916 | # available at http://redis.io web site. | ||
917 | |||
918 | ########################## CLUSTER DOCKER/NAT support ######################## | ||
919 | |||
920 | # In certain deployments, Redis Cluster nodes address discovery fails, because | ||
921 | # addresses are NAT-ted or because ports are forwarded (the typical case is | ||
922 | # Docker and other containers). | ||
923 | # | ||
924 | # In order to make Redis Cluster working in such environments, a static | ||
925 | # configuration where each node knows its public address is needed. The | ||
926 | # following two options are used for this scope, and are: | ||
927 | # | ||
928 | # * cluster-announce-ip | ||
929 | # * cluster-announce-port | ||
930 | # * cluster-announce-bus-port | ||
931 | # | ||
932 | # Each instruct the node about its address, client port, and cluster message | ||
933 | # bus port. The information is then published in the header of the bus packets | ||
934 | # so that other nodes will be able to correctly map the address of the node | ||
935 | # publishing the information. | ||
936 | # | ||
937 | # If the above options are not used, the normal Redis Cluster auto-detection | ||
938 | # will be used instead. | ||
939 | # | ||
940 | # Note that when remapped, the bus port may not be at the fixed offset of | ||
941 | # clients port + 10000, so you can specify any port and bus-port depending | ||
942 | # on how they get remapped. If the bus-port is not set, a fixed offset of | ||
943 | # 10000 will be used as usually. | ||
944 | # | ||
945 | # Example: | ||
946 | # | ||
947 | # cluster-announce-ip 10.1.1.5 | ||
948 | # cluster-announce-port 6379 | ||
949 | # cluster-announce-bus-port 6380 | ||
950 | |||
951 | ################################## SLOW LOG ################################### | ||
952 | |||
953 | # The Redis Slow Log is a system to log queries that exceeded a specified | ||
954 | # execution time. The execution time does not include the I/O operations | ||
955 | # like talking with the client, sending the reply and so forth, | ||
956 | # but just the time needed to actually execute the command (this is the only | ||
957 | # stage of command execution where the thread is blocked and can not serve | ||
958 | # other requests in the meantime). | ||
959 | # | ||
960 | # You can configure the slow log with two parameters: one tells Redis | ||
961 | # what is the execution time, in microseconds, to exceed in order for the | ||
962 | # command to get logged, and the other parameter is the length of the | ||
963 | # slow log. When a new command is logged the oldest one is removed from the | ||
964 | # queue of logged commands. | ||
965 | |||
966 | # The following time is expressed in microseconds, so 1000000 is equivalent | ||
967 | # to one second. Note that a negative number disables the slow log, while | ||
968 | # a value of zero forces the logging of every command. | ||
969 | slowlog-log-slower-than 10000 | ||
970 | |||
971 | # There is no limit to this length. Just be aware that it will consume memory. | ||
972 | # You can reclaim memory used by the slow log with SLOWLOG RESET. | ||
973 | slowlog-max-len 128 | ||
974 | |||
975 | ################################ LATENCY MONITOR ############################## | ||
976 | |||
977 | # The Redis latency monitoring subsystem samples different operations | ||
978 | # at runtime in order to collect data related to possible sources of | ||
979 | # latency of a Redis instance. | ||
980 | # | ||
981 | # Via the LATENCY command this information is available to the user that can | ||
982 | # print graphs and obtain reports. | ||
983 | # | ||
984 | # The system only logs operations that were performed in a time equal or | ||
985 | # greater than the amount of milliseconds specified via the | ||
986 | # latency-monitor-threshold configuration directive. When its value is set | ||
987 | # to zero, the latency monitor is turned off. | ||
988 | # | ||
989 | # By default latency monitoring is disabled since it is mostly not needed | ||
990 | # if you don't have latency issues, and collecting data has a performance | ||
991 | # impact, that while very small, can be measured under big load. Latency | ||
992 | # monitoring can easily be enabled at runtime using the command | ||
993 | # "CONFIG SET latency-monitor-threshold <milliseconds>" if needed. | ||
994 | latency-monitor-threshold 0 | ||
995 | |||
996 | ############################# EVENT NOTIFICATION ############################## | ||
997 | |||
998 | # Redis can notify Pub/Sub clients about events happening in the key space. | ||
999 | # This feature is documented at http://redis.io/topics/notifications | ||
1000 | # | ||
1001 | # For instance if keyspace events notification is enabled, and a client | ||
1002 | # performs a DEL operation on key "foo" stored in the Database 0, two | ||
1003 | # messages will be published via Pub/Sub: | ||
1004 | # | ||
1005 | # PUBLISH __keyspace@0__:foo del | ||
1006 | # PUBLISH __keyevent@0__:del foo | ||
1007 | # | ||
1008 | # It is possible to select the events that Redis will notify among a set | ||
1009 | # of classes. Every class is identified by a single character: | ||
1010 | # | ||
1011 | # K Keyspace events, published with __keyspace@<db>__ prefix. | ||
1012 | # E Keyevent events, published with __keyevent@<db>__ prefix. | ||
1013 | # g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ... | ||
1014 | # $ String commands | ||
1015 | # l List commands | ||
1016 | # s Set commands | ||
1017 | # h Hash commands | ||
1018 | # z Sorted set commands | ||
1019 | # x Expired events (events generated every time a key expires) | ||
1020 | # e Evicted events (events generated when a key is evicted for maxmemory) | ||
1021 | # A Alias for g$lshzxe, so that the "AKE" string means all the events. | ||
1022 | # | ||
1023 | # The "notify-keyspace-events" takes as argument a string that is composed | ||
1024 | # of zero or multiple characters. The empty string means that notifications | ||
1025 | # are disabled. | ||
1026 | # | ||
1027 | # Example: to enable list and generic events, from the point of view of the | ||
1028 | # event name, use: | ||
1029 | # | ||
1030 | # notify-keyspace-events Elg | ||
1031 | # | ||
1032 | # Example 2: to get the stream of the expired keys subscribing to channel | ||
1033 | # name __keyevent@0__:expired use: | ||
1034 | # | ||
1035 | # notify-keyspace-events Ex | ||
1036 | # | ||
1037 | # By default all notifications are disabled because most users don't need | ||
1038 | # this feature and the feature has some overhead. Note that if you don't | ||
1039 | # specify at least one of K or E, no events will be delivered. | ||
1040 | notify-keyspace-events "" | ||
1041 | |||
1042 | ############################### ADVANCED CONFIG ############################### | ||
1043 | |||
1044 | # Hashes are encoded using a memory efficient data structure when they have a | ||
1045 | # small number of entries, and the biggest entry does not exceed a given | ||
1046 | # threshold. These thresholds can be configured using the following directives. | ||
1047 | hash-max-ziplist-entries 512 | ||
1048 | hash-max-ziplist-value 64 | ||
1049 | |||
1050 | # Lists are also encoded in a special way to save a lot of space. | ||
1051 | # The number of entries allowed per internal list node can be specified | ||
1052 | # as a fixed maximum size or a maximum number of elements. | ||
1053 | # For a fixed maximum size, use -5 through -1, meaning: | ||
1054 | # -5: max size: 64 Kb <-- not recommended for normal workloads | ||
1055 | # -4: max size: 32 Kb <-- not recommended | ||
1056 | # -3: max size: 16 Kb <-- probably not recommended | ||
1057 | # -2: max size: 8 Kb <-- good | ||
1058 | # -1: max size: 4 Kb <-- good | ||
1059 | # Positive numbers mean store up to _exactly_ that number of elements | ||
1060 | # per list node. | ||
1061 | # The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size), | ||
1062 | # but if your use case is unique, adjust the settings as necessary. | ||
1063 | list-max-ziplist-size -2 | ||
1064 | |||
1065 | # Lists may also be compressed. | ||
1066 | # Compress depth is the number of quicklist ziplist nodes from *each* side of | ||
1067 | # the list to *exclude* from compression. The head and tail of the list | ||
1068 | # are always uncompressed for fast push/pop operations. Settings are: | ||
1069 | # 0: disable all list compression | ||
1070 | # 1: depth 1 means "don't start compressing until after 1 node into the list, | ||
1071 | # going from either the head or tail" | ||
1072 | # So: [head]->node->node->...->node->[tail] | ||
1073 | # [head], [tail] will always be uncompressed; inner nodes will compress. | ||
1074 | # 2: [head]->[next]->node->node->...->node->[prev]->[tail] | ||
1075 | # 2 here means: don't compress head or head->next or tail->prev or tail, | ||
1076 | # but compress all nodes between them. | ||
1077 | # 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail] | ||
1078 | # etc. | ||
1079 | list-compress-depth 0 | ||
1080 | |||
1081 | # Sets have a special encoding in just one case: when a set is composed | ||
1082 | # of just strings that happen to be integers in radix 10 in the range | ||
1083 | # of 64 bit signed integers. | ||
1084 | # The following configuration setting sets the limit in the size of the | ||
1085 | # set in order to use this special memory saving encoding. | ||
1086 | set-max-intset-entries 512 | ||
1087 | |||
1088 | # Similarly to hashes and lists, sorted sets are also specially encoded in | ||
1089 | # order to save a lot of space. This encoding is only used when the length and | ||
1090 | # elements of a sorted set are below the following limits: | ||
1091 | zset-max-ziplist-entries 128 | ||
1092 | zset-max-ziplist-value 64 | ||
1093 | |||
1094 | # HyperLogLog sparse representation bytes limit. The limit includes the | ||
1095 | # 16 bytes header. When an HyperLogLog using the sparse representation crosses | ||
1096 | # this limit, it is converted into the dense representation. | ||
1097 | # | ||
1098 | # A value greater than 16000 is totally useless, since at that point the | ||
1099 | # dense representation is more memory efficient. | ||
1100 | # | ||
1101 | # The suggested value is ~ 3000 in order to have the benefits of | ||
1102 | # the space efficient encoding without slowing down too much PFADD, | ||
1103 | # which is O(N) with the sparse encoding. The value can be raised to | ||
1104 | # ~ 10000 when CPU is not a concern, but space is, and the data set is | ||
1105 | # composed of many HyperLogLogs with cardinality in the 0 - 15000 range. | ||
1106 | hll-sparse-max-bytes 3000 | ||
1107 | |||
1108 | # Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in | ||
1109 | # order to help rehashing the main Redis hash table (the one mapping top-level | ||
1110 | # keys to values). The hash table implementation Redis uses (see dict.c) | ||
1111 | # performs a lazy rehashing: the more operation you run into a hash table | ||
1112 | # that is rehashing, the more rehashing "steps" are performed, so if the | ||
1113 | # server is idle the rehashing is never complete and some more memory is used | ||
1114 | # by the hash table. | ||
1115 | # | ||
1116 | # The default is to use this millisecond 10 times every second in order to | ||
1117 | # actively rehash the main dictionaries, freeing memory when possible. | ||
1118 | # | ||
1119 | # If unsure: | ||
1120 | # use "activerehashing no" if you have hard latency requirements and it is | ||
1121 | # not a good thing in your environment that Redis can reply from time to time | ||
1122 | # to queries with 2 milliseconds delay. | ||
1123 | # | ||
1124 | # use "activerehashing yes" if you don't have such hard requirements but | ||
1125 | # want to free memory asap when possible. | ||
1126 | activerehashing yes | ||
1127 | |||
1128 | # The client output buffer limits can be used to force disconnection of clients | ||
1129 | # that are not reading data from the server fast enough for some reason (a | ||
1130 | # common reason is that a Pub/Sub client can't consume messages as fast as the | ||
1131 | # publisher can produce them). | ||
1132 | # | ||
1133 | # The limit can be set differently for the three different classes of clients: | ||
1134 | # | ||
1135 | # normal -> normal clients including MONITOR clients | ||
1136 | # slave -> slave clients | ||
1137 | # pubsub -> clients subscribed to at least one pubsub channel or pattern | ||
1138 | # | ||
1139 | # The syntax of every client-output-buffer-limit directive is the following: | ||
1140 | # | ||
1141 | # client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds> | ||
1142 | # | ||
1143 | # A client is immediately disconnected once the hard limit is reached, or if | ||
1144 | # the soft limit is reached and remains reached for the specified number of | ||
1145 | # seconds (continuously). | ||
1146 | # So for instance if the hard limit is 32 megabytes and the soft limit is | ||
1147 | # 16 megabytes / 10 seconds, the client will get disconnected immediately | ||
1148 | # if the size of the output buffers reach 32 megabytes, but will also get | ||
1149 | # disconnected if the client reaches 16 megabytes and continuously overcomes | ||
1150 | # the limit for 10 seconds. | ||
1151 | # | ||
1152 | # By default normal clients are not limited because they don't receive data | ||
1153 | # without asking (in a push way), but just after a request, so only | ||
1154 | # asynchronous clients may create a scenario where data is requested faster | ||
1155 | # than it can read. | ||
1156 | # | ||
1157 | # Instead there is a default limit for pubsub and slave clients, since | ||
1158 | # subscribers and slaves receive data in a push fashion. | ||
1159 | # | ||
1160 | # Both the hard or the soft limit can be disabled by setting them to zero. | ||
1161 | client-output-buffer-limit normal 0 0 0 | ||
1162 | client-output-buffer-limit slave 256mb 64mb 60 | ||
1163 | client-output-buffer-limit pubsub 32mb 8mb 60 | ||
1164 | |||
1165 | # Client query buffers accumulate new commands. They are limited to a fixed | ||
1166 | # amount by default in order to avoid that a protocol desynchronization (for | ||
1167 | # instance due to a bug in the client) will lead to unbound memory usage in | ||
1168 | # the query buffer. However you can configure it here if you have very special | ||
1169 | # needs, such us huge multi/exec requests or alike. | ||
1170 | # | ||
1171 | # client-query-buffer-limit 1gb | ||
1172 | |||
1173 | # In the Redis protocol, bulk requests, that are, elements representing single | ||
1174 | # strings, are normally limited ot 512 mb. However you can change this limit | ||
1175 | # here. | ||
1176 | # | ||
1177 | # proto-max-bulk-len 512mb | ||
1178 | |||
1179 | # Redis calls an internal function to perform many background tasks, like | ||
1180 | # closing connections of clients in timeout, purging expired keys that are | ||
1181 | # never requested, and so forth. | ||
1182 | # | ||
1183 | # Not all tasks are performed with the same frequency, but Redis checks for | ||
1184 | # tasks to perform according to the specified "hz" value. | ||
1185 | # | ||
1186 | # By default "hz" is set to 10. Raising the value will use more CPU when | ||
1187 | # Redis is idle, but at the same time will make Redis more responsive when | ||
1188 | # there are many keys expiring at the same time, and timeouts may be | ||
1189 | # handled with more precision. | ||
1190 | # | ||
1191 | # The range is between 1 and 500, however a value over 100 is usually not | ||
1192 | # a good idea. Most users should use the default of 10 and raise this up to | ||
1193 | # 100 only in environments where very low latency is required. | ||
1194 | hz 10 | ||
1195 | |||
1196 | # When a child rewrites the AOF file, if the following option is enabled | ||
1197 | # the file will be fsync-ed every 32 MB of data generated. This is useful | ||
1198 | # in order to commit the file to the disk more incrementally and avoid | ||
1199 | # big latency spikes. | ||
1200 | aof-rewrite-incremental-fsync yes | ||
1201 | |||
1202 | # Redis LFU eviction (see maxmemory setting) can be tuned. However it is a good | ||
1203 | # idea to start with the default settings and only change them after investigating | ||
1204 | # how to improve the performances and how the keys LFU change over time, which | ||
1205 | # is possible to inspect via the OBJECT FREQ command. | ||
1206 | # | ||
1207 | # There are two tunable parameters in the Redis LFU implementation: the | ||
1208 | # counter logarithm factor and the counter decay time. It is important to | ||
1209 | # understand what the two parameters mean before changing them. | ||
1210 | # | ||
1211 | # The LFU counter is just 8 bits per key, it's maximum value is 255, so Redis | ||
1212 | # uses a probabilistic increment with logarithmic behavior. Given the value | ||
1213 | # of the old counter, when a key is accessed, the counter is incremented in | ||
1214 | # this way: | ||
1215 | # | ||
1216 | # 1. A random number R between 0 and 1 is extracted. | ||
1217 | # 2. A probability P is calculated as 1/(old_value*lfu_log_factor+1). | ||
1218 | # 3. The counter is incremented only if R < P. | ||
1219 | # | ||
1220 | # The default lfu-log-factor is 10. This is a table of how the frequency | ||
1221 | # counter changes with a different number of accesses with different | ||
1222 | # logarithmic factors: | ||
1223 | # | ||
1224 | # +--------+------------+------------+------------+------------+------------+ | ||
1225 | # | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits | | ||
1226 | # +--------+------------+------------+------------+------------+------------+ | ||
1227 | # | 0 | 104 | 255 | 255 | 255 | 255 | | ||
1228 | # +--------+------------+------------+------------+------------+------------+ | ||
1229 | # | 1 | 18 | 49 | 255 | 255 | 255 | | ||
1230 | # +--------+------------+------------+------------+------------+------------+ | ||
1231 | # | 10 | 10 | 18 | 142 | 255 | 255 | | ||
1232 | # +--------+------------+------------+------------+------------+------------+ | ||
1233 | # | 100 | 8 | 11 | 49 | 143 | 255 | | ||
1234 | # +--------+------------+------------+------------+------------+------------+ | ||
1235 | # | ||
1236 | # NOTE: The above table was obtained by running the following commands: | ||
1237 | # | ||
1238 | # redis-benchmark -n 1000000 incr foo | ||
1239 | # redis-cli object freq foo | ||
1240 | # | ||
1241 | # NOTE 2: The counter initial value is 5 in order to give new objects a chance | ||
1242 | # to accumulate hits. | ||
1243 | # | ||
1244 | # The counter decay time is the time, in minutes, that must elapse in order | ||
1245 | # for the key counter to be divided by two (or decremented if it has a value | ||
1246 | # less <= 10). | ||
1247 | # | ||
1248 | # The default value for the lfu-decay-time is 1. A Special value of 0 means to | ||
1249 | # decay the counter every time it happens to be scanned. | ||
1250 | # | ||
1251 | # lfu-log-factor 10 | ||
1252 | # lfu-decay-time 1 | ||
1253 | |||
1254 | ########################### ACTIVE DEFRAGMENTATION ####################### | ||
1255 | # | ||
1256 | # WARNING THIS FEATURE IS EXPERIMENTAL. However it was stress tested | ||
1257 | # even in production and manually tested by multiple engineers for some | ||
1258 | # time. | ||
1259 | # | ||
1260 | # What is active defragmentation? | ||
1261 | # ------------------------------- | ||
1262 | # | ||
1263 | # Active (online) defragmentation allows a Redis server to compact the | ||
1264 | # spaces left between small allocations and deallocations of data in memory, | ||
1265 | # thus allowing to reclaim back memory. | ||
1266 | # | ||
1267 | # Fragmentation is a natural process that happens with every allocator (but | ||
1268 | # less so with Jemalloc, fortunately) and certain workloads. Normally a server | ||
1269 | # restart is needed in order to lower the fragmentation, or at least to flush | ||
1270 | # away all the data and create it again. However thanks to this feature | ||
1271 | # implemented by Oran Agra for Redis 4.0 this process can happen at runtime | ||
1272 | # in an "hot" way, while the server is running. | ||
1273 | # | ||
1274 | # Basically when the fragmentation is over a certain level (see the | ||
1275 | # configuration options below) Redis will start to create new copies of the | ||
1276 | # values in contiguous memory regions by exploiting certain specific Jemalloc | ||
1277 | # features (in order to understand if an allocation is causing fragmentation | ||
1278 | # and to allocate it in a better place), and at the same time, will release the | ||
1279 | # old copies of the data. This process, repeated incrementally for all the keys | ||
1280 | # will cause the fragmentation to drop back to normal values. | ||
1281 | # | ||
1282 | # Important things to understand: | ||
1283 | # | ||
1284 | # 1. This feature is disabled by default, and only works if you compiled Redis | ||
1285 | # to use the copy of Jemalloc we ship with the source code of Redis. | ||
1286 | # This is the default with Linux builds. | ||
1287 | # | ||
1288 | # 2. You never need to enable this feature if you don't have fragmentation | ||
1289 | # issues. | ||
1290 | # | ||
1291 | # 3. Once you experience fragmentation, you can enable this feature when | ||
1292 | # needed with the command "CONFIG SET activedefrag yes". | ||
1293 | # | ||
1294 | # The configuration parameters are able to fine tune the behavior of the | ||
1295 | # defragmentation process. If you are not sure about what they mean it is | ||
1296 | # a good idea to leave the defaults untouched. | ||
1297 | |||
1298 | # Enabled active defragmentation | ||
1299 | # activedefrag yes | ||
1300 | |||
1301 | # Minimum amount of fragmentation waste to start active defrag | ||
1302 | # active-defrag-ignore-bytes 100mb | ||
1303 | |||
1304 | # Minimum percentage of fragmentation to start active defrag | ||
1305 | # active-defrag-threshold-lower 10 | ||
1306 | |||
1307 | # Maximum percentage of fragmentation at which we use maximum effort | ||
1308 | # active-defrag-threshold-upper 100 | ||
1309 | |||
1310 | # Minimal effort for defrag in CPU percentage | ||
1311 | # active-defrag-cycle-min 25 | ||
1312 | |||
1313 | # Maximal effort for defrag in CPU percentage | ||
1314 | # active-defrag-cycle-max 75 | ||
diff --git a/meta-oe/recipes-extended/redis/redis-7.2.6/redis.service b/meta-oe/recipes-extended/redis/redis-7.2.6/redis.service new file mode 100644 index 000000000..b7791d0df --- /dev/null +++ b/meta-oe/recipes-extended/redis/redis-7.2.6/redis.service | |||
@@ -0,0 +1,17 @@ | |||
1 | [Unit] | ||
2 | Description=Redis In-Memory Data Store | ||
3 | After=network.target | ||
4 | |||
5 | [Service] | ||
6 | User=redis | ||
7 | Group=redis | ||
8 | ExecStart=/usr/bin/redis-server /etc/redis/redis.conf | ||
9 | ExecStop=/usr/bin/redis-cli shutdown | ||
10 | Restart=always | ||
11 | LimitNOFILE=10032 | ||
12 | Type=notify | ||
13 | StateDirectory=redis | ||
14 | |||
15 | [Install] | ||
16 | WantedBy=multi-user.target | ||
17 | |||