api: add valkey
Pedro Lucas Porcellis porcellis@eletrotupi.com · 5 months ago
8eb3e96836781e34ce84fad5372e568854e630a5 Browse filesParents
4df4b33Changed files
3
Additions
+2654
Deletions
-1
api/Dockerfile
1 1
FROM node:24-alpine3.23
2 2
3 -
RUN apk add -U bash postgresql17-client build-base yaml-dev
3 +
RUN apk add -U bash postgresql17-client build-base yaml-dev valkey-cli
4 4
5 5
ARG UID=1000
6 6
ARG GID=1000
7 7
8 8
USER "${UID}:${GID}"
20 20
COPY --chown="${UID}:${GID}" . .
21 21
22 22
EXPOSE 3000
23 23
24 24
CMD ["npm", "run", "dev"]
docker-compose.yml
1 1
services:
2 2
db:
3 3
image: postgres:17-alpine
4 4
shm_size: 1g
5 5
user: postgres
16 16
POSTGRES_DB: orbit_dev
17 17
POSTGRES_PASSWORD: password
18 18
volumes:
19 19
- db_data:/var/lib/postgresql/data
20 20
21 +
valkey:
22 +
image: valkey/valkey:9.0-alpine
23 +
ports:
24 +
- '6379:6379'
25 +
volumes:
26 +
- valkey_data:/data
27 +
- ./etc/valkey.conf:/etc/valkey/valkey.conf
28 +
command: valkey-server /etc/valkey/valkey.conf
29 +
environment:
30 +
- ALLOW_EMPTY_PASSWORD=yes
31 +
21 32
api:
22 33
build: ./api
23 34
volumes:
24 35
- ./api:/app
25 36
- /app/node_modules
26 37
ports:
27 38
- 3000:3000
28 39
env_file:
29 40
- api/.env.development
30 41
depends_on:
42 +
valkey:
43 +
condition: service_started
31 44
db:
32 45
condition: service_healthy
33 46
restart: always
34 47
35 48
volumes:
36 49
db_data:
50 +
valkey_data:
/dev/null → etc/valkey.conf
1 +
# Valkey configuration file example.
2 +
#
3 +
# Note that in order to read the configuration file, the server must be
4 +
# started with the file path as first argument:
5 +
#
6 +
# ./valkey-server /path/to/valkey.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 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 +
# Note that option "include" won't be rewritten by command "CONFIG REWRITE"
28 +
# from admin or Sentinel. Since the server 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 +
# Included paths may contain wildcards. All files matching the wildcards will
36 +
# be included in alphabetical order.
37 +
# Note that if an include path contains a wildcards but no files match it when
38 +
# the server is started, the include statement will be ignored and no error will
39 +
# be emitted. It is safe, therefore, to include wildcard files from empty
40 +
# directories.
41 +
#
42 +
# include /path/to/local.conf
43 +
# include /path/to/other.conf
44 +
# include /path/to/fragments/*.conf
45 +
#
46 +
47 +
################################## MODULES #####################################
48 +
49 +
# Load modules at startup. If the server is not able to load modules
50 +
# it will abort. It is possible to use multiple loadmodule directives.
51 +
#
52 +
# loadmodule /path/to/my_module.so
53 +
# loadmodule /path/to/other_module.so
54 +
# loadmodule /path/to/args_module.so [arg [arg ...]]
55 +
56 +
################################## NETWORK #####################################
57 +
58 +
# By default, if no "bind" configuration directive is specified, the server listens
59 +
# for connections from all available network interfaces on the host machine.
60 +
# It is possible to listen to just one or multiple selected interfaces using
61 +
# the "bind" configuration directive, followed by one or more IP addresses.
62 +
# Each address can be prefixed by "-", which means that the server will not fail to
63 +
# start if the address is not available. Being not available only refers to
64 +
# addresses that does not correspond to any network interface. Addresses that
65 +
# are already in use will always fail, and unsupported protocols will always be
66 +
# silently skipped.
67 +
#
68 +
# Examples:
69 +
#
70 +
# bind 192.168.1.100 10.0.0.1 # listens on two specific IPv4 addresses
71 +
# bind 127.0.0.1 ::1 # listens on loopback IPv4 and IPv6
72 +
# bind * -::* # like the default, all available interfaces
73 +
#
74 +
# ~~~ WARNING ~~~ If the computer running the server is directly exposed to the
75 +
# internet, binding to all the interfaces is dangerous and will expose the
76 +
# instance to everybody on the internet. So by default we uncomment the
77 +
# following bind directive, that will force the server to listen only on the
78 +
# IPv4 and IPv6 (if available) loopback interface addresses (this means the server
79 +
# will only be able to accept client connections from the same host that it is
80 +
# running on).
81 +
#
82 +
# IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES
83 +
# COMMENT OUT THE FOLLOWING LINE.
84 +
#
85 +
# You will also need to set a password unless you explicitly disable protected
86 +
# mode.
87 +
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
88 +
bind 0.0.0.0 -::1
89 +
90 +
# By default, outgoing connections (from replica to primary, from Sentinel to
91 +
# instances, cluster bus, etc.) are not bound to a specific local address. In
92 +
# most cases, this means the operating system will handle that based on routing
93 +
# and the interface through which the connection goes out.
94 +
#
95 +
# Using bind-source-addr it is possible to configure a specific address to bind
96 +
# to, which may also affect how the connection gets routed.
97 +
#
98 +
# Example:
99 +
#
100 +
# bind-source-addr 10.0.0.1
101 +
102 +
# Protected mode is a layer of security protection, in order to avoid that
103 +
# the server instances left open on the internet are accessed and exploited.
104 +
#
105 +
# When protected mode is on and the default user has no password, the server
106 +
# only accepts local connections from the IPv4 address (127.0.0.1), IPv6 address
107 +
# (::1) or Unix domain sockets.
108 +
#
109 +
# By default protected mode is enabled. You should disable it only if
110 +
# you are sure you want clients from other hosts to connect to the server
111 +
# even if no authentication is configured.
112 +
protected-mode no
113 +
114 +
# The server uses default hardened security configuration directives to reduce the
115 +
# attack surface on innocent users. Therefore, several sensitive configuration
116 +
# directives are immutable, and some potentially-dangerous commands are blocked.
117 +
#
118 +
# Configuration directives that control files that the server writes to (e.g., 'dir'
119 +
# and 'dbfilename') and that aren't usually modified during runtime
120 +
# are protected by making them immutable.
121 +
#
122 +
# Commands that can increase the attack surface of the server and that aren't usually
123 +
# called by users are blocked by default.
124 +
#
125 +
# These can be exposed to either all connections or just local ones by setting
126 +
# each of the configs listed below to either of these values:
127 +
#
128 +
# no - Block for any connection (remain immutable)
129 +
# yes - Allow for any connection (no protection)
130 +
# local - Allow only for local connections. Ones originating from the
131 +
# IPv4 address (127.0.0.1), IPv6 address (::1) or Unix domain sockets.
132 +
#
133 +
# enable-protected-configs no
134 +
# enable-debug-command no
135 +
# enable-module-command no
136 +
137 +
# Accept connections on the specified port, default is 6379 (IANA #815344).
138 +
# If port 0 is specified the server will not listen on a TCP socket.
139 +
port 6379
140 +
141 +
# TCP listen() backlog.
142 +
#
143 +
# In high requests-per-second environments you need a high backlog in order
144 +
# to avoid slow clients connection issues. Note that the Linux kernel
145 +
# will silently truncate it to the value of /proc/sys/net/core/somaxconn so
146 +
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog
147 +
# in order to get the desired effect.
148 +
tcp-backlog 511
149 +
150 +
# Multipath TCP (MPTCP)
151 +
#
152 +
# MPTCP splits a single TCP connection into subflows over multiple interfaces or paths.
153 +
# It enables bandwidth aggregation, failover, and improved reliability.
154 +
# When set to 'yes', clients will be able to use MPTCP if requested. When not
155 +
# requested, regular TCP can be used like before.
156 +
# Note: MPTCP is supported in the mainline Linux kernel starting from version 5.6.
157 +
#
158 +
# mptcp yes
159 +
160 +
# Unix socket.
161 +
#
162 +
# Specify the path for the Unix socket that will be used to listen for
163 +
# incoming connections. There is no default, so the server will not listen
164 +
# on a unix socket when not specified.
165 +
#
166 +
# unixsocket /run/valkey.sock
167 +
# unixsocketgroup wheel
168 +
# unixsocketperm 700
169 +
170 +
# Close the connection after a client is idle for N seconds (0 to disable)
171 +
timeout 0
172 +
173 +
# TCP keepalive.
174 +
#
175 +
# If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence
176 +
# of communication. This is useful for two reasons:
177 +
#
178 +
# 1) Detect dead peers.
179 +
# 2) Force network equipment in the middle to consider the connection to be
180 +
# alive.
181 +
#
182 +
# On Linux, the specified value (in seconds) is the period used to send ACKs.
183 +
# Note that to close the connection the double of the time is needed.
184 +
# On other kernels the period depends on the kernel configuration.
185 +
tcp-keepalive 300
186 +
187 +
# Apply OS-specific mechanism to mark the listening socket with the specified
188 +
# ID, to support advanced routing and filtering capabilities.
189 +
#
190 +
# On Linux, the ID represents a connection mark.
191 +
# On FreeBSD, the ID represents a socket cookie ID.
192 +
# On OpenBSD, the ID represents a route table ID.
193 +
#
194 +
# The default value is 0, which implies no marking is required.
195 +
# socket-mark-id 0
196 +
197 +
################################# TLS/SSL #####################################
198 +
199 +
# By default, TLS/SSL is disabled. To enable it, the "tls-port" configuration
200 +
# directive can be used to define TLS-listening ports. To enable TLS on the
201 +
# default port, use:
202 +
#
203 +
# port 0
204 +
# tls-port 6379
205 +
206 +
# Configure a X.509 certificate and private key to use for authenticating the
207 +
# server to connected clients, primaries or cluster peers. These files should be
208 +
# PEM formatted.
209 +
#
210 +
# tls-cert-file valkey.crt
211 +
# tls-key-file valkey.key
212 +
#
213 +
# If the key file is encrypted using a passphrase, it can be included here
214 +
# as well.
215 +
#
216 +
# tls-key-file-pass secret
217 +
218 +
# Normally the server uses the same certificate for both server functions (accepting
219 +
# connections) and client functions (replicating from a primary, establishing
220 +
# cluster bus connections, etc.).
221 +
#
222 +
# Sometimes certificates are issued with attributes that designate them as
223 +
# client-only or server-only certificates. In that case it may be desired to use
224 +
# different certificates for incoming (server) and outgoing (client)
225 +
# connections. To do that, use the following directives:
226 +
#
227 +
# tls-client-cert-file client.crt
228 +
# tls-client-key-file client.key
229 +
#
230 +
# If the key file is encrypted using a passphrase, it can be included here
231 +
# as well.
232 +
#
233 +
# tls-client-key-file-pass secret
234 +
235 +
# Configure a DH parameters file to enable Diffie-Hellman (DH) key exchange,
236 +
# required by older versions of OpenSSL (<3.0). Newer versions do not require
237 +
# this configuration and recommend against it.
238 +
#
239 +
# tls-dh-params-file valkey.dh
240 +
241 +
# Configure a CA certificate(s) bundle or directory to authenticate TLS/SSL
242 +
# clients and peers. The server requires an explicit configuration of at least one
243 +
# of these, and will not implicitly use the system wide configuration.
244 +
#
245 +
# tls-ca-cert-file ca.crt
246 +
# tls-ca-cert-dir /etc/ssl/certs
247 +
248 +
# By default, clients (including replica servers) on a TLS port are required
249 +
# to authenticate using valid client side certificates.
250 +
#
251 +
# If "no" is specified, client certificates are not required and not accepted.
252 +
# If "optional" is specified, client certificates are accepted and must be
253 +
# valid if provided, but are not required.
254 +
#
255 +
# tls-auth-clients no
256 +
# tls-auth-clients optional
257 +
258 +
# Automatically authenticate TLS clients as Valkey users based on their
259 +
# certificates.
260 +
#
261 +
# If set to a field like "CN", the server will extract the corresponding field
262 +
# from the client's TLS certificate and attempt to find a Valkey user with the
263 +
# same name. If a matching user is found, the client is automatically
264 +
# authenticated as that user during the TLS handshake. If no matching user is
265 +
# found, the client is connected as the unauthenticated default user. Set to
266 +
# "off" to disable automatic user authentication via certificate fields.
267 +
#
268 +
# Supported values: CN, off. Default: off.
269 +
#
270 +
# tls-auth-clients-user CN
271 +
272 +
# By default, a replica does not attempt to establish a TLS connection
273 +
# with its primary.
274 +
#
275 +
# Use the following directive to enable TLS on replication links.
276 +
#
277 +
# tls-replication yes
278 +
279 +
# By default, the cluster bus uses a plain TCP connection. To enable
280 +
# TLS for the bus protocol, use the following directive:
281 +
#
282 +
# tls-cluster yes
283 +
284 +
# By default, only TLSv1.2 and TLSv1.3 are enabled and it is highly recommended
285 +
# that older formally deprecated versions are kept disabled to reduce the attack surface.
286 +
# You can explicitly specify TLS versions to support.
287 +
# Allowed values are case insensitive and include "TLSv1", "TLSv1.1", "TLSv1.2",
288 +
# "TLSv1.3" (OpenSSL >= 1.1.1) or any combination.
289 +
# To enable only TLSv1.2 and TLSv1.3, use:
290 +
#
291 +
# tls-protocols "TLSv1.2 TLSv1.3"
292 +
293 +
# Configure allowed ciphers. See the ciphers(1ssl) manpage for more information
294 +
# about the syntax of this string.
295 +
#
296 +
# Note: this configuration applies only to <= TLSv1.2.
297 +
#
298 +
# tls-ciphers DEFAULT:!MEDIUM
299 +
300 +
# Configure allowed TLSv1.3 ciphersuites. See the ciphers(1ssl) manpage for more
301 +
# information about the syntax of this string, and specifically for TLSv1.3
302 +
# ciphersuites.
303 +
#
304 +
# tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256
305 +
306 +
# When choosing a cipher, use the server's preference instead of the client
307 +
# preference. By default, the server follows the client's preference.
308 +
#
309 +
# tls-prefer-server-ciphers yes
310 +
311 +
# By default, TLS session caching is enabled to allow faster and less expensive
312 +
# reconnections by clients that support it. Use the following directive to disable
313 +
# caching.
314 +
#
315 +
# tls-session-caching no
316 +
317 +
# Change the default number of TLS sessions cached. A zero value sets the cache
318 +
# to unlimited size. The default size is 20480.
319 +
#
320 +
# tls-session-cache-size 5000
321 +
322 +
# Change the default timeout of cached TLS sessions. The default timeout is 300
323 +
# seconds.
324 +
#
325 +
# tls-session-cache-timeout 60
326 +
327 +
################################### RDMA ######################################
328 +
329 +
# Valkey Over RDMA is experimental, it may be changed or be removed in any minor or major version.
330 +
# By default, RDMA is disabled. To enable it, the "rdma-port" configuration
331 +
# directive can be used to define RDMA-listening ports.
332 +
#
333 +
# rdma-port 6379
334 +
# rdma-bind 192.168.1.100
335 +
336 +
# The RDMA receive transfer buffer is 1M by default. It can be set between 64K and 16M.
337 +
# Note that page size aligned size is preferred.
338 +
#
339 +
# rdma-rx-size 1048576
340 +
341 +
# The RDMA completion queue will use the completion vector to signal completion events
342 +
# via hardware interrupts. A large number of hardware interrupts can affect CPU performance.
343 +
# It is possible to tune the performance using rdma-completion-vector.
344 +
#
345 +
# Example 1. a) Pin hardware interrupt vectors [0, 3] to CPU [0, 3].
346 +
# b) Set CPU affinity for valkey to CPU [4, X].
347 +
# c) Any valkey server uses a random RDMA completion vector [-1].
348 +
# All valkey servers will not affect each other and will be isolated from kernel interrupts.
349 +
#
350 +
# SYS SYS SYS SYS VALKEY VALKEY VALKEY
351 +
# | | | | | | |
352 +
# CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 ... CPUX
353 +
# | | | |
354 +
# INTR0 INTR1 INTR2 INTR3
355 +
#
356 +
# Example 2. a) 1:1 pin hardware interrupt vectors [0, X] to CPU [0, X].
357 +
# b) Set CPU affinity for valkey [M] to CPU [M].
358 +
# c) Valkey server [M] uses RDMA completion vector [M].
359 +
# A single CPU [M] handles hardware interrupts, the RDMA completion vector [M],
360 +
# and the valkey server [M] within its context only.
361 +
# This avoids overhead and function calls across multiple CPUs, fully isolating
362 +
# each valkey server from one another.
363 +
#
364 +
# VALKEY VALKEY VALKEY VALKEY VALKEY VALKEY VALKEY
365 +
# | | | | | | |
366 +
# CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 ... CPUX
367 +
# | | | | | | |
368 +
# INTR0 INTR1 INTR2 INTR3 INTR4 INTR5 INTRX
369 +
#
370 +
# Use 0 and positive numbers to specify the RDMA completion vector, or specify -1 to allow
371 +
# the server to use a random vector for a new connection. The default vector is -1.
372 +
#
373 +
# rdma-completion-vector 0
374 +
375 +
################################# GENERAL #####################################
376 +
377 +
# By default the server does not run as a daemon. Use 'yes' if you need it.
378 +
# Note that the server will write a pid file in /var/run/valkey.pid when daemonized.
379 +
# When the server is supervised by upstart or systemd, this parameter has no impact.
380 +
daemonize no
381 +
382 +
# If you run the server from upstart or systemd, the server can interact with your
383 +
# supervision tree. Options:
384 +
# supervised no - no supervision interaction
385 +
# supervised upstart - signal upstart by putting the server into SIGSTOP mode
386 +
# requires "expect stop" in your upstart job config
387 +
# supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
388 +
# on startup, and updating the server status on a regular
389 +
# basis.
390 +
# supervised auto - detect upstart or systemd method based on
391 +
# UPSTART_JOB or NOTIFY_SOCKET environment variables
392 +
# Note: these supervision methods only signal "process is ready."
393 +
# They do not enable continuous pings back to your supervisor.
394 +
#
395 +
# The default is "no". To run under upstart/systemd, you can simply uncomment
396 +
# the line below:
397 +
#
398 +
# supervised auto
399 +
400 +
# If a pid file is specified, the server writes it where specified at startup
401 +
# and removes it at exit.
402 +
#
403 +
# When the server runs non daemonized, no pid file is created if none is
404 +
# specified in the configuration. When the server is daemonized, the pid file
405 +
# is used even if not specified, defaulting to "/var/run/valkey.pid".
406 +
#
407 +
# Creating a pid file is best effort: if the server is not able to create it
408 +
# nothing bad happens, the server will start and run normally.
409 +
#
410 +
# Note that on modern Linux systems "/run/valkey.pid" is more conforming
411 +
# and should be used instead.
412 +
pidfile /var/run/valkey_6379.pid
413 +
414 +
# Specify the server verbosity level.
415 +
# This can be one of:
416 +
# debug (a lot of information, useful for development/testing)
417 +
# verbose (many rarely useful info, but not a mess like the debug level)
418 +
# notice (moderately verbose, what you want in production probably)
419 +
# warning (only very important / critical messages are logged)
420 +
# nothing (nothing is logged)
421 +
loglevel notice
422 +
423 +
# Specify the logging format.
424 +
# This can be one of:
425 +
#
426 +
# - legacy: the default, traditional log format
427 +
# - logfmt: a structured log format; see https://www.brandur.org/logfmt
428 +
#
429 +
# log-format legacy
430 +
431 +
# Specify the timestamp format used in logs using 'log-timestamp-format'.
432 +
#
433 +
# - legacy: default format
434 +
# - iso8601: ISO 8601 extended date and time with time zone, on the form
435 +
# yyyy-mm-ddThh:mm:ss.sss±hh:mm
436 +
# - milliseconds: milliseconds since the epoch
437 +
#
438 +
# log-timestamp-format legacy
439 +
440 +
# Specify the log file name. Also the empty string can be used to force
441 +
# the server to log on the standard output. Note that if you use standard
442 +
# output for logging but daemonize, logs will be sent to /dev/null
443 +
logfile ""
444 +
445 +
# To enable logging to the system logger, just set 'syslog-enabled' to yes,
446 +
# and optionally update the other syslog parameters to suit your needs.
447 +
# syslog-enabled no
448 +
449 +
# Specify the syslog identity.
450 +
# syslog-ident valkey
451 +
452 +
# Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7.
453 +
# syslog-facility local0
454 +
455 +
# To disable the built in crash log, which will possibly produce cleaner core
456 +
# dumps when they are needed, uncomment the following:
457 +
#
458 +
# crash-log-enabled no
459 +
460 +
# To disable the fast memory check that's run as part of the crash log, which
461 +
# will possibly let the server terminate sooner, uncomment the following:
462 +
#
463 +
# crash-memcheck-enabled no
464 +
465 +
# Set the number of databases. The default database is DB 0, you can select
466 +
# a different one on a per-connection basis using SELECT <dbid> where
467 +
# dbid is a number between 0 and 'databases'-1
468 +
# Note: This setting is ignored in cluster mode. Use `cluster-databases` instead.
469 +
databases 16
470 +
471 +
# By default the server shows an ASCII art logo only when started to log to the
472 +
# standard output and if the standard output is a TTY and syslog logging is
473 +
# disabled. Basically this means that normally a logo is displayed only in
474 +
# interactive sessions.
475 +
#
476 +
# However it is possible to force the pre-4.0 behavior and always show a
477 +
# ASCII art logo in startup logs by setting the following option to yes.
478 +
always-show-logo no
479 +
480 +
# User data, including keys, values, client names, and ACL usernames, can be
481 +
# logged as part of assertions and other error cases. To prevent sensitive user
482 +
# information, such as PII, from being recorded in the server log file, this
483 +
# user data is hidden from the log by default. If you need to log user data for
484 +
# debugging or troubleshooting purposes, you can disable this feature by
485 +
# changing the config value to no.
486 +
hide-user-data-from-log yes
487 +
488 +
# By default, the server modifies the process title (as seen in 'top' and 'ps') to
489 +
# provide some runtime information. It is possible to disable this and leave
490 +
# the process name as executed by setting the following to no.
491 +
set-proc-title yes
492 +
493 +
# When changing the process title, the server uses the following template to construct
494 +
# the modified title.
495 +
#
496 +
# Template variables are specified in curly brackets. The following variables are
497 +
# supported:
498 +
#
499 +
# {title} Name of process as executed if parent, or type of child process.
500 +
# {listen-addr} Bind address or '*' followed by TCP or TLS port listening on, or
501 +
# Unix socket if only that's available.
502 +
# {server-mode} Special mode, i.e. "[sentinel]" or "[cluster]".
503 +
# {port} TCP port listening on, or 0.
504 +
# {tls-port} TLS port listening on, or 0.
505 +
# {unixsocket} Unix domain socket listening on, or "".
506 +
# {config-file} Name of configuration file used.
507 +
#
508 +
proc-title-template "{title} {listen-addr} {server-mode}"
509 +
510 +
# Set the local environment which is used for string comparison operations, and
511 +
# also affect the performance of Lua scripts. Empty String indicates the locale
512 +
# is derived from the environment variables.
513 +
locale-collate ""
514 +
515 +
# Valkey is largely compatible with Redis OSS, apart from a few cases where
516 +
# Valkey identifies itself as "Valkey" rather than "Redis". Extended
517 +
# Redis OSS compatibility mode makes Valkey pretend to be Redis. Enable this
518 +
# only if you have problems with tools or clients. This is a temporary
519 +
# configuration added in Valkey 8.0 and is scheduled to have no effect and
520 +
# will be removed in a future version.
521 +
#
522 +
# extended-redis-compatibility no
523 +
524 +
################################ SNAPSHOTTING ################################
525 +
526 +
# Save the DB to disk.
527 +
#
528 +
# save <seconds> <changes> [<seconds> <changes> ...]
529 +
#
530 +
# The server will save the DB if the given number of seconds elapsed and it
531 +
# surpassed the given number of write operations against the DB.
532 +
#
533 +
# Snapshotting can be completely disabled with a single empty string argument
534 +
# as in following example:
535 +
#
536 +
# save ""
537 +
#
538 +
# Unless specified otherwise, by default the server will save the DB:
539 +
# * After 3600 seconds (an hour) if at least 1 change was performed
540 +
# * After 300 seconds (5 minutes) if at least 100 changes were performed
541 +
# * After 60 seconds if at least 10000 changes were performed
542 +
#
543 +
# You can set these explicitly by uncommenting the following line.
544 +
#
545 +
# save 3600 1 300 100 60 10000
546 +
547 +
# By default the server will stop accepting writes if RDB snapshots are enabled
548 +
# (at least one save point) and the latest background save failed.
549 +
# This will make the user aware (in a hard way) that data is not persisting
550 +
# on disk properly, otherwise chances are that no one will notice and some
551 +
# disaster will happen.
552 +
#
553 +
# If the background saving process will start working again, the server will
554 +
# automatically allow writes again.
555 +
#
556 +
# However if you have setup your proper monitoring of the server
557 +
# and persistence, you may want to disable this feature so that the server will
558 +
# continue to work as usual even if there are problems with disk,
559 +
# permissions, and so forth.
560 +
stop-writes-on-bgsave-error yes
561 +
562 +
# Compress string objects using LZF when dump .rdb databases?
563 +
# By default compression is enabled as it's almost always a win.
564 +
# If you want to save some CPU in the saving child set it to 'no' but
565 +
# the dataset will likely be bigger if you have compressible values or keys.
566 +
rdbcompression yes
567 +
568 +
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
569 +
# This makes the format more resistant to corruption but there is a performance
570 +
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
571 +
# for maximum performances.
572 +
#
573 +
# RDB files created with checksum disabled have a checksum of zero that will
574 +
# tell the loading code to skip the check.
575 +
rdbchecksum yes
576 +
577 +
# Valkey can try to load an RDB dump produced by a future version of Valkey.
578 +
# This can only work on a best-effort basis, because future RDB versions may
579 +
# contain information that's not known to the current version. If no new features
580 +
# are used, it may be possible to import the data produced by a later version,
581 +
# but loading is aborted if unknown information is encountered. Possible values
582 +
# are 'strict' and 'relaxed'. This also applies to replication and the RESTORE
583 +
# command.
584 +
rdb-version-check strict
585 +
586 +
# Enables or disables full sanitization checks for ziplist and listpack etc when
587 +
# loading an RDB or RESTORE payload. This reduces the chances of a assertion or
588 +
# crash later on while processing commands.
589 +
# Options:
590 +
# no - Never perform full sanitization
591 +
# yes - Always perform full sanitization
592 +
# clients - Perform full sanitization only for user connections.
593 +
# Excludes: RDB files, RESTORE commands received from the primary
594 +
# connection, and client connections which have the
595 +
# skip-sanitize-payload ACL flag.
596 +
# The default should be 'clients' but since it currently affects cluster
597 +
# resharding via MIGRATE, it is temporarily set to 'no' by default.
598 +
#
599 +
# sanitize-dump-payload no
600 +
601 +
# The filename where to dump the DB
602 +
dbfilename dump.rdb
603 +
604 +
# Remove RDB files used by replication in instances without persistence
605 +
# enabled. By default this option is disabled, however there are environments
606 +
# where for regulations or other security concerns, RDB files persisted on
607 +
# disk by primaries in order to feed replicas, or stored on disk by replicas
608 +
# in order to load them for the initial synchronization, should be deleted
609 +
# ASAP. Note that this option ONLY WORKS in instances that have both AOF
610 +
# and RDB persistence disabled, otherwise is completely ignored.
611 +
#
612 +
# An alternative (and sometimes better) way to obtain the same effect is
613 +
# to use diskless replication on both primary and replicas instances. However
614 +
# in the case of replicas, diskless is not always an option.
615 +
rdb-del-sync-files no
616 +
617 +
# The working directory.
618 +
#
619 +
# The server log is written relative this directory, if the 'logfile'
620 +
# configuration directive is a relative path.
621 +
#
622 +
# The DB will be written inside this directory, with the filename specified
623 +
# above using the 'dbfilename' configuration directive.
624 +
#
625 +
# The Append Only File will also be created inside this directory.
626 +
#
627 +
# The Cluster config file is written relative this directory, if the
628 +
# 'cluster-config-file' configuration directive is a relative path.
629 +
#
630 +
# Note that you must specify a directory here, not a file name.
631 +
# Note that modifying 'dir' during runtime may have unexpected behavior,
632 +
# for example when a child process is running, related file operations may
633 +
# have unexpected effects.
634 +
dir ./
635 +
636 +
################################# REPLICATION #################################
637 +
638 +
# Master-Replica replication. Use replicaof to make a server a copy of
639 +
# another server. A few things to understand ASAP about replication.
640 +
#
641 +
# +------------------+ +---------------+
642 +
# | Master | ---> | Replica |
643 +
# | (receive writes) | | (exact copy) |
644 +
# +------------------+ +---------------+
645 +
#
646 +
# 1) Replication is asynchronous, but you can configure a primary to
647 +
# stop accepting writes if it appears to be not connected with at least
648 +
# a given number of replicas.
649 +
# 2) Replicas are able to perform a partial resynchronization with the
650 +
# primary if the replication link is lost for a relatively small amount of
651 +
# time. You may want to configure the replication backlog size (see the next
652 +
# sections of this file) with a sensible value depending on your needs.
653 +
# 3) Replication is automatic and does not need user intervention. After a
654 +
# network partition replicas automatically try to reconnect to primaries
655 +
# and resynchronize with them.
656 +
#
657 +
# replicaof <primary_ip> <primary_port>
658 +
659 +
# If the primary is password protected (using the "requirepass" configuration
660 +
# directive below) it is possible to tell the replica to authenticate before
661 +
# starting the replication synchronization process, otherwise the primary will
662 +
# refuse the replica request.
663 +
#
664 +
# primaryauth <primary-password>
665 +
#
666 +
# However this is not enough if you are using ACLs
667 +
# and the default user is not capable of running the PSYNC
668 +
# command and/or other commands needed for replication. In this case it's
669 +
# better to configure a special user to use with replication, and specify the
670 +
# primaryuser configuration as such:
671 +
#
672 +
# primaryuser <username>
673 +
#
674 +
# When primaryuser is specified, the replica will authenticate against its
675 +
# primary using the new AUTH form: AUTH <username> <password>.
676 +
677 +
# When a replica loses its connection with the primary, or when the replication
678 +
# is still in progress, the replica can act in two different ways:
679 +
#
680 +
# 1) if replica-serve-stale-data is set to 'yes' (the default) the replica will
681 +
# still reply to client requests, possibly with out of date data, or the
682 +
# data set may just be empty if this is the first synchronization.
683 +
#
684 +
# 2) If replica-serve-stale-data is set to 'no' the replica will reply with error
685 +
# "MASTERDOWN Link with MASTER is down and replica-serve-stale-data is set to 'no'"
686 +
# to all data access commands, excluding commands such as:
687 +
# INFO, REPLICAOF, AUTH, SHUTDOWN, REPLCONF, ROLE, CONFIG, SUBSCRIBE,
688 +
# UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, COMMAND, POST,
689 +
# HOST and LATENCY.
690 +
#
691 +
replica-serve-stale-data yes
692 +
693 +
# You can configure a replica instance to accept writes or not. Writing against
694 +
# a replica instance may be useful to store some ephemeral data (because data
695 +
# written on a replica will be easily deleted after resync with the primary) but
696 +
# may also cause problems if clients are writing to it because of a
697 +
# misconfiguration.
698 +
#
699 +
# By default, replicas are read-only.
700 +
#
701 +
# Note: read only replicas are not designed to be exposed to untrusted clients
702 +
# on the internet. It's just a protection layer against misuse of the instance.
703 +
# Still a read only replica exports by default all the administrative commands
704 +
# such as CONFIG, DEBUG, and so forth. To a limited extent you can improve
705 +
# security of read only replicas using 'rename-command' to shadow all the
706 +
# administrative / dangerous commands.
707 +
replica-read-only yes
708 +
709 +
# Replication SYNC strategy: disk or socket.
710 +
#
711 +
# New replicas and reconnecting replicas that are not able to continue the
712 +
# replication process just receiving differences, need to do what is called a
713 +
# "full synchronization". An RDB file is transmitted from the primary to the
714 +
# replicas.
715 +
#
716 +
# The transmission can happen in two different ways:
717 +
#
718 +
# 1) Disk-backed: The primary creates a new process that writes the RDB
719 +
# file on disk. Later the file is transferred by the parent
720 +
# process to the replicas incrementally.
721 +
# 2) Diskless: The primary creates a new process that directly writes the
722 +
# RDB file to replica sockets, without touching the disk at all.
723 +
#
724 +
# With disk-backed replication, while the RDB file is generated, more replicas
725 +
# can be queued and served with the RDB file as soon as the current child
726 +
# producing the RDB file finishes its work. With diskless replication instead
727 +
# once the transfer starts, new replicas arriving will be queued and a new
728 +
# transfer will start when the current one terminates.
729 +
#
730 +
# When diskless replication is used, the primary waits a configurable amount of
731 +
# time (in seconds) before starting the transfer in the hope that multiple
732 +
# replicas will arrive and the transfer can be parallelized.
733 +
#
734 +
# With slow disks and fast (large bandwidth) networks, diskless replication
735 +
# works better.
736 +
repl-diskless-sync yes
737 +
738 +
# When diskless replication is enabled, it is possible to configure the delay
739 +
# the server waits in order to spawn the child that transfers the RDB via socket
740 +
# to the replicas.
741 +
#
742 +
# This is important since once the transfer starts, it is not possible to serve
743 +
# new replicas arriving, that will be queued for the next RDB transfer, so the
744 +
# server waits a delay in order to let more replicas arrive.
745 +
#
746 +
# The delay is specified in seconds, and by default is 5 seconds. To disable
747 +
# it entirely just set it to 0 seconds and the transfer will start ASAP.
748 +
repl-diskless-sync-delay 5
749 +
750 +
# When diskless replication is enabled with a delay, it is possible to let
751 +
# the replication start before the maximum delay is reached if the maximum
752 +
# number of replicas expected have connected. Default of 0 means that the
753 +
# maximum is not defined and the server will wait the full delay.
754 +
repl-diskless-sync-max-replicas 0
755 +
756 +
# -----------------------------------------------------------------------------
757 +
# WARNING: Since in this setup the replica does not immediately store an RDB on
758 +
# disk, it may cause data loss during failovers. RDB diskless load + server
759 +
# modules not handling I/O reads may cause the server to abort in case of I/O errors
760 +
# during the initial synchronization stage with the primary.
761 +
# -----------------------------------------------------------------------------
762 +
#
763 +
# Replica can load the RDB it reads from the replication link directly from the
764 +
# socket, or store the RDB to a file and read that file after it was completely
765 +
# received from the primary.
766 +
#
767 +
# In many cases the disk is slower than the network, and storing and loading
768 +
# the RDB file may increase replication time (and even increase the primary's
769 +
# Copy on Write memory and replica buffers).
770 +
# However, when parsing the RDB file directly from the socket, in order to avoid
771 +
# data loss it's only safe to flush the current dataset when the new dataset is
772 +
# fully loaded in memory, resulting in higher memory usage.
773 +
# For this reason we have the following options:
774 +
#
775 +
# "disabled" - Don't use diskless load (store the rdb file to the disk first)
776 +
# "swapdb" - Keep current db contents in RAM while parsing the data directly
777 +
# from the socket. Replicas in this mode can keep serving current
778 +
# dataset while replication is in progress, except for cases where
779 +
# they can't recognize primary as having a data set from same
780 +
# replication history.
781 +
# Note that this requires sufficient memory, if you don't have it,
782 +
# you risk an OOM kill.
783 +
# "on-empty-db" - Use diskless load only when current dataset is empty. This is
784 +
# safer and avoid having old and new dataset loaded side by side
785 +
# during replication.
786 +
# "flush-before-load" - [dangerous] Flush all data before parsing. Note that if
787 +
# there's a problem before the replication succeeded you may
788 +
# lose all your data.
789 +
repl-diskless-load disabled
790 +
791 +
# This dual channel replication sync feature optimizes the full synchronization process
792 +
# between a primary and its replicas. When enabled, it reduces both memory and CPU load
793 +
# on the primary server.
794 +
#
795 +
# How it works:
796 +
# 1. During full sync, instead of accumulating replication data on the primary server,
797 +
# the data is sent directly to the syncing replica.
798 +
# 2. The primary's background save (bgsave) process streams the RDB snapshot directly
799 +
# to the replica over a separate connection.
800 +
#
801 +
# Tradeoff:
802 +
# While this approach reduces load on the primary, it shifts the burden of storing
803 +
# the replication buffer to the replica. This means the replica must have sufficient
804 +
# memory to accommodate the buffer during synchronization. However, this tradeoff is
805 +
# generally beneficial as it prevents potential performance degradation on the primary
806 +
# server, which is typically handling more critical operations.
807 +
#
808 +
# When toggling this configuration on or off during an ongoing synchronization process,
809 +
# it does not change the already running sync method. The new configuration will take
810 +
# effect only for subsequent synchronization processes.
811 +
812 +
dual-channel-replication-enabled no
813 +
814 +
# Master send PINGs to its replicas in a predefined interval. It's possible to
815 +
# change this interval with the repl_ping_replica_period option. The default
816 +
# value is 10 seconds.
817 +
#
818 +
# repl-ping-replica-period 10
819 +
820 +
# The following option sets the replication timeout for:
821 +
#
822 +
# 1) Bulk transfer I/O during SYNC, from the point of view of replica.
823 +
# 2) Master timeout from the point of view of replicas (data, pings).
824 +
# 3) Replica timeout from the point of view of primaries (REPLCONF ACK pings).
825 +
#
826 +
# It is important to make sure that this value is greater than the value
827 +
# specified for repl-ping-replica-period otherwise a timeout will be detected
828 +
# every time there is low traffic between the primary and the replica. The default
829 +
# value is 60 seconds.
830 +
#
831 +
# repl-timeout 60
832 +
833 +
# Disable TCP_NODELAY on the replica socket after SYNC?
834 +
#
835 +
# If you select "yes", the server will use a smaller number of TCP packets and
836 +
# less bandwidth to send data to replicas. But this can add a delay for
837 +
# the data to appear on the replica side, up to 40 milliseconds with
838 +
# Linux kernels using a default configuration.
839 +
#
840 +
# If you select "no" the delay for data to appear on the replica side will
841 +
# be reduced but more bandwidth will be used for replication.
842 +
#
843 +
# By default we optimize for low latency, but in very high traffic conditions
844 +
# or when the primary and replicas are many hops away, turning this to "yes" may
845 +
# be a good idea.
846 +
repl-disable-tcp-nodelay no
847 +
848 +
# Enables MPTCP for the replica's connection to the primary.
849 +
#
850 +
# An MPTCP connection is established between the primary and the replica if
851 +
# the replica has set 'repl-mptcp yes' and the primary has set 'mptcp yes'.
852 +
# Otherwise, it will automatically and implicitly fall back to a regular TCP
853 +
# connection.
854 +
#
855 +
# repl-mptcp no
856 +
857 +
# Set the replication backlog size. The backlog is a buffer that accumulates
858 +
# replica data when replicas are disconnected for some time, so that when a
859 +
# replica wants to reconnect again, often a full resync is not needed, but a
860 +
# partial resync is enough, just passing the portion of data the replica
861 +
# missed while disconnected.
862 +
#
863 +
# The bigger the replication backlog, the longer the replica can endure the
864 +
# disconnect and later be able to perform a partial resynchronization.
865 +
#
866 +
# The backlog is only allocated if there is at least one replica connected.
867 +
#
868 +
# repl-backlog-size 10mb
869 +
870 +
# After a primary has no connected replicas for some time, the backlog will be
871 +
# freed. The following option configures the amount of seconds that need to
872 +
# elapse, starting from the time the last replica disconnected, for the backlog
873 +
# buffer to be freed.
874 +
#
875 +
# Note that replicas never free the backlog for timeout, since they may be
876 +
# promoted to primaries later, and should be able to correctly "partially
877 +
# resynchronize" with other replicas: hence they should always accumulate backlog.
878 +
#
879 +
# A value of 0 means to never release the backlog.
880 +
#
881 +
# repl-backlog-ttl 3600
882 +
883 +
# The replica priority is an integer number published by the server in the INFO
884 +
# output. It is used by Sentinel in order to select a replica to promote
885 +
# into a primary if the primary is no longer working correctly.
886 +
#
887 +
# A replica with a low priority number is considered better for promotion, so
888 +
# for instance if there are three replicas with priority 10, 100, 25 Sentinel
889 +
# will pick the one with priority 10, that is the lowest.
890 +
#
891 +
# However a special priority of 0 marks the replica as not able to perform the
892 +
# role of primary, so a replica with priority of 0 will never be selected by
893 +
# Sentinel for promotion.
894 +
#
895 +
# By default the priority is 100.
896 +
replica-priority 100
897 +
898 +
# The propagation error behavior controls how the server will behave when it is
899 +
# unable to handle a command being processed in the replication stream from a primary
900 +
# or processed while reading from an AOF file. Errors that occur during propagation
901 +
# are unexpected, and can cause data inconsistency.
902 +
#
903 +
# If an application wants to ensure there is no data divergence, this configuration
904 +
# should be set to 'panic' instead. The value can also be set to 'panic-on-replicas'
905 +
# to only panic when a replica encounters an error on the replication stream. One of
906 +
# these two panic values will become the default value in the future once there are
907 +
# sufficient safety mechanisms in place to prevent false positive crashes.
908 +
#
909 +
# propagation-error-behavior ignore
910 +
911 +
# Replica ignore disk write errors controls the behavior of a replica when it is
912 +
# unable to persist a write command received from its primary to disk. By default,
913 +
# this configuration is set to 'no' and will crash the replica in this condition.
914 +
# It is not recommended to change this default.
915 +
#
916 +
# replica-ignore-disk-write-errors no
917 +
918 +
# Make the primary forbid expiration and eviction.
919 +
# This is useful for sync tools, because expiration and eviction may cause the data corruption.
920 +
# Sync tools can mark their connections as importing source by CLIENT IMPORT-SOURCE.
921 +
# NOTICE: Clients should avoid writing the same key on the source server and the destination server.
922 +
#
923 +
# import-mode no
924 +
925 +
# -----------------------------------------------------------------------------
926 +
# By default, Sentinel includes all replicas in its reports. A replica
927 +
# can be excluded from Sentinel's announcements. An unannounced replica
928 +
# will be ignored by the 'sentinel replicas <primary>' command and won't be
929 +
# exposed to Sentinel's clients.
930 +
#
931 +
# This option does not change the behavior of replica-priority. Even with
932 +
# replica-announced set to 'no', the replica can be promoted to primary. To
933 +
# prevent this behavior, set replica-priority to 0.
934 +
#
935 +
# replica-announced yes
936 +
937 +
# It is possible for a primary to stop accepting writes if there are less than
938 +
# N replicas connected, having a lag less or equal than M seconds.
939 +
#
940 +
# The N replicas need to be in "online" state.
941 +
#
942 +
# The lag in seconds, that must be <= the specified value, is calculated from
943 +
# the last ping received from the replica, that is usually sent every second.
944 +
#
945 +
# This option does not GUARANTEE that N replicas will accept the write, but
946 +
# will limit the window of exposure for lost writes in case not enough replicas
947 +
# are available, to the specified number of seconds.
948 +
#
949 +
# For example to require at least 3 replicas with a lag <= 10 seconds use:
950 +
#
951 +
# min-replicas-to-write 3
952 +
# min-replicas-max-lag 10
953 +
#
954 +
# Setting one or the other to 0 disables the feature.
955 +
#
956 +
# By default min-replicas-to-write is set to 0 (feature disabled) and
957 +
# min-replicas-max-lag is set to 10.
958 +
959 +
# A primary is able to list the address and port of the attached
960 +
# replicas in different ways. For example the "INFO replication" section
961 +
# offers this information, which is used, among other tools, by
962 +
# Sentinel in order to discover replica instances.
963 +
# Another place where this info is available is in the output of the
964 +
# "ROLE" command of a primary.
965 +
#
966 +
# The listed IP address and port normally reported by a replica is
967 +
# obtained in the following way:
968 +
#
969 +
# IP: The address is auto detected by checking the peer address
970 +
# of the socket used by the replica to connect with the primary.
971 +
#
972 +
# Port: The port is communicated by the replica during the replication
973 +
# handshake, and is normally the port that the replica is using to
974 +
# listen for connections.
975 +
#
976 +
# However when port forwarding or Network Address Translation (NAT) is
977 +
# used, the replica may actually be reachable via different IP and port
978 +
# pairs. The following two options can be used by a replica in order to
979 +
# report to its primary a specific set of IP and port, so that both INFO
980 +
# and ROLE will report those values.
981 +
#
982 +
# There is no need to use both the options if you need to override just
983 +
# the port or the IP address.
984 +
#
985 +
# replica-announce-ip 5.5.5.5
986 +
# replica-announce-port 1234
987 +
988 +
############################### KEYS TRACKING #################################
989 +
990 +
# The client side caching of values is assisted via server-side support.
991 +
# This is implemented using an invalidation table that remembers, using
992 +
# a radix key indexed by key name, what clients have which keys. In turn
993 +
# this is used in order to send invalidation messages to clients. Please
994 +
# check this page to understand more about the feature:
995 +
#
996 +
# https://valkey.io/topics/client-side-caching
997 +
#
998 +
# When tracking is enabled for a client, all the read only queries are assumed
999 +
# to be cached: this will force the server to store information in the invalidation
1000 +
# table. When keys are modified, such information is flushed away, and
1001 +
# invalidation messages are sent to the clients. However if the workload is
1002 +
# heavily dominated by reads, the server could use more and more memory in order
1003 +
# to track the keys fetched by many clients.
1004 +
#
1005 +
# For this reason it is possible to configure a maximum fill value for the
1006 +
# invalidation table. By default it is set to 1M of keys, and once this limit
1007 +
# is reached, the server will start to evict keys in the invalidation table
1008 +
# even if they were not modified, just to reclaim memory: this will in turn
1009 +
# force the clients to invalidate the cached values. Basically the table
1010 +
# maximum size is a trade off between the memory you want to spend server
1011 +
# side to track information about who cached what, and the ability of clients
1012 +
# to retain cached objects in memory.
1013 +
#
1014 +
# If you set the value to 0, it means there are no limits, and the server will
1015 +
# retain as many keys as needed in the invalidation table.
1016 +
# In the "stats" INFO section, you can find information about the number of
1017 +
# keys in the invalidation table at every given moment.
1018 +
#
1019 +
# Note: when key tracking is used in broadcasting mode, no memory is used
1020 +
# in the server side so this setting is useless.
1021 +
#
1022 +
# tracking-table-max-keys 1000000
1023 +
1024 +
################################## SECURITY ###################################
1025 +
1026 +
# Warning: since the server is pretty fast, an outside user can try up to
1027 +
# 1 million passwords per second against a modern box. This means that you
1028 +
# should use very strong passwords, otherwise they will be very easy to break.
1029 +
# Note that because the password is really a shared secret between the client
1030 +
# and the server, and should not be memorized by any human, the password
1031 +
# can be easily a long string from /dev/urandom or whatever, so by using a
1032 +
# long and unguessable password no brute force attack will be possible.
1033 +
1034 +
# ACL users are defined in the following format:
1035 +
#
1036 +
# user <username> ... acl rules ...
1037 +
#
1038 +
# For example:
1039 +
#
1040 +
# user worker +@list +@connection ~jobs:* on >ffa9203c493aa99
1041 +
#
1042 +
# The special username "default" is used for new connections. If this user
1043 +
# has the "nopass" rule, then new connections will be immediately authenticated
1044 +
# as the "default" user without the need of any password provided via the
1045 +
# AUTH command. Otherwise if the "default" user is not flagged with "nopass"
1046 +
# the connections will start in not authenticated state, and will require
1047 +
# AUTH (or the HELLO command AUTH option) in order to be authenticated and
1048 +
# start to work.
1049 +
#
1050 +
# The ACL rules that describe what a user can do are the following:
1051 +
#
1052 +
# on Enable the user: it is possible to authenticate as this user.
1053 +
# off Disable the user: it's no longer possible to authenticate
1054 +
# with this user, however the already authenticated connections
1055 +
# will still work.
1056 +
# skip-sanitize-payload RESTORE dump-payload sanitization is skipped.
1057 +
# sanitize-payload RESTORE dump-payload is sanitized (default).
1058 +
# +<command> Allow the execution of that command.
1059 +
# May be used with `|` for allowing subcommands (e.g "+config|get")
1060 +
# -<command> Disallow the execution of that command.
1061 +
# May be used with `|` for blocking subcommands (e.g "-config|set")
1062 +
# +@<category> Allow the execution of all the commands in such category
1063 +
# with valid categories are like @admin, @set, @sortedset, ...
1064 +
# and so forth, see the full list in the server.c file where
1065 +
# the server command table is described and defined.
1066 +
# The special category @all means all the commands, but currently
1067 +
# present in the server, and that will be loaded in the future
1068 +
# via modules.
1069 +
# +<command>|first-arg Allow a specific first argument of an otherwise
1070 +
# disabled command. It is only supported on commands with
1071 +
# no sub-commands, and is not allowed as negative form
1072 +
# like -SELECT|1, only additive starting with "+". This
1073 +
# feature is deprecated and may be removed in the future.
1074 +
# allcommands Alias for +@all. Note that it implies the ability to execute
1075 +
# all the future commands loaded via the modules system.
1076 +
# nocommands Alias for -@all.
1077 +
# ~<pattern> Add a pattern of keys that can be mentioned as part of
1078 +
# commands. For instance ~* allows all the keys. The pattern
1079 +
# is a glob-style pattern like the one of KEYS.
1080 +
# It is possible to specify multiple patterns.
1081 +
# %R~<pattern> Add key read pattern that specifies which keys can be read
1082 +
# from.
1083 +
# %W~<pattern> Add key write pattern that specifies which keys can be
1084 +
# written to.
1085 +
# allkeys Alias for ~*
1086 +
# resetkeys Flush the list of allowed keys patterns.
1087 +
# &<pattern> Add a glob-style pattern of Pub/Sub channels that can be
1088 +
# accessed by the user. It is possible to specify multiple channel
1089 +
# patterns.
1090 +
# allchannels Alias for &*
1091 +
# resetchannels Flush the list of allowed channel patterns.
1092 +
# ><password> Add this password to the list of valid password for the user.
1093 +
# For example >mypass will add "mypass" to the list.
1094 +
# This directive clears the "nopass" flag (see later).
1095 +
# <<password> Remove this password from the list of valid passwords.
1096 +
# nopass All the set passwords of the user are removed, and the user
1097 +
# is flagged as requiring no password: it means that every
1098 +
# password will work against this user. If this directive is
1099 +
# used for the default user, every new connection will be
1100 +
# immediately authenticated with the default user without
1101 +
# any explicit AUTH command required. Note that the "resetpass"
1102 +
# directive will clear this condition.
1103 +
# resetpass Flush the list of allowed passwords. Moreover removes the
1104 +
# "nopass" status. After "resetpass" the user has no associated
1105 +
# passwords and there is no way to authenticate without adding
1106 +
# some password (or setting it as "nopass" later).
1107 +
# reset Performs the following actions: resetpass, resetkeys, resetchannels,
1108 +
# allchannels (if acl-pubsub-default is set), off, clearselectors, -@all.
1109 +
# The user returns to the same state it has immediately after its creation.
1110 +
# (<options>) Create a new selector with the options specified within the
1111 +
# parentheses and attach it to the user. Each option should be
1112 +
# space separated. The first character must be ( and the last
1113 +
# character must be ).
1114 +
# clearselectors Remove all of the currently attached selectors.
1115 +
# Note this does not change the "root" user permissions,
1116 +
# which are the permissions directly applied onto the
1117 +
# user (outside the parentheses).
1118 +
#
1119 +
# ACL rules can be specified in any order: for instance you can start with
1120 +
# passwords, then flags, or key patterns. However note that the additive
1121 +
# and subtractive rules will CHANGE MEANING depending on the ordering.
1122 +
# For instance see the following example:
1123 +
#
1124 +
# user alice on +@all -DEBUG ~* >somepassword
1125 +
#
1126 +
# This will allow "alice" to use all the commands with the exception of the
1127 +
# DEBUG command, since +@all added all the commands to the set of the commands
1128 +
# alice can use, and later DEBUG was removed. However if we invert the order
1129 +
# of two ACL rules the result will be different:
1130 +
#
1131 +
# user alice on -DEBUG +@all ~* >somepassword
1132 +
#
1133 +
# Now DEBUG was removed when alice had yet no commands in the set of allowed
1134 +
# commands, later all the commands are added, so the user will be able to
1135 +
# execute everything.
1136 +
#
1137 +
# Basically ACL rules are processed left-to-right.
1138 +
#
1139 +
# The following is a list of command categories and their meanings:
1140 +
# * keyspace - Writing or reading from keys, databases, or their metadata
1141 +
# in a type agnostic way. Includes DEL, RESTORE, DUMP, RENAME, EXISTS, DBSIZE,
1142 +
# KEYS, EXPIRE, TTL, FLUSHALL, etc. Commands that may modify the keyspace,
1143 +
# key or metadata will also have `write` category. Commands that only read
1144 +
# the keyspace, key or metadata will have the `read` category.
1145 +
# * read - Reading from keys (values or metadata). Note that commands that don't
1146 +
# interact with keys, will not have either `read` or `write`.
1147 +
# * write - Writing to keys (values or metadata)
1148 +
# * admin - Administrative commands. Normal applications will never need to use
1149 +
# these. Includes REPLICAOF, CONFIG, DEBUG, SAVE, MONITOR, ACL, SHUTDOWN, etc.
1150 +
# * dangerous - Potentially dangerous (each should be considered with care for
1151 +
# various reasons). This includes FLUSHALL, MIGRATE, RESTORE, SORT, KEYS,
1152 +
# CLIENT, DEBUG, INFO, CONFIG, SAVE, REPLICAOF, etc.
1153 +
# * connection - Commands affecting the connection or other connections.
1154 +
# This includes AUTH, SELECT, COMMAND, CLIENT, ECHO, PING, etc.
1155 +
# * blocking - Potentially blocking the connection until released by another
1156 +
# command.
1157 +
# * fast - Fast O(1) commands. May loop on the number of arguments, but not the
1158 +
# number of elements in the key.
1159 +
# * slow - All commands that are not Fast.
1160 +
# * pubsub - PUBLISH / SUBSCRIBE related
1161 +
# * transaction - WATCH / MULTI / EXEC related commands.
1162 +
# * scripting - Scripting related.
1163 +
# * set - Data type: sets related.
1164 +
# * sortedset - Data type: zsets related.
1165 +
# * list - Data type: lists related.
1166 +
# * hash - Data type: hashes related.
1167 +
# * string - Data type: strings related.
1168 +
# * bitmap - Data type: bitmaps related.
1169 +
# * hyperloglog - Data type: hyperloglog related.
1170 +
# * geo - Data type: geo related.
1171 +
# * stream - Data type: streams related.
1172 +
#
1173 +
# For more information about ACL configuration please refer to
1174 +
# the Valkey web site at https://valkey.io/topics/acl
1175 +
1176 +
# ACL LOG
1177 +
#
1178 +
# The ACL Log tracks failed commands and authentication events associated
1179 +
# with ACLs. The ACL Log is useful to troubleshoot failed commands blocked
1180 +
# by ACLs. The ACL Log is stored in memory. You can reclaim memory with
1181 +
# ACL LOG RESET. Define the maximum entry length of the ACL Log below.
1182 +
acllog-max-len 128
1183 +
1184 +
# Using an external ACL file
1185 +
#
1186 +
# Instead of configuring users here in this file, it is possible to use
1187 +
# a stand-alone file just listing users. The two methods cannot be mixed:
1188 +
# if you configure users here and at the same time you activate the external
1189 +
# ACL file, the server will refuse to start.
1190 +
#
1191 +
# The format of the external ACL user file is exactly the same as the
1192 +
# format that is used inside valkey.conf to describe users.
1193 +
#
1194 +
# aclfile /etc/valkey/users.acl
1195 +
1196 +
# IMPORTANT NOTE: "requirepass" is just a compatibility
1197 +
# layer on top of the new ACL system. The option effect will be just setting
1198 +
# the password for the default user. Clients will still authenticate using
1199 +
# AUTH <password> as usually, or more explicitly with AUTH default <password>
1200 +
# if they follow the new protocol: both will work.
1201 +
#
1202 +
# The requirepass is not compatible with aclfile option and the ACL LOAD
1203 +
# command, these will cause requirepass to be ignored.
1204 +
#
1205 +
# requirepass foobared
1206 +
1207 +
# The default Pub/Sub channels permission for new users is controlled by the
1208 +
# acl-pubsub-default configuration directive, which accepts one of these values:
1209 +
#
1210 +
# allchannels: grants access to all Pub/Sub channels
1211 +
# resetchannels: revokes access to all Pub/Sub channels
1212 +
#
1213 +
# acl-pubsub-default defaults to 'resetchannels' permission.
1214 +
#
1215 +
# acl-pubsub-default resetchannels
1216 +
1217 +
# Command renaming (DEPRECATED).
1218 +
#
1219 +
# ------------------------------------------------------------------------
1220 +
# WARNING: avoid using this option if possible. Instead use ACLs to remove
1221 +
# commands from the default user, and put them only in some admin user you
1222 +
# create for administrative purposes.
1223 +
# ------------------------------------------------------------------------
1224 +
#
1225 +
# It is possible to change the name of dangerous commands in a shared
1226 +
# environment. For instance the CONFIG command may be renamed into something
1227 +
# hard to guess so that it will still be available for internal-use tools
1228 +
# but not available for general clients.
1229 +
#
1230 +
# Example:
1231 +
#
1232 +
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
1233 +
#
1234 +
# It is also possible to completely kill a command by renaming it into
1235 +
# an empty string:
1236 +
#
1237 +
# rename-command CONFIG ""
1238 +
#
1239 +
# Please note that changing the name of commands that are logged into the
1240 +
# AOF file or transmitted to replicas may cause problems.
1241 +
1242 +
################################### CLIENTS ####################################
1243 +
1244 +
# Set the max number of connected clients at the same time. By default
1245 +
# this limit is set to 10000 clients, however if the server is not
1246 +
# able to configure the process file limit to allow for the specified limit
1247 +
# the max number of allowed clients is set to the current file limit
1248 +
# minus 32 (as the server reserves a few file descriptors for internal uses).
1249 +
#
1250 +
# Once the limit is reached the server will close all the new connections sending
1251 +
# an error 'max number of clients reached'.
1252 +
#
1253 +
# IMPORTANT: With a cluster-enabled setup, the max number of connections is also
1254 +
# shared with the cluster bus: every node in the cluster will use two
1255 +
# connections, one incoming and another outgoing. It is important to size the
1256 +
# limit accordingly in case of very large clusters.
1257 +
#
1258 +
# maxclients 10000
1259 +
1260 +
############################## MEMORY MANAGEMENT ################################
1261 +
1262 +
# Set a memory usage limit to the specified amount of bytes.
1263 +
# When the memory limit is reached the server will try to remove keys
1264 +
# according to the eviction policy selected (see maxmemory-policy).
1265 +
#
1266 +
# If the server can't remove keys according to the policy, or if the policy is
1267 +
# set to 'noeviction', the server will start to reply with errors to commands
1268 +
# that would use more memory, like SET, LPUSH, and so on, and will continue
1269 +
# to reply to read-only commands like GET.
1270 +
#
1271 +
# This option is usually useful when using the server as an LRU or LFU cache, or to
1272 +
# set a hard memory limit for an instance (using the 'noeviction' policy).
1273 +
#
1274 +
# WARNING: If you have replicas attached to an instance with maxmemory on,
1275 +
# the size of the output buffers needed to feed the replicas are subtracted
1276 +
# from the used memory count, so that network problems / resyncs will
1277 +
# not trigger a loop where keys are evicted, and in turn the output
1278 +
# buffer of replicas is full with DELs of keys evicted triggering the deletion
1279 +
# of more keys, and so forth until the database is completely emptied.
1280 +
#
1281 +
# In short... if you have replicas attached it is suggested that you set a lower
1282 +
# limit for maxmemory so that there is some free RAM on the system for replica
1283 +
# output buffers (but this is not needed if the policy is 'noeviction').
1284 +
#
1285 +
# maxmemory <bytes>
1286 +
1287 +
# MAXMEMORY POLICY: how the server will select what to remove when maxmemory
1288 +
# is reached. You can select one from the following behaviors:
1289 +
#
1290 +
# volatile-lru -> Evict using approximated LRU, only keys with an expire set.
1291 +
# allkeys-lru -> Evict any key using approximated LRU.
1292 +
# volatile-lfu -> Evict using approximated LFU, only keys with an expire set.
1293 +
# allkeys-lfu -> Evict any key using approximated LFU.
1294 +
# volatile-random -> Remove a random key having an expire set.
1295 +
# allkeys-random -> Remove a random key, any key.
1296 +
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
1297 +
# noeviction -> Don't evict anything, just return an error on write operations.
1298 +
#
1299 +
# LRU means Least Recently Used
1300 +
# LFU means Least Frequently Used
1301 +
#
1302 +
# Both LRU, LFU and volatile-ttl are implemented using approximated
1303 +
# randomized algorithms.
1304 +
#
1305 +
# Note: with any of the above policies, when there are no suitable keys for
1306 +
# eviction, the server will return an error on write operations that require
1307 +
# more memory. These are usually commands that create new keys, add data or
1308 +
# modify existing keys. A few examples are: SET, INCR, HSET, LPUSH, SUNIONSTORE,
1309 +
# SORT (due to the STORE argument), and EXEC (if the transaction includes any
1310 +
# command that requires memory).
1311 +
#
1312 +
# The default is:
1313 +
#
1314 +
# maxmemory-policy noeviction
1315 +
1316 +
# LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated
1317 +
# algorithms (in order to save memory), so you can tune it for speed or
1318 +
# accuracy. By default the server will check five keys and pick the one that was
1319 +
# used least recently, you can change the sample size using the following
1320 +
# configuration directive.
1321 +
#
1322 +
# The default of 5 produces good enough results. 10 Approximates very closely
1323 +
# true LRU but costs more CPU. 3 is faster but not very accurate. The maximum
1324 +
# value that can be set is 64.
1325 +
#
1326 +
# maxmemory-samples 5
1327 +
1328 +
# Eviction processing is designed to function well with the default setting.
1329 +
# If there is an unusually large amount of write traffic, this value may need to
1330 +
# be increased. Decreasing this value may reduce latency at the risk of
1331 +
# eviction processing effectiveness
1332 +
# 0 = minimum latency, 10 = default, 100 = process without regard to latency
1333 +
#
1334 +
# maxmemory-eviction-tenacity 10
1335 +
1336 +
# By default a replica will ignore its maxmemory setting
1337 +
# (unless it is promoted to primary after a failover or manually). It means
1338 +
# that the eviction of keys will be just handled by the primary, sending the
1339 +
# DEL commands to the replica as keys evict in the primary side.
1340 +
#
1341 +
# This behavior ensures that primaries and replicas stay consistent, and is usually
1342 +
# what you want, however if your replica is writable, or you want the replica
1343 +
# to have a different memory setting, and you are sure all the writes performed
1344 +
# to the replica are idempotent, then you may change this default (but be sure
1345 +
# to understand what you are doing).
1346 +
#
1347 +
# Note that since the replica by default does not evict, it may end using more
1348 +
# memory than the one set via maxmemory (there are certain buffers that may
1349 +
# be larger on the replica, or data structures may sometimes take more memory
1350 +
# and so forth). So make sure you monitor your replicas and make sure they
1351 +
# have enough memory to never hit a real out-of-memory condition before the
1352 +
# primary hits the configured maxmemory setting.
1353 +
#
1354 +
# replica-ignore-maxmemory yes
1355 +
1356 +
# The server reclaims expired keys in two ways: upon access when those keys are
1357 +
# found to be expired, and also in the background, in what is called the
1358 +
# "active expire key". The key space is slowly and incrementally scanned
1359 +
# looking for expired keys to reclaim, so that it is possible to free memory
1360 +
# of keys that are expired and will never be accessed again in a short time.
1361 +
#
1362 +
# The default effort of the expire cycle will try to avoid having more than
1363 +
# ten percent of expired keys still in memory, and will try to avoid consuming
1364 +
# more than 25% of total memory and to add latency to the system. However
1365 +
# it is possible to increase the expire "effort" that is normally set to
1366 +
# "1", to a greater value, up to the value "10". At its maximum value the
1367 +
# system will use more CPU, longer cycles (and technically may introduce
1368 +
# more latency), and will tolerate less already expired keys still present
1369 +
# in the system. It's a tradeoff between memory, CPU and latency.
1370 +
#
1371 +
# active-expire-effort 1
1372 +
1373 +
############################# LAZY FREEING ####################################
1374 +
1375 +
# When keys are deleted, the served has historically freed their memory using
1376 +
# blocking operations. It means that the server stopped processing new commands
1377 +
# in order to reclaim all the memory associated with an object in a synchronous
1378 +
# way. If the key deleted is associated with a small object, the time needed
1379 +
# in order to execute the DEL command is very small and comparable to most other
1380 +
# O(1) or O(log_N) commands in the server. However if the key is associated with an
1381 +
# aggregated value containing millions of elements, the server can block for
1382 +
# a long time (even seconds) in order to complete the operation.
1383 +
#
1384 +
# For the above reasons, lazy freeing (or asynchronous freeing), has been
1385 +
# introduced. With lazy freeing, keys are deleted in constant time. Another
1386 +
# thread will incrementally free the object in the background as fast as
1387 +
# possible.
1388 +
#
1389 +
# Starting from Valkey 8.0, lazy freeing is enabled by default. It is possible
1390 +
# to retain the synchronous freeing behaviour by setting the lazyfree related
1391 +
# configuration directives to 'no'.
1392 +
1393 +
# Commands like DEL, FLUSHALL and FLUSHDB delete keys, but the server can also
1394 +
# delete keys or flush the whole database as a side effect of other operations.
1395 +
# Specifically the server deletes objects independently of a user call in the
1396 +
# following scenarios:
1397 +
#
1398 +
# 1) On eviction, because of the maxmemory and maxmemory policy configurations,
1399 +
# in order to make room for new data, without going over the specified
1400 +
# memory limit.
1401 +
# 2) Because of expire: when a key with an associated time to live (see the
1402 +
# EXPIRE command) must be deleted from memory.
1403 +
# 3) Because of a side effect of a command that stores data on a key that may
1404 +
# already exist. For example the RENAME command may delete the old key
1405 +
# content when it is replaced with another one. Similarly SUNIONSTORE
1406 +
# or SORT with STORE option may delete existing keys. The SET command
1407 +
# itself removes any old content of the specified key in order to replace
1408 +
# it with the specified string.
1409 +
# 4) During replication, when a replica performs a full resynchronization with
1410 +
# its primary, the content of the whole database is removed in order to
1411 +
# load the RDB file just transferred.
1412 +
#
1413 +
# In all the above cases, the default is to release memory in a non-blocking
1414 +
# way.
1415 +
1416 +
lazyfree-lazy-eviction yes
1417 +
lazyfree-lazy-expire yes
1418 +
lazyfree-lazy-server-del yes
1419 +
replica-lazy-flush yes
1420 +
1421 +
# For keys deleted using the DEL command, lazy freeing is controlled by the
1422 +
# configuration directive 'lazyfree-lazy-user-del'. The default is 'yes'. The
1423 +
# UNLINK command is identical to the DEL command, except that UNLINK always
1424 +
# frees the memory lazily, regardless of this configuration directive:
1425 +
1426 +
lazyfree-lazy-user-del yes
1427 +
1428 +
# FLUSHDB, FLUSHALL, SCRIPT FLUSH and FUNCTION FLUSH support both asynchronous and synchronous
1429 +
# deletion, which can be controlled by passing the [SYNC|ASYNC] flags into the
1430 +
# commands. When neither flag is passed, this directive will be used to determine
1431 +
# if the data should be deleted asynchronously.
1432 +
#
1433 +
# When a replica performs a node reset via CLUSTER RESET, the entire
1434 +
# database content is removed to allow the node to become an empty primary.
1435 +
# This directive also determines whether the data should be deleted asynchronously.
1436 +
#
1437 +
# There are many problems with running flush synchronously. Even in single CPU
1438 +
# environments, the thread managers should balance between the freeing and
1439 +
# serving incoming requests. The default value is yes.
1440 +
1441 +
lazyfree-lazy-user-flush yes
1442 +
1443 +
################################ THREADED I/O #################################
1444 +
1445 +
# The server is mostly single threaded, however there are certain threaded
1446 +
# operations such as UNLINK, slow I/O accesses and other things that are
1447 +
# performed on side threads.
1448 +
#
1449 +
# Now it is also possible to handle the server clients socket reads and writes
1450 +
# in different I/O threads. Since especially writing is so slow, normally
1451 +
# users use pipelining in order to speed up the server performances per
1452 +
# core, and spawn multiple instances in order to scale more. Using I/O
1453 +
# threads it is possible to easily speedup two times the server without resorting
1454 +
# to pipelining nor sharding of the instance.
1455 +
#
1456 +
# By default threading is disabled, we suggest enabling it only in machines
1457 +
# that have at least 3 or more cores, leaving at least one spare core.
1458 +
# We also recommend using threaded I/O only if you actually have performance problems, with
1459 +
# instances being able to use a quite big percentage of CPU time, otherwise
1460 +
# there is no point in using this feature.
1461 +
#
1462 +
# So for instance if you have a four cores boxes, try to use 2 or 3 I/O
1463 +
# threads, if you have a 8 cores, try to use 6 threads. In order to
1464 +
# enable I/O threads use the following configuration directive:
1465 +
#
1466 +
# io-threads 4
1467 +
#
1468 +
# Setting io-threads to 1 will just use the main thread as usual.
1469 +
# When I/O threads are enabled, we use threads for reads and writes, that is
1470 +
# to thread the write and read syscall and transfer the client buffers to the
1471 +
# socket and to enable threading of reads and protocol parsing.
1472 +
#
1473 +
#
1474 +
# NOTE:
1475 +
# 1. The 'io-threads-do-reads' config is deprecated and has no effect. Please
1476 +
# avoid using this config if possible.
1477 +
#
1478 +
# 2. If you want to test the server speedup using valkey-benchmark, make
1479 +
# sure you also run the benchmark itself in threaded mode, using the
1480 +
# --threads option to match the number of server threads, otherwise you'll not
1481 +
# be able to notice the improvements.
1482 +
1483 +
############################ KERNEL OOM CONTROL ##############################
1484 +
1485 +
# On Linux, it is possible to hint the kernel OOM killer on what processes
1486 +
# should be killed first when out of memory.
1487 +
#
1488 +
# Enabling this feature makes the server actively control the oom_score_adj value
1489 +
# for all its processes, depending on their role. The default scores will
1490 +
# attempt to have background child processes killed before all others, and
1491 +
# replicas killed before primaries.
1492 +
#
1493 +
# The server supports these options:
1494 +
#
1495 +
# no: Don't make changes to oom-score-adj (default).
1496 +
# yes: Alias to "relative" see below.
1497 +
# absolute: Values in oom-score-adj-values are written as is to the kernel.
1498 +
# relative: Values are used relative to the initial value of oom_score_adj when
1499 +
# the server starts and are then clamped to a range of -1000 to 1000.
1500 +
# Because typically the initial value is 0, they will often match the
1501 +
# absolute values.
1502 +
oom-score-adj no
1503 +
1504 +
# When oom-score-adj is used, this directive controls the specific values used
1505 +
# for primary, replica and background child processes. Values range -2000 to
1506 +
# 2000 (higher means more likely to be killed).
1507 +
#
1508 +
# Unprivileged processes (not root, and without CAP_SYS_RESOURCE capabilities)
1509 +
# can freely increase their value, but not decrease it below its initial
1510 +
# settings. This means that setting oom-score-adj to "relative" and setting the
1511 +
# oom-score-adj-values to positive values will always succeed.
1512 +
oom-score-adj-values 0 200 800
1513 +
1514 +
1515 +
#################### KERNEL transparent hugepage CONTROL ######################
1516 +
1517 +
# Usually the kernel Transparent Huge Pages control is set to "madvise" or
1518 +
# "never" by default (/sys/kernel/mm/transparent_hugepage/enabled), in which
1519 +
# case this config has no effect. On systems in which it is set to "always",
1520 +
# the server will attempt to disable it specifically for the server process in order
1521 +
# to avoid latency problems specifically with fork(2) and CoW.
1522 +
# If for some reason you prefer to keep it enabled, you can set this config to
1523 +
# "no" and the kernel global to "always".
1524 +
1525 +
disable-thp yes
1526 +
1527 +
############################## APPEND ONLY MODE ###############################
1528 +
1529 +
# By default the server asynchronously dumps the dataset on disk. This mode is
1530 +
# good enough in many applications, but an issue with the server process or
1531 +
# a power outage may result into a few minutes of writes lost (depending on
1532 +
# the configured save points).
1533 +
#
1534 +
# The Append Only File is an alternative persistence mode that provides
1535 +
# much better durability. For instance using the default data fsync policy
1536 +
# (see later in the config file) the server can lose just one second of writes in a
1537 +
# dramatic event like a server power outage, or a single write if something
1538 +
# wrong with the process itself happens, but the operating system is
1539 +
# still running correctly.
1540 +
#
1541 +
# AOF and RDB persistence can be enabled at the same time without problems.
1542 +
# If the AOF is enabled on startup the server will load the AOF, that is the file
1543 +
# with the better durability guarantees.
1544 +
#
1545 +
# Note that changing this value in a config file of an existing database and
1546 +
# restarting the server can lead to data loss. A conversion needs to be done
1547 +
# by setting it via CONFIG command on a live server first.
1548 +
#
1549 +
# Please check https://valkey.io/topics/persistence for more information.
1550 +
1551 +
appendonly no
1552 +
1553 +
# The base name of the append only file.
1554 +
#
1555 +
# The server uses a set of append-only files to persist the dataset
1556 +
# and changes applied to it. There are two basic types of files in use:
1557 +
#
1558 +
# - Base files, which are a snapshot representing the complete state of the
1559 +
# dataset at the time the file was created. Base files can be either in
1560 +
# the form of RDB (binary serialized) or AOF (textual commands).
1561 +
# - Incremental files, which contain additional commands that were applied
1562 +
# to the dataset following the previous file.
1563 +
#
1564 +
# In addition, manifest files are used to track the files and the order in
1565 +
# which they were created and should be applied.
1566 +
#
1567 +
# Append-only file names are created by the server following a specific pattern.
1568 +
# The file name's prefix is based on the 'appendfilename' configuration
1569 +
# parameter, followed by additional information about the sequence and type.
1570 +
#
1571 +
# For example, if appendfilename is set to appendonly.aof, the following file
1572 +
# names could be derived:
1573 +
#
1574 +
# - appendonly.aof.1.base.rdb as a base file.
1575 +
# - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
1576 +
# - appendonly.aof.manifest as a manifest file.
1577 +
1578 +
appendfilename "appendonly.aof"
1579 +
1580 +
# For convenience, the server stores all persistent append-only files in a dedicated
1581 +
# directory. The name of the directory is determined by the appenddirname
1582 +
# configuration parameter.
1583 +
1584 +
appenddirname "appendonlydir"
1585 +
1586 +
# The fsync() call tells the Operating System to actually write data on disk
1587 +
# instead of waiting for more data in the output buffer. Some OS will really flush
1588 +
# data on disk, some other OS will just try to do it ASAP.
1589 +
#
1590 +
# The server supports three different modes:
1591 +
#
1592 +
# no: don't fsync, just let the OS flush the data when it wants. Faster.
1593 +
# always: fsync after every write to the append only log. Slow, Safest.
1594 +
# everysec: fsync only one time every second. Compromise.
1595 +
#
1596 +
# The default is "everysec", as that's usually the right compromise between
1597 +
# speed and data safety. It's up to you to understand if you can relax this to
1598 +
# "no" that will let the operating system flush the output buffer when
1599 +
# it wants, for better performances (but if you can live with the idea of
1600 +
# some data loss consider the default persistence mode that's snapshotting),
1601 +
# or on the contrary, use "always" that's very slow but a bit safer than
1602 +
# everysec.
1603 +
#
1604 +
# More details please check the following article:
1605 +
# http://antirez.com/post/redis-persistence-demystified.html
1606 +
#
1607 +
# If unsure, use "everysec".
1608 +
1609 +
# appendfsync always
1610 +
appendfsync everysec
1611 +
# appendfsync no
1612 +
1613 +
# When the AOF fsync policy is set to always or everysec, and a background
1614 +
# saving process (a background save or AOF log background rewriting) is
1615 +
# performing a lot of I/O against the disk, in some Linux configurations
1616 +
# the server may block too long on the fsync() call. Note that there is no fix for
1617 +
# this currently, as even performing fsync in a different thread will block
1618 +
# our synchronous write(2) call.
1619 +
#
1620 +
# In order to mitigate this problem it's possible to use the following option
1621 +
# that will prevent fsync() from being called in the main process while a
1622 +
# BGSAVE or BGREWRITEAOF is in progress.
1623 +
#
1624 +
# This means that while another child is saving, the durability of the server is
1625 +
# the same as "appendfsync no". In practical terms, this means that it is
1626 +
# possible to lose up to 30 seconds of log in the worst scenario (with the
1627 +
# default Linux settings).
1628 +
#
1629 +
# If you have latency problems turn this to "yes". Otherwise leave it as
1630 +
# "no" that is the safest pick from the point of view of durability.
1631 +
1632 +
no-appendfsync-on-rewrite no
1633 +
1634 +
# Automatic rewrite of the append only file.
1635 +
# The server is able to automatically rewrite the log file implicitly calling
1636 +
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
1637 +
#
1638 +
# This is how it works: The server remembers the size of the AOF file after the
1639 +
# latest rewrite (if no rewrite has happened since the restart, the size of
1640 +
# the AOF at startup is used).
1641 +
#
1642 +
# This base size is compared to the current size. If the current size is
1643 +
# bigger than the specified percentage, the rewrite is triggered. Also
1644 +
# you need to specify a minimal size for the AOF file to be rewritten, this
1645 +
# is useful to avoid rewriting the AOF file even if the percentage increase
1646 +
# is reached but it is still pretty small.
1647 +
#
1648 +
# Specify a percentage of zero in order to disable the automatic AOF
1649 +
# rewrite feature.
1650 +
1651 +
auto-aof-rewrite-percentage 100
1652 +
auto-aof-rewrite-min-size 64mb
1653 +
1654 +
# An AOF file may be found to be truncated at the end during the server
1655 +
# startup process, when the AOF data gets loaded back into memory.
1656 +
# This may happen when the system where the server is running
1657 +
# crashes, especially when an ext4 filesystem is mounted without the
1658 +
# data=ordered option (however this can't happen when the server itself
1659 +
# crashes or aborts but the operating system still works correctly).
1660 +
#
1661 +
# The server can either exit with an error when this happens, or load as much
1662 +
# data as possible (the default now) and start if the AOF file is found
1663 +
# to be truncated at the end. The following option controls this behavior.
1664 +
#
1665 +
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
1666 +
# the server starts emitting a log to inform the user of the event.
1667 +
# Otherwise if the option is set to no, the server aborts with an error
1668 +
# and refuses to start. When the option is set to no, the user requires
1669 +
# to fix the AOF file using the "valkey-check-aof" utility before to restart
1670 +
# the server.
1671 +
#
1672 +
# Note that if the AOF file will be found to be corrupted in the middle
1673 +
# the server will still exit with an error. This option only applies when
1674 +
# the server will try to read more data from the AOF file but not enough bytes
1675 +
# will be found.
1676 +
aof-load-truncated yes
1677 +
1678 +
# The server can create append-only base files in either RDB or AOF formats. Using
1679 +
# the RDB format is always faster and more efficient, and disabling it is only
1680 +
# supported for backward compatibility purposes.
1681 +
aof-use-rdb-preamble yes
1682 +
1683 +
# The server supports recording timestamp annotations in the AOF to support restoring
1684 +
# the data from a specific point-in-time. However, using this capability changes
1685 +
# the AOF format in a way that may not be compatible with existing AOF parsers.
1686 +
aof-timestamp-enabled no
1687 +
1688 +
################################ SHUTDOWN #####################################
1689 +
1690 +
# Maximum time to wait for replicas when shutting down, in seconds.
1691 +
#
1692 +
# During shut down, a grace period allows any lagging replicas to catch up with
1693 +
# the latest replication offset before the primary exits. This period can
1694 +
# prevent data loss, especially for deployments without configured disk backups.
1695 +
#
1696 +
# The 'shutdown-timeout' value is the grace period's duration in seconds. It is
1697 +
# only applicable when the instance has replicas. To disable the feature, set
1698 +
# the value to 0.
1699 +
#
1700 +
# shutdown-timeout 10
1701 +
1702 +
# When the server receives a SIGINT or SIGTERM, shutdown is initiated and by default
1703 +
# an RDB snapshot is written to disk in a blocking operation if save points are configured.
1704 +
# The options used on signaled shutdown can include the following values:
1705 +
#
1706 +
# default: Saves RDB snapshot only if save points are configured.
1707 +
# Waits for lagging replicas to catch up.
1708 +
# save: Forces a DB saving operation even if no save points are configured.
1709 +
# nosave: Prevents DB saving operation even if one or more save points are configured.
1710 +
# now: Skips waiting for lagging replicas.
1711 +
# force: Ignores any errors that would normally prevent the server from exiting.
1712 +
# safe: Shut down only when safe. Note that safe cannot prevent force, in the case of
1713 +
# force, safe will print the relevant logs. The definition of safe may be different
1714 +
# in different modes. Here are the definitions:
1715 +
# * In cluster mode, it is unsafe to shut down a primary with slots, and may cause
1716 +
# the cluster to go down.
1717 +
# failover: In cluster mode, when shutting down a primary, it can proactively
1718 +
# initiate a manual failover. This promotes one of its replicas to
1719 +
# primary before shutdown, resulting in a quicker and safer transition
1720 +
# than relying on an automatic failover. For a replica to be eligible
1721 +
# for this promotion, it must be fully synchronized with the primary
1722 +
# node at the time of the shutdown signal after waiting up to the
1723 +
# configured shutdown-timeout. If no such replica is found, this
1724 +
# proactive failover will not occur.
1725 +
#
1726 +
# Any combination of values is allowed as long as "save" and "nosave" are not set simultaneously.
1727 +
# Example: "nosave force now"
1728 +
#
1729 +
# shutdown-on-sigint default
1730 +
# shutdown-on-sigterm default
1731 +
1732 +
################ NON-DETERMINISTIC LONG BLOCKING COMMANDS #####################
1733 +
1734 +
# Maximum time in milliseconds for EVAL scripts, functions and in some cases
1735 +
# modules' commands before the server can start processing or rejecting other clients.
1736 +
#
1737 +
# If the maximum execution time is reached the server will start to reply to most
1738 +
# commands with a BUSY error.
1739 +
#
1740 +
# In this state the server will only allow a handful of commands to be executed.
1741 +
# For instance, SCRIPT KILL, FUNCTION KILL, SHUTDOWN NOSAVE and possibly some
1742 +
# module specific 'allow-busy' commands.
1743 +
#
1744 +
# SCRIPT KILL and FUNCTION KILL will only be able to stop a script that did not
1745 +
# yet call any write commands, so SHUTDOWN NOSAVE may be the only way to stop
1746 +
# the server in the case a write command was already issued by the script when
1747 +
# the user doesn't want to wait for the natural termination of the script.
1748 +
#
1749 +
# The default is 5 seconds. It is possible to set it to 0 or a negative value
1750 +
# to disable this mechanism (uninterrupted execution). Note that in the past
1751 +
# this config had a different name, which is now an alias, so both of these do
1752 +
# the same:
1753 +
# lua-time-limit 5000
1754 +
# busy-reply-threshold 5000
1755 +
1756 +
################################ VALKEY CLUSTER ###############################
1757 +
1758 +
# Normal server instances can't be part of a cluster; only nodes that are
1759 +
# started as cluster nodes can. In order to start a server instance as a
1760 +
# cluster node enable the cluster support uncommenting the following:
1761 +
#
1762 +
# cluster-enabled yes
1763 +
1764 +
# Every cluster node has a cluster configuration file. This file is not
1765 +
# intended to be edited by hand. It is created and updated by each node.
1766 +
# Every cluster node requires a different cluster configuration file.
1767 +
# Make sure that instances running in the same system do not have
1768 +
# overlapping cluster configuration file names.
1769 +
#
1770 +
# cluster-config-file nodes-6379.conf
1771 +
1772 +
# Cluster node timeout is the amount of milliseconds a node must be unreachable
1773 +
# for it to be considered in failure state.
1774 +
# Most other internal time limits are a multiple of the node timeout.
1775 +
#
1776 +
# cluster-node-timeout 15000
1777 +
1778 +
# The cluster port is the port that the cluster bus will listen for inbound connections on. When set
1779 +
# to the default value, 0, it will be bound to the command port + 10000. Setting this value requires
1780 +
# you to specify the cluster bus port when executing cluster meet.
1781 +
# cluster-port 0
1782 +
1783 +
# A replica of a failing primary will avoid to start a failover if its data
1784 +
# looks too old.
1785 +
#
1786 +
# There is no simple way for a replica to actually have an exact measure of
1787 +
# its "data age", so the following two checks are performed:
1788 +
#
1789 +
# 1) If there are multiple replicas able to failover, they exchange messages
1790 +
# in order to try to give an advantage to the replica with the best
1791 +
# replication offset (more data from the primary processed).
1792 +
# Replicas will try to get their rank by offset, and apply to the start
1793 +
# of the failover a delay proportional to their rank.
1794 +
#
1795 +
# 2) Every single replica computes the time of the last interaction with
1796 +
# its primary. This can be the last ping or command received (if the primary
1797 +
# is still in the "connected" state), or the time that elapsed since the
1798 +
# disconnection with the primary (if the replication link is currently down).
1799 +
# If the last interaction is too old, the replica will not try to failover
1800 +
# at all.
1801 +
#
1802 +
# The point "2" can be tuned by user. Specifically a replica will not perform
1803 +
# the failover if, since the last interaction with the primary, the time
1804 +
# elapsed is greater than:
1805 +
#
1806 +
# (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period
1807 +
#
1808 +
# So for example if node-timeout is 30 seconds, and the cluster-replica-validity-factor
1809 +
# is 10, and assuming a default repl-ping-replica-period of 10 seconds, the
1810 +
# replica will not try to failover if it was not able to talk with the primary
1811 +
# for longer than 310 seconds.
1812 +
#
1813 +
# A large cluster-replica-validity-factor may allow replicas with too old data to failover
1814 +
# a primary, while a too small value may prevent the cluster from being able to
1815 +
# elect a replica at all.
1816 +
#
1817 +
# For maximum availability, it is possible to set the cluster-replica-validity-factor
1818 +
# to a value of 0, which means, that replicas will always try to failover the
1819 +
# primary regardless of the last time they interacted with the primary.
1820 +
# (However they'll always try to apply a delay proportional to their
1821 +
# offset rank).
1822 +
#
1823 +
# Zero is the only value able to guarantee that when all the partitions heal
1824 +
# the cluster will always be able to continue.
1825 +
#
1826 +
# cluster-replica-validity-factor 10
1827 +
1828 +
# Cluster replicas are able to migrate to orphaned primaries, that are primaries
1829 +
# that are left without working replicas. This improves the cluster ability
1830 +
# to resist to failures as otherwise an orphaned primary can't be failed over
1831 +
# in case of failure if it has no working replicas.
1832 +
#
1833 +
# Replicas migrate to orphaned primaries only if there are still at least a
1834 +
# given number of other working replicas for their old primary. This number
1835 +
# is the "migration barrier". A migration barrier of 1 means that a replica
1836 +
# will migrate only if there is at least 1 other working replica for its primary
1837 +
# and so forth. It usually reflects the number of replicas you want for every
1838 +
# primary in your cluster.
1839 +
#
1840 +
# Default is 1 (replicas migrate only if their primaries remain with at least
1841 +
# one replica). To disable migration just set it to a very large value or
1842 +
# set cluster-allow-replica-migration to 'no'.
1843 +
# A value of 0 can be set but is useful only for debugging and dangerous
1844 +
# in production.
1845 +
#
1846 +
# cluster-migration-barrier 1
1847 +
1848 +
# Turning off this option allows to use less automatic cluster configuration.
1849 +
# It disables migration of replicas to orphaned primaries. Masters that become
1850 +
# empty due to losing their last slots to another primary will not automatically
1851 +
# replicate from the primary that took over their last slots. Instead, they will
1852 +
# remain as empty primaries without any slots.
1853 +
#
1854 +
# Default is 'yes' (allow automatic migrations).
1855 +
#
1856 +
# cluster-allow-replica-migration yes
1857 +
1858 +
# By default cluster nodes stop accepting queries if they detect there
1859 +
# is at least a hash slot uncovered (no available node is serving it).
1860 +
# This way if the cluster is partially down (for example a range of hash slots
1861 +
# are no longer covered) all the cluster becomes, eventually, unavailable.
1862 +
# It automatically returns available as soon as all the slots are covered again.
1863 +
#
1864 +
# However sometimes you want the subset of the cluster which is working,
1865 +
# to continue to accept queries for the part of the key space that is still
1866 +
# covered. In order to do so, just set the cluster-require-full-coverage
1867 +
# option to no.
1868 +
#
1869 +
# cluster-require-full-coverage yes
1870 +
1871 +
# This option, when set to yes, prevents replicas from trying to failover its
1872 +
# primary during primary failures. However the replica can still perform a
1873 +
# manual failover, if forced to do so.
1874 +
#
1875 +
# This is useful in different scenarios, especially in the case of multiple
1876 +
# data center operations, where we want one side to never be promoted if not
1877 +
# in the case of a total DC failure.
1878 +
#
1879 +
# cluster-replica-no-failover no
1880 +
1881 +
# The timeout in milliseconds for cluster manual failover. If a manual failover
1882 +
# does not complete within the specified time, both the replica and the primary
1883 +
# will abort it. Note that this timeout is also used for the finalization of
1884 +
# migrations initiated with the CLUSTER MIGRATESLOTS command.
1885 +
#
1886 +
# A manual failover is a special kind of failover that is usually executed when
1887 +
# there are no actual failures, and we wish to swap the current primary with one
1888 +
# of its replicas in a safe way, without any window for data loss.
1889 +
#
1890 +
# To avoid data loss, the primary and the replica need to wait for each other for
1891 +
# a period of time, the primary need to pause the clients writes to stop processing
1892 +
# traffic. The default failover timeout is 5000ms, it is possible to configure the
1893 +
# timeout and decide how long the primary will pause in the worst case scenario,
1894 +
# i.e. the manual failover timed out due to the insufficient votes.
1895 +
#
1896 +
# Check https://valkey.io/commands/cluster-failover/ for more information.
1897 +
#
1898 +
# cluster-manual-failover-timeout 5000
1899 +
1900 +
# This option, when set to yes, allows nodes to serve read traffic while the
1901 +
# cluster is in a down state, as long as it believes it owns the slots.
1902 +
#
1903 +
# This is useful for two cases. The first case is for when an application
1904 +
# doesn't require consistency of data during node failures or network partitions.
1905 +
# One example of this is a cache, where as long as the node has the data it
1906 +
# should be able to serve it.
1907 +
#
1908 +
# The second use case is for configurations that don't meet the recommended
1909 +
# three shards but want to enable cluster mode and scale later. A
1910 +
# primary outage in a 1 or 2 shard configuration causes a read/write outage to the
1911 +
# entire cluster without this option set, with it set there is only a write outage.
1912 +
# Without a quorum of primaries, slot ownership will not change automatically.
1913 +
#
1914 +
# cluster-allow-reads-when-down no
1915 +
1916 +
# This option, when set to yes, allows nodes to serve pubsub shard traffic while
1917 +
# the cluster is in a down state, as long as it believes it owns the slots.
1918 +
#
1919 +
# This is useful if the application would like to use the pubsub feature even when
1920 +
# the cluster global stable state is not OK. If the application wants to make sure only
1921 +
# one shard is serving a given channel, this feature should be kept as yes.
1922 +
#
1923 +
# cluster-allow-pubsubshard-when-down yes
1924 +
1925 +
# Cluster link send buffer limit is the limit on the memory usage of an individual
1926 +
# cluster bus link's send buffer in bytes. Cluster links would be freed if they exceed
1927 +
# this limit. This is to primarily prevent send buffers from growing unbounded on links
1928 +
# toward slow peers (E.g. PubSub messages being piled up).
1929 +
# This limit is disabled by default. Enable this limit when 'mem_cluster_links' INFO field
1930 +
# and/or 'send-buffer-allocated' entries in the 'CLUSTER LINKS` command output continuously increase.
1931 +
# Minimum limit of 1gb is recommended so that cluster link buffer can fit in at least a single
1932 +
# PubSub message by default. (client-query-buffer-limit default value is 1gb)
1933 +
#
1934 +
# cluster-link-sendbuf-limit 0
1935 +
1936 +
# Clusters can configure their announced hostname using this config. This is a common use case for
1937 +
# applications that need to use TLS Server Name Indication (SNI) or dealing with DNS based
1938 +
# routing. By default this value is only shown as additional metadata in the CLUSTER SLOTS
1939 +
# command, but can be changed using 'cluster-preferred-endpoint-type' config. This value is
1940 +
# communicated along the clusterbus to all nodes, setting it to an empty string will remove
1941 +
# the hostname and also propagate the removal.
1942 +
#
1943 +
# cluster-announce-hostname ""
1944 +
1945 +
# Clusters can configure an optional nodename to be used in addition to the node ID for
1946 +
# debugging and admin information. This name is broadcasted between nodes, so will be used
1947 +
# in addition to the node ID when reporting cross node events such as node failures.
1948 +
# cluster-announce-human-nodename ""
1949 +
1950 +
# Clusters can advertise how clients should connect to them using either their IP address,
1951 +
# a user defined hostname, or by declaring they have no endpoint. Which endpoint is
1952 +
# shown as the preferred endpoint is set by using the cluster-preferred-endpoint-type
1953 +
# config with values 'ip', 'hostname', or 'unknown-endpoint'. This value controls how
1954 +
# the endpoint returned for MOVED/ASKING requests as well as the first field of CLUSTER SLOTS.
1955 +
# If the preferred endpoint type is set to hostname, but no announced hostname is set, a '?'
1956 +
# will be returned instead.
1957 +
#
1958 +
# When a cluster advertises itself as having an unknown endpoint, it's indicating that
1959 +
# the server doesn't know how clients can reach the cluster. This can happen in certain
1960 +
# networking situations where there are multiple possible routes to the node, and the
1961 +
# server doesn't know which one the client took. In this case, the server is expecting
1962 +
# the client to reach out on the same endpoint it used for making the last request, but use
1963 +
# the port provided in the response.
1964 +
#
1965 +
# cluster-preferred-endpoint-type ip
1966 +
1967 +
# The cluster blacklist is used when removing a node from the cluster completely.
1968 +
# When CLUSTER FORGET is called for a node, that node is put into the blacklist for
1969 +
# some time so that when gossip messages are received from other nodes that still
1970 +
# remember it, it is not re-added. This gives time for CLUSTER FORGET to be sent to
1971 +
# every node in the cluster. The blacklist TTL is 60 seconds by default, which should
1972 +
# be sufficient for most clusters, but you may considering increasing this if you see
1973 +
# nodes getting re-added while using CLUSTER FORGET.
1974 +
#
1975 +
# cluster-blacklist-ttl 60
1976 +
1977 +
# Clusters can be configured to track per-slot resource statistics,
1978 +
# which are accessible by the CLUSTER SLOT-STATS command.
1979 +
#
1980 +
# By default, the 'cluster-slot-stats-enabled' is disabled, and only 'key-count' is captured.
1981 +
# By enabling the 'cluster-slot-stats-enabled' config, the cluster will begin to capture advanced statistics.
1982 +
# These statistics can be leveraged to assess general slot usage trends, identify hot / cold slots,
1983 +
# migrate slots for a balanced cluster workload, and / or re-write application logic to better utilize slots.
1984 +
#
1985 +
# cluster-slot-stats-enabled no
1986 +
1987 +
# Slot migrations using the CLUSTER MIGRATESLOTS command will generate an in-memory migration log on both
1988 +
# the source and target nodes of the migration. These can be observed with CLUSTER GETSLOTMIGRATIONS.
1989 +
# 'cluster-slot-migration-log-max-len' allows the maximum length of this log to be specified. Only
1990 +
# migrations that are completed will be considered for removal.
1991 +
#
1992 +
# cluster-slot-migration-log-max-len 1000
1993 +
1994 +
# During the CLUSTER MIGRATESLOTS command execution, the source node needs to pause itself and allow all
1995 +
# writes to be fully processed by the target node. The amount of data remaining in the buffer on the
1996 +
# source node when this pause happens will affect how long this pause takes.
1997 +
# 'slot-migration-max-failover-repl-bytes' allows the pause to wait until there are at most this
1998 +
# many bytes in the output buffer. Setting this to -1 will disable this limit, and 0 will require
1999 +
# no data be in the source output buffer (although this is not a guaranatee the data is fully
2000 +
# received by the target).
2001 +
#
2002 +
# slot-migration-max-failover-repl-bytes 0
2003 +
2004 +
# In order to setup your cluster make sure to read the documentation
2005 +
# available at https://valkey.io web site.
2006 +
2007 +
########################## CLUSTER DOCKER/NAT support ########################
2008 +
2009 +
# In certain deployments, cluster node's address discovery fails, because
2010 +
# addresses are NAT-ted or because ports are forwarded (the typical case is
2011 +
# Docker and other containers).
2012 +
#
2013 +
# In order to make a cluster work in such environments, a static
2014 +
# configuration where each node knows its public address is needed. The
2015 +
# following options are used for this scope, and are:
2016 +
#
2017 +
# * cluster-announce-ip
2018 +
# * cluster-announce-client-ipv4
2019 +
# * cluster-announce-client-ipv6
2020 +
# * cluster-announce-port
2021 +
# * cluster-announce-tls-port
2022 +
# * cluster-announce-bus-port
2023 +
# * cluster-announce-client-port
2024 +
# * cluster-announce-client-tls-port
2025 +
#
2026 +
# Each instructs the node about its address, possibly other addresses to expose
2027 +
# to clients, client ports (for connections without and with TLS) and cluster
2028 +
# message bus port. The information is then published in the bus packets so that
2029 +
# other nodes will be able to correctly map the address of the node publishing
2030 +
# the information.
2031 +
#
2032 +
# If tls-cluster is set to yes and cluster-announce-tls-port is omitted or set
2033 +
# to zero, then cluster-announce-port refers to the TLS port. Note also that
2034 +
# cluster-announce-tls-port has no effect if tls-cluster is set to no.
2035 +
#
2036 +
# If cluster-announce-client-ipv4 and cluster-announce-client-ipv6 are omitted,
2037 +
# then cluster-announce-ip is exposed to clients.
2038 +
#
2039 +
# If the port that clients will use to connect to Valkey is different than
2040 +
# the one other valkey nodes in the cluster will connect to it on, either
2041 +
# through special networking rules or because Valkey is behind a load balancer,
2042 +
# you can configure the port that clients will see by setting
2043 +
# cluster-announce-client-port or cluster-announce-client-tls-port.
2044 +
#
2045 +
# If the above options are not used, the normal cluster auto-detection
2046 +
# will be used instead.
2047 +
#
2048 +
# Note that when remapped, the bus port may not be at the fixed offset of
2049 +
# clients port + 10000, so you can specify any port and bus-port depending
2050 +
# on how they get remapped. If the bus-port is not set, a fixed offset of
2051 +
# 10000 will be used as usual.
2052 +
#
2053 +
# Example:
2054 +
#
2055 +
# cluster-announce-ip 10.1.1.5
2056 +
# cluster-announce-client-ipv4 123.123.123.5
2057 +
# cluster-announce-client-ipv6 2001:db8::8a2e:370:7334
2058 +
# cluster-announce-tls-port 6379
2059 +
# cluster-announce-port 0
2060 +
# cluster-announce-bus-port 6380
2061 +
# cluster-announce-client-tls-port 6479
2062 +
# cluster-announce-client-port 0
2063 +
2064 +
# Set the number of databases in cluster mode. The default database is DB 0,
2065 +
# you can select a different one on a per-connection basis using SELECT <dbid> where
2066 +
# dbid is a number between 0 and 'cluster-databases'-1.
2067 +
# cluster-databases 1
2068 +
2069 +
################################## COMMAND LOG ###################################
2070 +
2071 +
# The Command Log system is used to record commands that consume significant resources
2072 +
# during server operation, including CPU, memory, and network bandwidth.
2073 +
# These commands and the data they access may lead to abnormal instance operations,
2074 +
# the commandlog can help users quickly and intuitively locate issues.
2075 +
#
2076 +
# Currently, three types of command logs are supported:
2077 +
#
2078 +
# SLOW: Logs commands that exceed a specified execution time. This excludes time spent
2079 +
# on I/O operations like client communication and focuses solely on the command's
2080 +
# processing time, where the main thread is blocked.
2081 +
#
2082 +
# LARGE-REQUEST: Logs commands with requests exceeding a defined size. This helps
2083 +
# identify potentially problematic commands that send excessive data to the server.
2084 +
#
2085 +
# LARGE-REPLY: Logs commands that generate replies exceeding a defined size. This
2086 +
# helps identify commands that return unusually large amounts of data, which may
2087 +
# impact network performance or client processing.
2088 +
#
2089 +
# Each log type has two key parameters:
2090 +
# 1. A threshold value that determines when a command is logged. This threshold is specific
2091 +
# to the type of log (e.g., execution time, request size, or reply size). A negative value disables
2092 +
# logging. A value of 0 logs all commands.
2093 +
# 2. A maximum length that specifies the number of entries to retain in the log. Increasing
2094 +
# the length allows more entries to be stored but consumes additional memory. To clear all
2095 +
# entries for a specific log type and reclaim memory, use the `COMMANDLOG RESET`
2096 +
# subcommand followed by the log type.
2097 +
#
2098 +
# SLOW Command Logs
2099 +
# The SLOW log records commands that exceed a specified execution time. The execution time
2100 +
# does not include I/O operations, such as client communication or sending responses.
2101 +
# It only measures the time spent executing the command, during which the thread is blocked
2102 +
# and cannot handle other requests.
2103 +
#
2104 +
# The threshold is measured in microseconds.
2105 +
#
2106 +
# Backward Compatibility: The parameters `slowlog-log-slower-than` and `slowlog-max-len`
2107 +
# are still supported but deprecated in favor of these commandlog parameters.
2108 +
#
2109 +
# The following time is expressed in microseconds, so 1000000 is equivalent to 1 second.
2110 +
# Note that -1 disables the slow log, while 0 forces logging of every command.
2111 +
commandlog-execution-slower-than 10000
2112 +
# Record the number of commands.
2113 +
# There is no limit to this length. Just be aware that it will consume memory.
2114 +
# You can reclaim memory used by the slow log with SLOWLOG RESET or COMMANDLOG RESET SLOW.
2115 +
commandlog-slow-execution-max-len 128
2116 +
#
2117 +
# LARGE_REQUEST Command Logs
2118 +
# The LARGE_REQUEST log tracks commands with requests exceeding a specified size. The request size
2119 +
# includes the command itself and all its arguments. For example, in `SET KEY VALUE`, the size is
2120 +
# determined by the combined size of the key and value. Commands that consume excessive network
2121 +
# bandwidth or query buffer space are recorded here.
2122 +
#
2123 +
# The threshold is measured in bytes.
2124 +
# Note that -1 disables the large request log, while 0 forces logging of every command.
2125 +
commandlog-request-larger-than 1048576
2126 +
# Record the number of commands.
2127 +
# There is no limit to this length. Just be aware that it will consume memory.
2128 +
# You can reclaim memory used by the large request log with COMMANDLOG RESET LARGE-REQUEST.
2129 +
commandlog-large-request-max-len 128
2130 +
#
2131 +
# LARGE_REPLY Command Logs
2132 +
# The LARGE_REPLY log records commands that produce replies exceeding a specified size. These replies
2133 +
# may consume significant network bandwidth or client output buffer space. Examples include commands
2134 +
# like `KEYS` or `HGETALL` that return large datasets. Even a `GET` command may qualify if the value
2135 +
# is substantial.
2136 +
#
2137 +
# The threshold is measured in bytes.
2138 +
# Note that -1 disables the large reply log, while 0 forces logging of every command.
2139 +
# Enabling this feature (values other than -1) has performance implications
2140 +
# when I/O threads are used due to additional tracking overhead.
2141 +
# Consider using -1 to disable if large reply monitoring is not needed.
2142 +
commandlog-reply-larger-than 1048576
2143 +
# Record the number of commands.
2144 +
# There is no limit to this length. Just be aware that it will consume memory.
2145 +
# You can reclaim memory used by the large reply log with COMMANDLOG RESET LARGE-REPLY.
2146 +
commandlog-large-reply-max-len 128
2147 +
2148 +
################################ LATENCY MONITOR ##############################
2149 +
2150 +
# The server latency monitoring subsystem samples different operations
2151 +
# at runtime in order to collect data related to possible sources of
2152 +
# latency of a server instance.
2153 +
#
2154 +
# Via the LATENCY command this information is available to the user that can
2155 +
# print graphs and obtain reports.
2156 +
#
2157 +
# The system only logs operations that were performed in a time equal or
2158 +
# greater than the amount of milliseconds specified via the
2159 +
# latency-monitor-threshold configuration directive. When its value is set
2160 +
# to zero, the latency monitor is turned off.
2161 +
#
2162 +
# By default latency monitoring is disabled since it is mostly not needed
2163 +
# if you don't have latency issues, and collecting data has a performance
2164 +
# impact, that while very small, can be measured under big load. Latency
2165 +
# monitoring can easily be enabled at runtime using the command
2166 +
# "CONFIG SET latency-monitor-threshold <milliseconds>" if needed.
2167 +
latency-monitor-threshold 0
2168 +
2169 +
################################ LATENCY TRACKING ##############################
2170 +
2171 +
# The server's extended latency monitoring tracks the per command latencies and enables
2172 +
# exporting the percentile distribution via the INFO latencystats command,
2173 +
# and cumulative latency distributions (histograms) via the LATENCY command.
2174 +
#
2175 +
# By default, the extended latency monitoring is enabled since the overhead
2176 +
# of keeping track of the command latency is very small.
2177 +
# latency-tracking yes
2178 +
2179 +
# By default the exported latency percentiles via the INFO latencystats command
2180 +
# are the p50, p99, and p999.
2181 +
# latency-tracking-info-percentiles 50 99 99.9
2182 +
2183 +
############################# EVENT NOTIFICATION ##############################
2184 +
2185 +
# The server can notify Pub/Sub clients about events happening in the key space.
2186 +
# This feature is documented at https://valkey.io/topics/notifications
2187 +
#
2188 +
# For instance if keyspace events notification is enabled, and a client
2189 +
# performs a DEL operation on key "foo" stored in the Database 0, two
2190 +
# messages will be published via Pub/Sub:
2191 +
#
2192 +
# PUBLISH __keyspace@0__:foo del
2193 +
# PUBLISH __keyevent@0__:del foo
2194 +
#
2195 +
# It is possible to select the events that the server will notify among a set
2196 +
# of classes. Every class is identified by a single character:
2197 +
#
2198 +
# K Keyspace events, published with __keyspace@<db>__ prefix.
2199 +
# E Keyevent events, published with __keyevent@<db>__ prefix.
2200 +
# g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
2201 +
# $ String commands
2202 +
# l List commands
2203 +
# s Set commands
2204 +
# h Hash commands
2205 +
# z Sorted set commands
2206 +
# x Expired events (events generated every time a key expires)
2207 +
# e Evicted events (events generated when a key is evicted for maxmemory)
2208 +
# n New key events (Note: not included in the 'A' class)
2209 +
# t Stream commands
2210 +
# d Module key type events
2211 +
# m Key-miss events (Note: It is not included in the 'A' class)
2212 +
# A Alias for g$lshzxetd, so that the "AKE" string means all the events
2213 +
# (Except key-miss events which are excluded from 'A' due to their
2214 +
# unique nature).
2215 +
#
2216 +
# The "notify-keyspace-events" takes as argument a string that is composed
2217 +
# of zero or multiple characters. The empty string means that notifications
2218 +
# are disabled.
2219 +
#
2220 +
# Example: to enable list and generic events, from the point of view of the
2221 +
# event name, use:
2222 +
#
2223 +
# notify-keyspace-events Elg
2224 +
#
2225 +
# Example 2: to get the stream of the expired keys subscribing to channel
2226 +
# name __keyevent@0__:expired use:
2227 +
#
2228 +
# notify-keyspace-events Ex
2229 +
#
2230 +
# By default all notifications are disabled because most users don't need
2231 +
# this feature and the feature has some overhead. Note that if you don't
2232 +
# specify at least one of K or E, no events will be delivered.
2233 +
notify-keyspace-events ""
2234 +
2235 +
############################### ADVANCED CONFIG ###############################
2236 +
2237 +
# Hashes are encoded using a memory efficient data structure when they have a
2238 +
# small number of entries, and the biggest entry does not exceed a given
2239 +
# threshold. These thresholds can be configured using the following directives.
2240 +
hash-max-listpack-entries 512
2241 +
hash-max-listpack-value 64
2242 +
2243 +
# Lists are also encoded in a special way to save a lot of space.
2244 +
# The number of entries allowed per internal list node can be specified
2245 +
# as a fixed maximum size or a maximum number of elements.
2246 +
# For a fixed maximum size, use -5 through -1, meaning:
2247 +
# -5: max size: 64 Kb <-- not recommended for normal workloads
2248 +
# -4: max size: 32 Kb <-- not recommended
2249 +
# -3: max size: 16 Kb <-- probably not recommended
2250 +
# -2: max size: 8 Kb <-- good
2251 +
# -1: max size: 4 Kb <-- good
2252 +
# Positive numbers mean store up to _exactly_ that number of elements
2253 +
# per list node.
2254 +
# The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size),
2255 +
# but if your use case is unique, adjust the settings as necessary.
2256 +
list-max-listpack-size -2
2257 +
2258 +
# Lists may also be compressed.
2259 +
# Compress depth is the number of quicklist ziplist nodes from *each* side of
2260 +
# the list to *exclude* from compression. The head and tail of the list
2261 +
# are always uncompressed for fast push/pop operations. Settings are:
2262 +
# 0: disable all list compression
2263 +
# 1: depth 1 means "don't start compressing until after 1 node into the list,
2264 +
# going from either the head or tail"
2265 +
# So: [head]->node->node->...->node->[tail]
2266 +
# [head], [tail] will always be uncompressed; inner nodes will compress.
2267 +
# 2: [head]->[next]->node->node->...->node->[prev]->[tail]
2268 +
# 2 here means: don't compress head or head->next or tail->prev or tail,
2269 +
# but compress all nodes between them.
2270 +
# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
2271 +
# etc.
2272 +
list-compress-depth 0
2273 +
2274 +
# Sets have a special encoding when a set is composed
2275 +
# of just strings that happen to be integers in radix 10 in the range
2276 +
# of 64 bit signed integers.
2277 +
# The following configuration setting sets the limit in the size of the
2278 +
# set in order to use this special memory saving encoding.
2279 +
set-max-intset-entries 512
2280 +
2281 +
# Sets containing non-integer values are also encoded using a memory efficient
2282 +
# data structure when they have a small number of entries, and the biggest entry
2283 +
# does not exceed a given threshold. These thresholds can be configured using
2284 +
# the following directives.
2285 +
set-max-listpack-entries 128
2286 +
set-max-listpack-value 64
2287 +
2288 +
# Similarly to hashes and lists, sorted sets are also specially encoded in
2289 +
# order to save a lot of space. This encoding is only used when the length and
2290 +
# elements of a sorted set are below the following limits:
2291 +
zset-max-listpack-entries 128
2292 +
zset-max-listpack-value 64
2293 +
2294 +
# HyperLogLog sparse representation bytes limit. The limit includes the
2295 +
# 16 bytes header. When a HyperLogLog using the sparse representation crosses
2296 +
# this limit, it is converted into the dense representation.
2297 +
#
2298 +
# A value greater than 16000 is totally useless, since at that point the
2299 +
# dense representation is more memory efficient.
2300 +
#
2301 +
# The suggested value is ~ 3000 in order to have the benefits of
2302 +
# the space efficient encoding without slowing down too much PFADD,
2303 +
# which is O(N) with the sparse encoding. The value can be raised to
2304 +
# ~ 10000 when CPU is not a concern, but space is, and the data set is
2305 +
# composed of many HyperLogLogs with cardinality in the 0 - 15000 range.
2306 +
hll-sparse-max-bytes 3000
2307 +
2308 +
# Streams macro node max size / items. The stream data structure is a radix
2309 +
# tree of big nodes that encode multiple items inside. Using this configuration
2310 +
# it is possible to configure how big a single node can be in bytes, and the
2311 +
# maximum number of items it may contain before switching to a new node when
2312 +
# appending new stream entries. If any of the following settings are set to
2313 +
# zero, the limit is ignored, so for instance it is possible to set just a
2314 +
# max entries limit by setting max-bytes to 0 and max-entries to the desired
2315 +
# value.
2316 +
stream-node-max-bytes 4096
2317 +
stream-node-max-entries 100
2318 +
2319 +
# Active rehashing uses 1% of the CPU time to help perform incremental rehashing
2320 +
# of the main server hash tables, the ones mapping top-level keys to values.
2321 +
#
2322 +
# If active rehashing is disabled and rehashing is needed, a hash table is
2323 +
# rehashed one "step" on every operation performed on the hash table (add, find,
2324 +
# etc.), so if the server is idle, the rehashing may never complete and some
2325 +
# more memory is used by the hash tables. Active rehashing helps prevent this.
2326 +
#
2327 +
# Active rehashing runs as a background task. Depending on the value of 'hz',
2328 +
# the frequency at which the server performs background tasks, active rehashing
2329 +
# can cause the server to freeze for a short time. For example, if 'hz' is set
2330 +
# to 10, active rehashing runs for up to one millisecond every 100 milliseconds.
2331 +
# If a freeze of one millisecond is not acceptable, you can increase 'hz' to let
2332 +
# active rehashing run more often. If instead 'hz' is set to 100, active
2333 +
# rehashing runs up to only 100 microseconds every 10 milliseconds. The total is
2334 +
# still 1% of the time.
2335 +
activerehashing yes
2336 +
2337 +
# The client output buffer limits can be used to force disconnection of clients
2338 +
# that are not reading data from the server fast enough for some reason (a
2339 +
# common reason is that a Pub/Sub client can't consume messages as fast as the
2340 +
# publisher can produce them).
2341 +
#
2342 +
# The limit can be set differently for the three different classes of clients:
2343 +
#
2344 +
# normal -> normal clients including MONITOR clients
2345 +
# replica -> replica clients
2346 +
# pubsub -> clients subscribed to at least one pubsub channel or pattern
2347 +
#
2348 +
# The syntax of every client-output-buffer-limit directive is the following:
2349 +
#
2350 +
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
2351 +
#
2352 +
# A client is immediately disconnected once the hard limit is reached, or if
2353 +
# the soft limit is reached and remains reached for the specified number of
2354 +
# seconds (continuously).
2355 +
# So for instance if the hard limit is 32 megabytes and the soft limit is
2356 +
# 16 megabytes / 10 seconds, the client will get disconnected immediately
2357 +
# if the size of the output buffers reach 32 megabytes, but will also get
2358 +
# disconnected if the client reaches 16 megabytes and continuously overcomes
2359 +
# the limit for 10 seconds.
2360 +
#
2361 +
# By default normal clients are not limited because they don't receive data
2362 +
# without asking (in a push way), but just after a request, so only
2363 +
# asynchronous clients may create a scenario where data is requested faster
2364 +
# than it can read.
2365 +
#
2366 +
# Instead there is a default limit for pubsub and replica clients, since
2367 +
# subscribers and replicas receive data in a push fashion.
2368 +
#
2369 +
# Note that it doesn't make sense to set the replica clients output buffer
2370 +
# limit lower than the repl-backlog-size config (partial sync will succeed
2371 +
# and then replica will get disconnected).
2372 +
# Such a configuration is ignored (the size of repl-backlog-size will be used).
2373 +
# This doesn't have memory consumption implications since the replica client
2374 +
# will share the backlog buffers memory.
2375 +
#
2376 +
# Both the hard or the soft limit can be disabled by setting them to zero.
2377 +
client-output-buffer-limit normal 0 0 0
2378 +
client-output-buffer-limit replica 256mb 64mb 60
2379 +
client-output-buffer-limit pubsub 32mb 8mb 60
2380 +
2381 +
# Client query buffers accumulate new commands. They are limited to a fixed
2382 +
# amount by default in order to avoid that a protocol desynchronization (for
2383 +
# instance due to a bug in the client) will lead to unbound memory usage in
2384 +
# the query buffer. However you can configure it here if you have very special
2385 +
# needs, such as a command with huge argument, or huge multi/exec requests or alike.
2386 +
#
2387 +
# client-query-buffer-limit 1gb
2388 +
2389 +
# In some scenarios client connections can hog up memory leading to OOM
2390 +
# errors or data eviction. To avoid this we can cap the accumulated memory
2391 +
# used by all client connections (all pubsub and normal clients). Once we
2392 +
# reach that limit connections will be dropped by the server freeing up
2393 +
# memory. The server will attempt to drop the connections using the most
2394 +
# memory first. We call this mechanism "client eviction".
2395 +
#
2396 +
# Client eviction is configured using the maxmemory-clients setting as follows:
2397 +
# 0 - client eviction is disabled (default)
2398 +
#
2399 +
# A memory value can be used for the client eviction threshold,
2400 +
# for example:
2401 +
# maxmemory-clients 1g
2402 +
#
2403 +
# A percentage value (between 1% and 100%) means the client eviction threshold
2404 +
# is based on a percentage of the maxmemory setting. For example to set client
2405 +
# eviction at 5% of maxmemory:
2406 +
# maxmemory-clients 5%
2407 +
2408 +
# In the server protocol, bulk requests, that are, elements representing single
2409 +
# strings, are normally limited to 512 mb. However you can change this limit
2410 +
# here, but must be 1mb or greater
2411 +
#
2412 +
# proto-max-bulk-len 512mb
2413 +
2414 +
# The server calls an internal function to perform many background tasks, like
2415 +
# closing connections of clients in timeout, purging expired keys that are
2416 +
# never requested, and so forth.
2417 +
#
2418 +
# Not all tasks are performed with the same frequency, but the server checks for
2419 +
# tasks to perform according to the specified "hz" value.
2420 +
#
2421 +
# By default "hz" is set to 10. Raising the value will use more CPU when
2422 +
# the server is idle, but at the same time will make the server more responsive when
2423 +
# there are many keys expiring at the same time, and timeouts may be
2424 +
# handled with more precision.
2425 +
#
2426 +
# The range is between 1 and 500, however a value over 100 is usually not
2427 +
# a good idea. Most users should use the default of 10 and raise this up to
2428 +
# 100 only in environments where very low latency is required.
2429 +
hz 10
2430 +
2431 +
# When a child rewrites the AOF file, if the following option is enabled
2432 +
# the file will be fsync-ed every 4 MB of data generated. This is useful
2433 +
# in order to commit the file to the disk more incrementally and avoid
2434 +
# big latency spikes.
2435 +
aof-rewrite-incremental-fsync yes
2436 +
2437 +
# When the server saves RDB file, if the following option is enabled
2438 +
# the file will be fsync-ed every 4 MB of data generated. This is useful
2439 +
# in order to commit the file to the disk more incrementally and avoid
2440 +
# big latency spikes.
2441 +
rdb-save-incremental-fsync yes
2442 +
2443 +
# The server's LFU eviction (see maxmemory setting) can be tuned. However it is a good
2444 +
# idea to start with the default settings and only change them after investigating
2445 +
# how to improve the performances and how the keys LFU change over time, which
2446 +
# is possible to inspect via the OBJECT FREQ command.
2447 +
#
2448 +
# There are two tunable parameters in the server LFU implementation: the
2449 +
# counter logarithm factor and the counter decay time. It is important to
2450 +
# understand what the two parameters mean before changing them.
2451 +
#
2452 +
# The LFU counter is just 8 bits per key, it's maximum value is 255, so the server
2453 +
# uses a probabilistic increment with logarithmic behavior. Given the value
2454 +
# of the old counter, when a key is accessed, the counter is incremented in
2455 +
# this way:
2456 +
#
2457 +
# 1. A random number R between 0 and 1 is extracted.
2458 +
# 2. A probability P is calculated as 1/(old_value*lfu_log_factor+1).
2459 +
# 3. The counter is incremented only if R < P.
2460 +
#
2461 +
# The default lfu-log-factor is 10. This is a table of how the frequency
2462 +
# counter changes with a different number of accesses with different
2463 +
# logarithmic factors:
2464 +
#
2465 +
# +--------+------------+------------+------------+------------+------------+
2466 +
# | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits |
2467 +
# +--------+------------+------------+------------+------------+------------+
2468 +
# | 0 | 104 | 255 | 255 | 255 | 255 |
2469 +
# +--------+------------+------------+------------+------------+------------+
2470 +
# | 1 | 18 | 49 | 255 | 255 | 255 |
2471 +
# +--------+------------+------------+------------+------------+------------+
2472 +
# | 10 | 10 | 18 | 142 | 255 | 255 |
2473 +
# +--------+------------+------------+------------+------------+------------+
2474 +
# | 100 | 8 | 11 | 49 | 143 | 255 |
2475 +
# +--------+------------+------------+------------+------------+------------+
2476 +
#
2477 +
# NOTE: The above table was obtained by running the following commands:
2478 +
#
2479 +
# valkey-benchmark -n 1000000 incr foo
2480 +
# valkey-cli object freq foo
2481 +
#
2482 +
# NOTE 2: The counter initial value is 5 in order to give new objects a chance
2483 +
# to accumulate hits.
2484 +
#
2485 +
# The counter decay time is the time, in minutes, that must elapse in order
2486 +
# for the key counter to be decremented.
2487 +
#
2488 +
# The default value for the lfu-decay-time is 1. A special value of 0 means we
2489 +
# will never decay the counter.
2490 +
#
2491 +
# lfu-log-factor 10
2492 +
# lfu-decay-time 1
2493 +
2494 +
2495 +
# The maximum number of new client connections accepted per event-loop cycle. This configuration
2496 +
# is set independently for TLS connections.
2497 +
#
2498 +
# By default, up to 10 new connection will be accepted per event-loop cycle for normal connections
2499 +
# and up to 1 new connection per event-loop cycle for TLS connections.
2500 +
#
2501 +
# Adjusting this to a larger number can slightly improve efficiency for new connections
2502 +
# at the risk of causing timeouts for regular commands on established connections. It is
2503 +
# not advised to change this without ensuring that all clients have limited connection
2504 +
# pools and exponential backoff in the case of command/connection timeouts.
2505 +
#
2506 +
# If your application is establishing a large number of new connections per second you should
2507 +
# also consider tuning the value of tcp-backlog, which allows the kernel to buffer more
2508 +
# pending connections before dropping or rejecting connections.
2509 +
#
2510 +
# max-new-connections-per-cycle 10
2511 +
# max-new-tls-connections-per-cycle 1
2512 +
2513 +
# Memory prefetching is used when multiple commands are parsed and ready for
2514 +
# execution. We take advantage of knowing the next set of commands and prefetch
2515 +
# their required hash table entries in a batch. This reduces the time spent on
2516 +
# memory accesses.
2517 +
#
2518 +
# When I/O threads are used, the keys of multiple commands from multiple clients
2519 +
# are prefetched together. When I/O threads are not used, only the commands from
2520 +
# a single client's command pipeline is prefetched.
2521 +
#
2522 +
# The optimal batch size depends on the specific workflow of the user and on the
2523 +
# hardware used. The default batch size is 16, which can be modified using the
2524 +
# 'prefetch-batch-max-size' config.
2525 +
#
2526 +
# When the config is set to 0, prefetching is disabled.
2527 +
#
2528 +
# prefetch-batch-max-size 16
2529 +
2530 +
2531 +
########################### ACTIVE DEFRAGMENTATION #######################
2532 +
#
2533 +
# What is active defragmentation?
2534 +
# -------------------------------
2535 +
#
2536 +
# Active (online) defragmentation allows a server to compact the
2537 +
# spaces left between small allocations and deallocations of data in memory,
2538 +
# thus allowing to reclaim back memory.
2539 +
#
2540 +
# Fragmentation is a natural process that happens with every allocator (but
2541 +
# less so with Jemalloc, fortunately) and certain workloads. Normally a server
2542 +
# restart is needed in order to lower the fragmentation, or at least to flush
2543 +
# away all the data and create it again. However thanks to this feature, this
2544 +
# process can happen at runtime in a "hot" way, while the server is running.
2545 +
#
2546 +
# Basically when the fragmentation is over a certain level (see the
2547 +
# configuration options below) the server will start to create new copies of the
2548 +
# values in contiguous memory regions by exploiting certain specific Jemalloc
2549 +
# features (in order to understand if an allocation is causing fragmentation
2550 +
# and to allocate it in a better place), and at the same time, will release the
2551 +
# old copies of the data. This process, repeated incrementally for all the keys
2552 +
# will cause the fragmentation to drop back to normal values.
2553 +
#
2554 +
# Important things to understand:
2555 +
#
2556 +
# 1. This feature is disabled by default, and only works if you compiled the server
2557 +
# to use the copy of Jemalloc we ship with the source code of the server.
2558 +
# This is the default with Linux builds.
2559 +
#
2560 +
# 2. You never need to enable this feature if you don't have fragmentation
2561 +
# issues.
2562 +
#
2563 +
# 3. Once you experience fragmentation, you can enable this feature when
2564 +
# needed with the command "CONFIG SET activedefrag yes".
2565 +
#
2566 +
# The configuration parameters are able to fine tune the behavior of the
2567 +
# defragmentation process. If you are not sure about what they mean it is
2568 +
# a good idea to leave the defaults untouched.
2569 +
2570 +
# Active defragmentation is disabled by default
2571 +
# activedefrag no
2572 +
2573 +
# Minimum amount of fragmentation waste to start active defrag
2574 +
# active-defrag-ignore-bytes 100mb
2575 +
2576 +
# Minimum percentage of fragmentation to start active defrag
2577 +
# active-defrag-threshold-lower 10
2578 +
2579 +
# Maximum percentage of fragmentation at which we use maximum effort
2580 +
# active-defrag-threshold-upper 100
2581 +
2582 +
# Minimal effort for defrag in CPU percentage, not cycle time as the name might
2583 +
# suggest, to be used when the lower threshold is reached.
2584 +
# active-defrag-cycle-min 1
2585 +
2586 +
# Maximal effort for defrag in CPU percentage, not cycle time as the name might
2587 +
# suggest, to be used when the upper threshold is reached.
2588 +
# active-defrag-cycle-max 25
2589 +
2590 +
# Maximum number of set/hash/zset/list fields that will be processed from
2591 +
# the main dictionary scan
2592 +
# active-defrag-max-scan-fields 1000
2593 +
2594 +
# The time spent (in microseconds) of the periodic active defrag process. This
2595 +
# affects the latency impact of active defrag on client commands. Smaller numbers
2596 +
# will result in less latency impact at the cost of increased defrag overhead.
2597 +
# active-defrag-cycle-us 500
2598 +
2599 +
# Jemalloc background thread for purging will be enabled by default
2600 +
jemalloc-bg-thread yes
2601 +
2602 +
# It is possible to pin different threads and processes of the server to specific
2603 +
# CPUs in your system, in order to maximize the performances of the server.
2604 +
# This is useful both in order to pin different server threads in different
2605 +
# CPUs, but also in order to make sure that multiple server instances running
2606 +
# in the same host will be pinned to different CPUs.
2607 +
#
2608 +
# Normally you can do this using the "taskset" command, however it is also
2609 +
# possible to do this via the server configuration directly, both in Linux and FreeBSD.
2610 +
#
2611 +
# You can pin the server/IO threads, bio threads, aof rewrite child process,
2612 +
# bgsave child process and the slot migration process.
2613 +
# The syntax to specify the cpu list is the same as the taskset command:
2614 +
#
2615 +
# Set server/io threads to cpu affinity 0,2,4,6:
2616 +
# server-cpulist 0-7:2
2617 +
#
2618 +
# Set bio threads to cpu affinity 1,3:
2619 +
# bio-cpulist 1,3
2620 +
#
2621 +
# Set aof rewrite child process to cpu affinity 8,9,10,11:
2622 +
# aof-rewrite-cpulist 8-11
2623 +
#
2624 +
# Set bgsave (or slot migration) child process to cpu affinity 1,10,11:
2625 +
# bgsave-cpulist 1,10-11
2626 +
2627 +
# In some cases the server will emit warnings and even refuse to start if it detects
2628 +
# that the system is in bad state, it is possible to suppress these warnings
2629 +
# by setting the following config which takes a space delimited list of warnings
2630 +
# to suppress
2631 +
#
2632 +
# ignore-warnings ARM64-COW-BUG
2633 +
2634 +
# Inform Valkey of the availability zone if running in a cloud environment. Currently
2635 +
# this is exposed in the INFO and HELLO commands for clients to use. Default is
2636 +
# the empty string.
2637 +
#
2638 +
# availability-zone "zone-name"
2639 +