valkey: update configuration for 9.1.0

Author: thestinger

valkey/valkey.conf

@@ -256,18 +256,24 @@ tcp-keepalive 300
 # tls-auth-clients optional
 
 # Automatically authenticate TLS clients as Valkey users based on their
-# certificates.
+# certificate fields. When enabled, the server extracts a value from the
+# client's TLS certificate and looks up a matching Valkey user. If found,
+# the client is authenticated as that user during the TLS handshake. If no
+# match is found, the client remains unauthenticated as the default user.
 #
-# If set to a field like "CN", the server will extract the corresponding field
-# from the client's TLS certificate and attempt to find a Valkey user with the
-# same name. If a matching user is found, the client is automatically
-# authenticated as that user during the TLS handshake. If no matching user is
-# found, the client is connected as the unauthenticated default user. Set to
-# "off" to disable automatic user authentication via certificate fields.
+# When using this feature, it is recommended to configure users without
+# passwords so that authentication is enforced exclusively through client
+# certificates, such as `ACL SETUSER URI-user on allcommands allkeys`.
 #
-# Supported values: CN, off. Default: off.
+# Options:
+#   CN  - Use the Common Name from the certificate's Subject field.
+#   URI - Use the URI from the certificate's Subject Alternative Name (SAN).
+#         If multiple URI entries exist, the first one matching an enabled
+#         Valkey user is used.
+#   off - Disable certificate-based user authentication (default).
 #
-# tls-auth-clients-user CN
+# Example:
+#   tls-auth-clients-user URI
 
 # By default, a replica does not attempt to establish a TLS connection
 # with its primary.
@@ -324,6 +330,16 @@ tcp-keepalive 300
 #
 # tls-session-cache-timeout 60
 
+# Interval of TLS material reloading in seconds.
+# The default value is 0 (disabled, no automatic reload).
+# When set to a value greater than 0, the server will periodically check the
+# certificate and key files and, if modified, reload the TLS materials. The
+# reload work is performed in a background thread, so it does not block the main
+# thread.
+#
+# For example, to reload TLS materials daily:
+# tls-auto-reload-interval 86400
+
 ################################### RDMA ######################################
 
 # Valkey Over RDMA is experimental, it may be changed or be removed in any minor or major version.
@@ -425,6 +441,7 @@ loglevel notice
 #
 # - legacy: the default, traditional log format
 # - logfmt: a structured log format; see https://www.brandur.org/logfmt
+# - json: a structured log format
 #
 # log-format legacy
 
@@ -521,6 +538,19 @@ locale-collate ""
 #
 # extended-redis-compatibility no
 
+# Inform Valkey of the availability zone if running in a cloud environment.  Currently
+# this is exposed in the INFO and HELLO commands for clients to use. Default is
+# the empty string.
+#
+# availability-zone "zone-name"
+
+# Use a fixed hash seed for hashtable instead of a random one.
+# Setting this option makes commands like SCAN return keys in a consistent
+# order across restarts and failovers. The seed can be any string up to 256 characters.
+# The value is immutable and must be provided only at server startup.
+#
+# hash-seed example-seed-val
+
 ################################ SNAPSHOTTING  ################################
 
 # Save the DB to disk.
@@ -805,10 +835,21 @@ repl-diskless-load disabled
 # generally beneficial as it prevents potential performance degradation on the primary
 # server, which is typically handling more critical operations.
 #
+# During the dual channel full sync, the maximum size of the local replication buffer
+# on the replica is limited by the hard limit of the replica client output buffer on
+# the replica side. When the replica reaches the limit, it will stop accumulating the
+# further data. At this point, any additional data accumulation will occur on primary
+# side, which is depending on the replica client output buffer on the primary side.
+#
 # When toggling this configuration on or off during an ongoing synchronization process,
 # it does not change the already running sync method. The new configuration will take
 # effect only for subsequent synchronization processes.
-
+#
+# To enable dual channel replication, both the primary and its replicas should have
+# dual-channel-replication-enabled set to yes. Additionally, the primary is required
+# to have repl-diskless-sync enabled, as this allows the RDB snapshot to be streamed
+# directly over the connection for the dual channel mechanism to function properly.
+#
 dual-channel-replication-enabled no
 
 # Master send PINGs to its replicas in a predefined interval. It's possible to
@@ -1746,9 +1787,9 @@ aof-timestamp-enabled no
 # the server in the case a write command was already issued by the script when
 # the user doesn't want to wait for the natural termination of the script.
 #
-# The default is 5 seconds. It is possible to set it to 0 or a negative value
-# to disable this mechanism (uninterrupted execution). Note that in the past
-# this config had a different name, which is now an alias, so both of these do
+# The default is 5 seconds. It is possible to set it to 0 to disable this 
+# mechanism (uninterrupted execution). Note that in the past this config had a 
+# different name, which is now an alias, so both of these do
 # the same:
 # lua-time-limit 5000
 # busy-reply-threshold 5000
@@ -1769,6 +1810,32 @@ aof-timestamp-enabled no
 #
 # cluster-config-file nodes-6379.conf
 
+# This option controls how the cluster handles the saving behavior of the
+# "cluster-config-file" file.
+#
+# When cluster metadata changes (e.g., node joins/leaves, slot migrations,
+# failovers), the cluster needs to save the updated configuration to the
+# "cluster-config-file" file.
+#
+# Available options:
+#
+# - sync (default): Synchronously save the config file. If the save fails,
+#   the process exits immediately. This is the traditional behavior that
+#   prioritizes configuration consistency.
+#
+# - best-effort: Synchronously save the config file. If the save fails,
+#   only log a warning and continue running. The node will retry saving
+#   on the next configuration change. Passive exit may bring unexpected
+#   effects, such as cluster down. This mode allows the node to survive
+#   temporary disk failures, giving administrators time to address the
+#   issue without causing immediate service disruption.
+#
+# Note: The 'best-effort' mode is particularly useful in some environments.
+# However, if the disk issue persists and the node restarts, it may load
+# stale configuration data. Use with caution and ensure proper monitoring.
+#
+# cluster-config-save-behavior sync
+
 # Cluster node timeout is the amount of milliseconds a node must be unreachable
 # for it to be considered in failure state.
 # Most other internal time limits are a multiple of the node timeout.
@@ -1994,10 +2061,14 @@ aof-timestamp-enabled no
 # During the CLUSTER MIGRATESLOTS command execution, the source node needs to pause itself and allow all
 # writes to be fully processed by the target node. The amount of data remaining in the buffer on the
 # source node when this pause happens will affect how long this pause takes.
+#
 # 'slot-migration-max-failover-repl-bytes' allows the pause to wait until there are at most this
 # many bytes in the output buffer. Setting this to -1 will disable this limit, and 0 will require
-# no data be in the source output buffer (although this is not a guaranatee the data is fully
-# received by the target). 
+# no data be in the source output buffer (although this is not a guarantee the data is fully
+# received by the target).
+#
+# You can check the remaining buffer data size by examining the 'remaining_repl_size' field in the
+# 'CLUSTER GETSLOTMIGRATIONS' command output on the source node.
 #
 # slot-migration-max-failover-repl-bytes 0
 
@@ -2234,15 +2305,30 @@ notify-keyspace-events ""
 
 ############################### ADVANCED CONFIG ###############################
 
-# Hashes are encoded using a memory efficient data structure when they have a
-# small number of entries, and the biggest entry does not exceed a given
-# threshold. These thresholds can be configured using the following directives.
+# Valkey uses listpacks for some small hashes, sets, sorted sets, and
+# list nodes.
+# A listpack is a compact, memory-efficient representation that stores multiple
+# elements in a contiguous block of memory. This usually saves memory, but
+# larger listpacks can make some updates or lookups more expensive because more
+# data may need to be traversed or rewritten.
+#
+# The "*-max-listpack-entries" settings limit how many entries can stay in a
+# listpack. The "*-max-listpack-value" settings limit the largest element,
+# field, or value that can stay in a listpack.
+#
+# This section also includes related settings for list compression and for sets
+# that can use intset encoding instead of listpacks.
+#
+# Change these only after measuring your actual dataset and workload.
+#
+# Hashes use listpacks when they have a small number of entries, and the
+# biggest field or value does not exceed the following limits.
 hash-max-listpack-entries 512
 hash-max-listpack-value 64
 
-# Lists are also encoded in a special way to save a lot of space.
-# The number of entries allowed per internal list node can be specified
-# as a fixed maximum size or a maximum number of elements.
+# Lists are stored as quicklists, where each internal node is a listpack.
+# The number of entries allowed per listpack node can be specified as a fixed
+# maximum size or a maximum number of elements.
 # For a fixed maximum size, use -5 through -1, meaning:
 # -5: max size: 64 Kb  <-- not recommended for normal workloads
 # -4: max size: 32 Kb  <-- not recommended
@@ -2256,7 +2342,7 @@ hash-max-listpack-value 64
 list-max-listpack-size -2
 
 # Lists may also be compressed.
-# Compress depth is the number of quicklist ziplist nodes from *each* side of
+# Compress depth is the number of quicklist nodes from *each* side of
 # the list to *exclude* from compression.  The head and tail of the list
 # are always uncompressed for fast push/pop operations.  Settings are:
 # 0: disable all list compression
@@ -2271,23 +2357,18 @@ list-max-listpack-size -2
 # etc.
 list-compress-depth 0
 
-# Sets have a special encoding when a set is composed
-# of just strings that happen to be integers in radix 10 in the range
-# of 64 bit signed integers.
-# The following configuration setting sets the limit in the size of the
-# set in order to use this special memory saving encoding.
+# Sets containing only integers can use intset encoding.
+# The following setting limits the largest set that can use intset encoding.
 set-max-intset-entries 512
 
-# Sets containing non-integer values are also encoded using a memory efficient
-# data structure when they have a small number of entries, and the biggest entry
-# does not exceed a given threshold. These thresholds can be configured using
-# the following directives.
+# Sets containing non-integer values use listpacks when they have a small
+# number of entries, and the biggest member does not exceed the following
+# limits.
 set-max-listpack-entries 128
 set-max-listpack-value 64
 
-# Similarly to hashes and lists, sorted sets are also specially encoded in
-# order to save a lot of space. This encoding is only used when the length and
-# elements of a sorted set are below the following limits:
+# Sorted sets use listpacks when they have a small number of entries, and the
+# biggest member does not exceed the following limits:
 zset-max-listpack-entries 128
 zset-max-listpack-value 64
 
@@ -2393,8 +2474,9 @@ client-output-buffer-limit pubsub 32mb 8mb 60
 # memory. The server will attempt to drop the connections using the most
 # memory first. We call this mechanism "client eviction".
 #
-# Client eviction is configured using the maxmemory-clients setting as follows:
-# 0 - client eviction is disabled (default)
+# Client eviction is configured using the maxmemory-clients directive, which is
+# 0 (disabled) by default, because it has a small performance impact under high
+# load. It can be enabled at runtime when needed.
 #
 # A memory value can be used for the client eviction threshold,
 # for example:
@@ -2404,6 +2486,8 @@ client-output-buffer-limit pubsub 32mb 8mb 60
 # is based on a percentage of the maxmemory setting. For example to set client
 # eviction at 5% of maxmemory:
 # maxmemory-clients 5%
+#
+# maxmemory-clients 0
 
 # In the server protocol, bulk requests, that are, elements representing single
 # strings, are normally limited to 512 mb. However you can change this limit
@@ -2527,6 +2611,38 @@ rdb-save-incremental-fsync yes
 #
 # prefetch-batch-max-size 16
 
+# It is possible to pin different threads and processes of the server to specific
+# CPUs in your system, in order to maximize the performances of the server.
+# This is useful both in order to pin different server threads in different
+# CPUs, but also in order to make sure that multiple server instances running
+# in the same host will be pinned to different CPUs.
+#
+# Normally you can do this using the "taskset" command, however it is also
+# possible to do this via the server configuration directly, both in Linux and FreeBSD.
+#
+# You can pin the server/IO threads, bio threads, aof rewrite child process,
+# bgsave child process and the slot migration process.
+# The syntax to specify the cpu list is the same as the taskset command:
+#
+# Set server/io threads to cpu affinity 0,2,4,6:
+# server-cpulist 0-7:2
+#
+# Set bio threads to cpu affinity 1,3:
+# bio-cpulist 1,3
+#
+# Set aof rewrite child process to cpu affinity 8,9,10,11:
+# aof-rewrite-cpulist 8-11
+#
+# Set bgsave (or slot migration) child process to cpu affinity 1,10,11:
+# bgsave-cpulist 1,10-11
+
+# In some cases the server will emit warnings and even refuse to start if it detects
+# that the system is in bad state, it is possible to suppress these warnings
+# by setting the following config which takes a space delimited list of warnings
+# to suppress
+#
+# ignore-warnings ARM64-COW-BUG
+
 
 ########################### ACTIVE DEFRAGMENTATION #######################
 #
@@ -2598,41 +2714,3 @@ rdb-save-incremental-fsync yes
 
 # Jemalloc background thread for purging will be enabled by default
 jemalloc-bg-thread yes
-
-# It is possible to pin different threads and processes of the server to specific
-# CPUs in your system, in order to maximize the performances of the server.
-# This is useful both in order to pin different server threads in different
-# CPUs, but also in order to make sure that multiple server instances running
-# in the same host will be pinned to different CPUs.
-#
-# Normally you can do this using the "taskset" command, however it is also
-# possible to do this via the server configuration directly, both in Linux and FreeBSD.
-#
-# You can pin the server/IO threads, bio threads, aof rewrite child process,
-# bgsave child process and the slot migration process.
-# The syntax to specify the cpu list is the same as the taskset command:
-#
-# Set server/io threads to cpu affinity 0,2,4,6:
-# server-cpulist 0-7:2
-#
-# Set bio threads to cpu affinity 1,3:
-# bio-cpulist 1,3
-#
-# Set aof rewrite child process to cpu affinity 8,9,10,11:
-# aof-rewrite-cpulist 8-11
-#
-# Set bgsave (or slot migration) child process to cpu affinity 1,10,11:
-# bgsave-cpulist 1,10-11
-
-# In some cases the server will emit warnings and even refuse to start if it detects
-# that the system is in bad state, it is possible to suppress these warnings
-# by setting the following config which takes a space delimited list of warnings
-# to suppress
-#
-# ignore-warnings ARM64-COW-BUG
-
-# Inform Valkey of the availability zone if running in a cloud environment.  Currently
-# this is exposed in the INFO and HELLO commands for clients to use. Default is
-# the empty string.
-#
-# availability-zone "zone-name"