diff --git a/keydb.conf b/keydb.conf index 3edfb70d3..59dfc25d6 100644 --- a/keydb.conf +++ b/keydb.conf @@ -165,7 +165,7 @@ tcp-keepalive 300 # tls-auth-clients no # tls-auth-clients optional -# By default, a Redis replica does not attempt to establish a TLS connection +# By default, a KeyDB replica does not attempt to establish a TLS connection # with its master. # # Use the following directive to enable TLS on replication links. @@ -497,8 +497,8 @@ repl-diskless-sync-delay 5 # ----------------------------------------------------------------------------- # WARNING: RDB diskless load is experimental. Since in this setup the replica # does not immediately store an RDB on disk, it may cause data loss during -# failovers. RDB diskless load + Redis modules not handling I/O reads may also -# cause Redis to abort in case of I/O errors during the initial synchronization +# failovers. RDB diskless load + KeyDB modules not handling I/O reads may also +# cause KeyDB to abort in case of I/O errors during the initial synchronization # stage with the master. Use only if your do what you are doing. # ----------------------------------------------------------------------------- # @@ -581,7 +581,7 @@ repl-disable-tcp-nodelay no # repl-backlog-ttl 3600 # The replica priority is an integer number published by KeyDB in the INFO -# output. It is used by Redis Sentinel in order to select a replica to promote +# output. It is used by KeyDB Sentinel in order to select a replica to promote # into a master if the master is no longer working correctly. # # A replica with a low priority number is considered better for promotion, so @@ -648,7 +648,7 @@ replica-priority 100 ############################### KEYS TRACKING ################################# -# Redis implements server assisted support for client side caching of values. +# KeyDB implements server assisted support for client side caching of values. # This is implemented using an invalidation table that remembers, using # 16 millions of slots, what clients may have certain subsets of keys. In turn # this is used in order to send invalidation messages to clients. Please @@ -657,22 +657,22 @@ replica-priority 100 # https://redis.io/topics/client-side-caching # # When tracking is enabled for a client, all the read only queries are assumed -# to be cached: this will force Redis to store information in the invalidation +# to be cached: this will force KeyDB to store information in the invalidation # table. When keys are modified, such information is flushed away, and # invalidation messages are sent to the clients. However if the workload is -# heavily dominated by reads, Redis could use more and more memory in order +# heavily dominated by reads, KeyDB could use more and more memory in order # to track the keys fetched by many clients. # # For this reason it is possible to configure a maximum fill value for the # invalidation table. By default it is set to 1M of keys, and once this limit -# is reached, Redis will start to evict keys in the invalidation table +# is reached, KeyDB will start to evict keys in the invalidation table # even if they were not modified, just to reclaim memory: this will in turn # force the clients to invalidate the cached values. Basically the table # maximum size is a trade off between the memory you want to spend server # side to track information about who cached what, and the ability of clients # to retain cached objects in memory. # -# If you set the value to 0, it means there are no limits, and Redis will +# If you set the value to 0, it means there are no limits, and KeyDB will # retain as many keys as needed in the invalidation table. # In the "stats" INFO section, you can find information about the number of # keys in the invalidation table at every given moment. @@ -938,7 +938,7 @@ acllog-max-len 128 # # replica-ignore-maxmemory yes -# Redis reclaims expired keys in two ways: upon access when those keys are +# KeyDB reclaims expired keys in two ways: upon access when those keys are # found to be expired, and also in background, in what is called the # "active expire key". The key space is slowly and interactively scanned # looking for expired keys to reclaim, so that it is possible to free memory @@ -1011,63 +1011,17 @@ replica-lazy-flush no lazyfree-lazy-user-del no -################################ THREADED I/O ################################# - -# Redis is mostly single threaded, however there are certain threaded -# operations such as UNLINK, slow I/O accesses and other things that are -# performed on side threads. -# -# Now it is also possible to handle Redis clients socket reads and writes -# in different I/O threads. Since especially writing is so slow, normally -# Redis users use pipelining in order to speed up the Redis performances per -# core, and spawn multiple instances in order to scale more. Using I/O -# threads it is possible to easily speedup two times Redis without resorting -# to pipelining nor sharding of the instance. -# -# By default threading is disabled, we suggest enabling it only in machines -# that have at least 4 or more cores, leaving at least one spare core. -# Using more than 8 threads is unlikely to help much. We also recommend using -# threaded I/O only if you actually have performance problems, with Redis -# instances being able to use a quite big percentage of CPU time, otherwise -# there is no point in using this feature. -# -# So for instance if you have a four cores boxes, try to use 2 or 3 I/O -# threads, if you have a 8 cores, try to use 6 threads. In order to -# enable I/O threads use the following configuration directive: -# -# io-threads 4 -# -# Setting io-threads to 1 will just use the main thread as usual. -# When I/O threads are enabled, we only use threads for writes, that is -# to thread the write(2) syscall and transfer the client buffers to the -# socket. However it is also possible to enable threading of reads and -# protocol parsing using the following configuration directive, by setting -# it to yes: -# -# io-threads-do-reads no -# -# Usually threading reads doesn't help much. -# -# NOTE 1: This configuration directive cannot be changed at runtime via -# CONFIG SET. Aso this feature currently does not work when SSL is -# enabled. -# -# NOTE 2: If you want to test the Redis speedup using redis-benchmark, make -# sure you also run the benchmark itself in threaded mode, using the -# --threads option to match the number of Redis threads, otherwise you'll not -# be able to notice the improvements. - ############################ KERNEL OOM CONTROL ############################## # On Linux, it is possible to hint the kernel OOM killer on what processes # should be killed first when out of memory. # -# Enabling this feature makes Redis actively control the oom_score_adj value +# Enabling this feature makes KeyDB actively control the oom_score_adj value # for all its processes, depending on their role. The default scores will # attempt to have background child processes killed before all others, and # replicas killed before masters. # -# Redis supports three options: +# KeyDB supports three options: # # no: Don't make changes to oom-score-adj (default). # yes: Alias to "relative" see below. @@ -1491,64 +1445,6 @@ latency-monitor-threshold 0 # specify at least one of K or E, no events will be delivered. notify-keyspace-events "" -############################### GOPHER SERVER ################################# - -# KeyDB contains an implementation of the Gopher protocol, as specified in -# the RFC 1436 (https://www.ietf.org/rfc/rfc1436.txt). -# -# The Gopher protocol was very popular in the late '90s. It is an alternative -# to the web, and the implementation both server and client side is so simple -# that the KeyDB server has just 100 lines of code in order to implement this -# support. -# -# What do you do with Gopher nowadays? Well Gopher never *really* died, and -# lately there is a movement in order for the Gopher more hierarchical content -# composed of just plain text documents to be resurrected. Some want a simpler -# internet, others believe that the mainstream internet became too much -# controlled, and it's cool to create an alternative space for people that -# want a bit of fresh air. -# -# Anyway for the 10nth birthday of the KeyDB, we gave it the Gopher protocol -# as a gift. -# -# --- HOW IT WORKS? --- -# -# The KeyDB Gopher support uses the inline protocol of KeyDB, and specifically -# two kind of inline requests that were anyway illegal: an empty request -# or any request that starts with "/" (there are no KeyDB commands starting -# with such a slash). Normal RESP2/RESP3 requests are completely out of the -# path of the Gopher protocol implementation and are served as usual as well. -# -# If you open a connection to KeyDB when Gopher is enabled and send it -# a string like "/foo", if there is a key named "/foo" it is served via the -# Gopher protocol. -# -# In order to create a real Gopher "hole" (the name of a Gopher site in Gopher -# talking), you likely need a script like the following: -# -# https://github.com/antirez/gopher2redis -# -# --- SECURITY WARNING --- -# -# If you plan to put KeyDB on the internet in a publicly accessible address -# to server Gopher pages MAKE SURE TO SET A PASSWORD to the instance. -# Once a password is set: -# -# 1. The Gopher server (when enabled, not by default) will still serve -# content via Gopher. -# 2. However other commands cannot be called before the client will -# authenticate. -# -# So use the 'requirepass' option to protect your instance. -# -# Note that Gopher is not currently supported when 'io-threads-do-reads' -# is enabled. -# -# To enable Gopher support, uncomment the following line and set the option -# from no (the default) to yes. -# -# gopher-enabled no - ############################### ADVANCED CONFIG ############################### # Hashes are encoded using a memory efficient data structure when they have a @@ -1861,14 +1757,14 @@ 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 Redis to specific +# It is possible to pin different threads and processes of KeyDB to specific # CPUs in your system, in order to maximize the performances of the server. -# This is useful both in order to pin different Redis threads in different -# CPUs, but also in order to make sure that multiple Redis instances running +# This is useful both in order to pin different KeyDB threads in different +# CPUs, but also in order to make sure that multiple KeyDB 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 this via Redis configuration directly, both in Linux and FreeBSD. +# possible to this via KeyDB configuration directly, both in Linux and FreeBSD. # # You can pin the server/IO threads, bio threads, aof rewrite child process, and # the bgsave child process. The syntax to specify the cpu list is the same as