chg: Bump deps, bump config file to valkey 8

pull/963/head
Raphaël Vinot 2024-10-17 15:17:30 +02:00
parent 3acd76114b
commit 628ba438d7
4 changed files with 592 additions and 271 deletions

365
cache/cache.conf vendored
View File

@ -51,6 +51,7 @@
#
# loadmodule /path/to/my_module.so
# loadmodule /path/to/other_module.so
# loadmodule /path/to/args_module.so [arg [arg ...]]
################################## NETWORK #####################################
@ -86,7 +87,7 @@
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bind 127.0.0.1 -::1
# By default, outgoing connections (from replica to master, from Sentinel to
# By default, outgoing connections (from replica to primary, from Sentinel to
# instances, cluster bus, etc.) are not bound to a specific local address. In
# most cases, this means the operating system will handle that based on routing
# and the interface through which the connection goes out.
@ -152,6 +153,9 @@ tcp-backlog 511
# incoming connections. There is no default, so the server will not listen
# on a unix socket when not specified.
#
# unixsocket /run/valkey.sock
# unixsocketgroup wheel
# unixsocketperm 700
unixsocket cache.sock
unixsocketperm 700
@ -192,7 +196,7 @@ tcp-keepalive 300
# tls-port 6379
# Configure a X.509 certificate and private key to use for authenticating the
# server to connected clients, masters or cluster peers. These files should be
# server to connected clients, primaries or cluster peers. These files should be
# PEM formatted.
#
# tls-cert-file valkey.crt
@ -204,7 +208,7 @@ tcp-keepalive 300
# tls-key-file-pass secret
# Normally the server uses the same certificate for both server functions (accepting
# connections) and client functions (replicating from a master, establishing
# connections) and client functions (replicating from a primary, establishing
# cluster bus connections, etc.).
#
# Sometimes certificates are issued with attributes that designate them as
@ -244,7 +248,7 @@ tcp-keepalive 300
# tls-auth-clients optional
# By default, a replica does not attempt to establish a TLS connection
# with its master.
# with its primary.
#
# Use the following directive to enable TLS on replication links.
#
@ -328,7 +332,7 @@ daemonize yes
#
# When the server runs non daemonized, no pid file is created if none is
# specified in the configuration. When the server is daemonized, the pid file
# is used even if not specified, defaulting to "/var/run/redis.pid".
# is used even if not specified, defaulting to "/var/run/valkey.pid".
#
# Creating a pid file is best effort: if the server is not able to create it
# nothing bad happens, the server will start and run normally.
@ -356,7 +360,7 @@ logfile ""
# syslog-enabled no
# Specify the syslog identity.
# syslog-ident redis
# syslog-ident valkey
# Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7.
# syslog-facility local0
@ -385,6 +389,14 @@ databases 16
# ASCII art logo in startup logs by setting the following option to yes.
always-show-logo no
# User data, including keys, values, client names, and ACL usernames, can be
# logged as part of assertions and other error cases. To prevent sensitive user
# information, such as PII, from being recorded in the server log file, this
# user data is hidden from the log by default. If you need to log user data for
# debugging or troubleshooting purposes, you can disable this feature by
# changing the config value to no.
hide-user-data-from-log yes
# By default, the server modifies the process title (as seen in 'top' and 'ps') to
# provide some runtime information. It is possible to disable this and leave
# the process name as executed by setting the following to no.
@ -412,6 +424,15 @@ proc-title-template "{title} {listen-addr} {server-mode}"
# is derived from the environment variables.
locale-collate ""
# Valkey is largely compatible with Redis OSS, apart from a few cases where
# Valkey identifies itself itself as "Valkey" rather than "Redis". Extended
# Redis OSS compatibility mode makes Valkey pretend to be Redis. Enable this
# only if you have problems with tools or clients. This is a temporary
# configuration added in Valkey 8.0 and is scheduled to have no effect in Valkey
# 9.0 and be completely removed in Valkey 10.0.
#
# extended-redis-compatibility no
################################ SNAPSHOTTING ################################
# Save the DB to disk.
@ -433,6 +454,7 @@ locale-collate ""
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000
save 3600 1
# By default the server will stop accepting writes if RDB snapshots are enabled
@ -472,7 +494,7 @@ rdbchecksum yes
# no - Never perform full sanitization
# yes - Always perform full sanitization
# clients - Perform full sanitization only for user connections.
# Excludes: RDB files, RESTORE commands received from the master
# Excludes: RDB files, RESTORE commands received from the primary
# connection, and client connections which have the
# skip-sanitize-payload ACL flag.
# The default should be 'clients' but since it currently affects cluster
@ -486,13 +508,13 @@ dbfilename dump.rdb
# Remove RDB files used by replication in instances without persistence
# enabled. By default this option is disabled, however there are environments
# where for regulations or other security concerns, RDB files persisted on
# disk by masters in order to feed replicas, or stored on disk by replicas
# disk by primaries in order to feed replicas, or stored on disk by replicas
# in order to load them for the initial synchronization, should be deleted
# ASAP. Note that this option ONLY WORKS in instances that have both AOF
# and RDB persistence disabled, otherwise is completely ignored.
#
# An alternative (and sometimes better) way to obtain the same effect is
# to use diskless replication on both master and replicas instances. However
# to use diskless replication on both primary and replicas instances. However
# in the case of replicas, diskless is not always an option.
rdb-del-sync-files no
@ -503,6 +525,9 @@ rdb-del-sync-files no
#
# The Append Only File will also be created inside this directory.
#
# The Cluster config file is written relative this directory, if the
# 'cluster-config-file' configuration directive is a relative path.
#
# Note that you must specify a directory here, not a file name.
dir ./
@ -516,38 +541,38 @@ dir ./
# | (receive writes) | | (exact copy) |
# +------------------+ +---------------+
#
# 1) Replication is asynchronous, but you can configure a master to
# 1) Replication is asynchronous, but you can configure a primary to
# stop accepting writes if it appears to be not connected with at least
# a given number of replicas.
# 2) Replicas are able to perform a partial resynchronization with the
# master if the replication link is lost for a relatively small amount of
# primary if the replication link is lost for a relatively small amount of
# time. You may want to configure the replication backlog size (see the next
# sections of this file) with a sensible value depending on your needs.
# 3) Replication is automatic and does not need user intervention. After a
# network partition replicas automatically try to reconnect to masters
# network partition replicas automatically try to reconnect to primaries
# and resynchronize with them.
#
# replicaof <masterip> <masterport>
# replicaof <primary_ip> <primary_port>
# If the master is password protected (using the "requirepass" configuration
# If the primary is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the replica to authenticate before
# starting the replication synchronization process, otherwise the master will
# starting the replication synchronization process, otherwise the primary will
# refuse the replica request.
#
# masterauth <master-password>
# primaryauth <primary-password>
#
# However this is not enough if you are using ACLs
# and the default user is not capable of running the PSYNC
# command and/or other commands needed for replication. In this case it's
# better to configure a special user to use with replication, and specify the
# masteruser configuration as such:
# primaryuser configuration as such:
#
# masteruser <username>
# primaryuser <username>
#
# When masteruser is specified, the replica will authenticate against its
# master using the new AUTH form: AUTH <username> <password>.
# When primaryuser is specified, the replica will authenticate against its
# primary using the new AUTH form: AUTH <username> <password>.
# When a replica loses its connection with the master, or when the replication
# When a replica loses its connection with the primary, or when the replication
# is still in progress, the replica can act in two different ways:
#
# 1) if replica-serve-stale-data is set to 'yes' (the default) the replica will
@ -565,7 +590,7 @@ replica-serve-stale-data yes
# You can configure a replica instance to accept writes or not. Writing against
# a replica instance may be useful to store some ephemeral data (because data
# written on a replica will be easily deleted after resync with the master) but
# written on a replica will be easily deleted after resync with the primary) but
# may also cause problems if clients are writing to it because of a
# misconfiguration.
#
@ -583,15 +608,15 @@ replica-read-only yes
#
# New replicas and reconnecting replicas that are not able to continue the
# replication process just receiving differences, need to do what is called a
# "full synchronization". An RDB file is transmitted from the master to the
# "full synchronization". An RDB file is transmitted from the primary to the
# replicas.
#
# The transmission can happen in two different ways:
#
# 1) Disk-backed: The master creates a new process that writes the RDB
# 1) Disk-backed: The primary creates a new process that writes the RDB
# file on disk. Later the file is transferred by the parent
# process to the replicas incrementally.
# 2) Diskless: The master creates a new process that directly writes the
# 2) Diskless: The primary creates a new process that directly writes the
# RDB file to replica sockets, without touching the disk at all.
#
# With disk-backed replication, while the RDB file is generated, more replicas
@ -600,7 +625,7 @@ replica-read-only yes
# once the transfer starts, new replicas arriving will be queued and a new
# transfer will start when the current one terminates.
#
# When diskless replication is used, the master waits a configurable amount of
# When diskless replication is used, the primary waits a configurable amount of
# time (in seconds) before starting the transfer in the hope that multiple
# replicas will arrive and the transfer can be parallelized.
#
@ -630,15 +655,15 @@ repl-diskless-sync-max-replicas 0
# WARNING: Since in this setup the replica does not immediately store an RDB on
# disk, it may cause data loss during failovers. RDB diskless load + server
# modules not handling I/O reads may cause the server to abort in case of I/O errors
# during the initial synchronization stage with the master.
# during the initial synchronization stage with the primary.
# -----------------------------------------------------------------------------
#
# Replica can load the RDB it reads from the replication link directly from the
# socket, or store the RDB to a file and read that file after it was completely
# received from the master.
# received from the primary.
#
# In many cases the disk is slower than the network, and storing and loading
# the RDB file may increase replication time (and even increase the master's
# the RDB file may increase replication time (and even increase the primary's
# Copy on Write memory and replica buffers).
# However, when parsing the RDB file directly from the socket, in order to avoid
# data loss it's only safe to flush the current dataset when the new dataset is
@ -649,7 +674,7 @@ repl-diskless-sync-max-replicas 0
# "swapdb" - Keep current db contents in RAM while parsing the data directly
# from the socket. Replicas in this mode can keep serving current
# dataset while replication is in progress, except for cases where
# they can't recognize master as having a data set from same
# they can't recognize primary as having a data set from same
# replication history.
# Note that this requires sufficient memory, if you don't have it,
# you risk an OOM kill.
@ -658,6 +683,29 @@ repl-diskless-sync-max-replicas 0
# during replication.
repl-diskless-load disabled
# This dual channel replication sync feature optimizes the full synchronization process
# between a primary and its replicas. When enabled, it reduces both memory and CPU load
# on the primary server.
#
# How it works:
# 1. During full sync, instead of accumulating replication data on the primary server,
# the data is sent directly to the syncing replica.
# 2. The primary's background save (bgsave) process streams the RDB snapshot directly
# to the replica over a separate connection.
#
# Tradeoff:
# While this approach reduces load on the primary, it shifts the burden of storing
# the replication buffer to the replica. This means the replica must have sufficient
# memory to accommodate the buffer during synchronization. However, this tradeoff is
# generally beneficial as it prevents potential performance degradation on the primary
# server, which is typically handling more critical operations.
#
# 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.
dual-channel-replication-enabled no
# Master send PINGs to its replicas in a predefined interval. It's possible to
# change this interval with the repl_ping_replica_period option. The default
# value is 10 seconds.
@ -668,11 +716,11 @@ repl-diskless-load disabled
#
# 1) Bulk transfer I/O during SYNC, from the point of view of replica.
# 2) Master timeout from the point of view of replicas (data, pings).
# 3) Replica timeout from the point of view of masters (REPLCONF ACK pings).
# 3) Replica timeout from the point of view of primaries (REPLCONF ACK pings).
#
# It is important to make sure that this value is greater than the value
# specified for repl-ping-replica-period otherwise a timeout will be detected
# every time there is low traffic between the master and the replica. The default
# every time there is low traffic between the primary and the replica. The default
# value is 60 seconds.
#
# repl-timeout 60
@ -688,7 +736,7 @@ repl-diskless-load disabled
# be reduced but more bandwidth will be used for replication.
#
# By default we optimize for low latency, but in very high traffic conditions
# or when the master and replicas are many hops away, turning this to "yes" may
# or when the primary and replicas are many hops away, turning this to "yes" may
# be a good idea.
repl-disable-tcp-nodelay no
@ -703,15 +751,15 @@ repl-disable-tcp-nodelay no
#
# The backlog is only allocated if there is at least one replica connected.
#
# repl-backlog-size 1mb
# repl-backlog-size 10mb
# After a master has no connected replicas for some time, the backlog will be
# After a primary has no connected replicas for some time, the backlog will be
# freed. The following option configures the amount of seconds that need to
# elapse, starting from the time the last replica disconnected, for the backlog
# buffer to be freed.
#
# Note that replicas never free the backlog for timeout, since they may be
# promoted to masters later, and should be able to correctly "partially
# promoted to primaries later, and should be able to correctly "partially
# resynchronize" with other replicas: hence they should always accumulate backlog.
#
# A value of 0 means to never release the backlog.
@ -720,21 +768,21 @@ repl-disable-tcp-nodelay no
# The replica priority is an integer number published by the server in the INFO
# output. It is used by Sentinel in order to select a replica to promote
# into a master if the master is no longer working correctly.
# into a primary if the primary is no longer working correctly.
#
# A replica with a low priority number is considered better for promotion, so
# for instance if there are three replicas with priority 10, 100, 25 Sentinel
# will pick the one with priority 10, that is the lowest.
#
# However a special priority of 0 marks the replica as not able to perform the
# role of master, so a replica with priority of 0 will never be selected by
# role of primary, so a replica with priority of 0 will never be selected by
# Sentinel for promotion.
#
# By default the priority is 100.
replica-priority 100
# The propagation error behavior controls how the server will behave when it is
# unable to handle a command being processed in the replication stream from a master
# unable to handle a command being processed in the replication stream from a primary
# or processed while reading from an AOF file. Errors that occur during propagation
# are unexpected, and can cause data inconsistency.
#
@ -747,7 +795,7 @@ replica-priority 100
# propagation-error-behavior ignore
# Replica ignore disk write errors controls the behavior of a replica when it is
# unable to persist a write command received from its master to disk. By default,
# unable to persist a write command received from its primary to disk. By default,
# this configuration is set to 'no' and will crash the replica in this condition.
# It is not recommended to change this default.
#
@ -756,16 +804,16 @@ replica-priority 100
# -----------------------------------------------------------------------------
# By default, Sentinel includes all replicas in its reports. A replica
# can be excluded from Sentinel's announcements. An unannounced replica
# will be ignored by the 'sentinel replicas <master>' command and won't be
# will be ignored by the 'sentinel replicas <primary>' command and won't be
# exposed to Sentinel's clients.
#
# This option does not change the behavior of replica-priority. Even with
# replica-announced set to 'no', the replica can be promoted to master. To
# replica-announced set to 'no', the replica can be promoted to primary. To
# prevent this behavior, set replica-priority to 0.
#
# replica-announced yes
# It is possible for a master to stop accepting writes if there are less than
# It is possible for a primary to stop accepting writes if there are less than
# N replicas connected, having a lag less or equal than M seconds.
#
# The N replicas need to be in "online" state.
@ -787,18 +835,18 @@ replica-priority 100
# By default min-replicas-to-write is set to 0 (feature disabled) and
# min-replicas-max-lag is set to 10.
# A master is able to list the address and port of the attached
# A primary is able to list the address and port of the attached
# replicas in different ways. For example the "INFO replication" section
# offers this information, which is used, among other tools, by
# Sentinel in order to discover replica instances.
# Another place where this info is available is in the output of the
# "ROLE" command of a master.
# "ROLE" command of a primary.
#
# The listed IP address and port normally reported by a replica is
# obtained in the following way:
#
# IP: The address is auto detected by checking the peer address
# of the socket used by the replica to connect with the master.
# of the socket used by the replica to connect with the primary.
#
# Port: The port is communicated by the replica during the replication
# handshake, and is normally the port that the replica is using to
@ -807,7 +855,7 @@ replica-priority 100
# However when port forwarding or Network Address Translation (NAT) is
# used, the replica may actually be reachable via different IP and port
# pairs. The following two options can be used by a replica in order to
# report to its master a specific set of IP and port, so that both INFO
# report to its primary a specific set of IP and port, so that both INFO
# and ROLE will report those values.
#
# There is no need to use both the options if you need to override just
@ -1151,7 +1199,8 @@ acllog-max-len 128
# configuration directive.
#
# The default of 5 produces good enough results. 10 Approximates very closely
# true LRU but costs more CPU. 3 is faster but not very accurate.
# true LRU but costs more CPU. 3 is faster but not very accurate. The maximum
# value that can be set is 64.
#
# maxmemory-samples 5
@ -1164,11 +1213,11 @@ acllog-max-len 128
# maxmemory-eviction-tenacity 10
# By default a replica will ignore its maxmemory setting
# (unless it is promoted to master after a failover or manually). It means
# that the eviction of keys will be just handled by the master, sending the
# DEL commands to the replica as keys evict in the master side.
# (unless it is promoted to primary after a failover or manually). It means
# that the eviction of keys will be just handled by the primary, sending the
# DEL commands to the replica as keys evict in the primary side.
#
# This behavior ensures that masters and replicas stay consistent, and is usually
# This behavior ensures that primaries and replicas stay consistent, and is usually
# what you want, however if your replica is writable, or you want the replica
# to have a different memory setting, and you are sure all the writes performed
# to the replica are idempotent, then you may change this default (but be sure
@ -1179,7 +1228,7 @@ acllog-max-len 128
# be larger on the replica, or data structures may sometimes take more memory
# and so forth). So make sure you monitor your replicas and make sure they
# have enough memory to never hit a real out-of-memory condition before the
# master hits the configured maxmemory setting.
# primary hits the configured maxmemory setting.
#
# replica-ignore-maxmemory yes
@ -1202,8 +1251,8 @@ acllog-max-len 128
############################# LAZY FREEING ####################################
# The server has two primitives to delete keys. One is called DEL and is a blocking
# deletion of the object. It means that the server stops processing new commands
# When keys are deleted, the served has historically freed their memory using
# blocking operations. It means that the server stopped processing new commands
# in order to reclaim all the memory associated with an object in a synchronous
# way. If the key deleted is associated with a small object, the time needed
# in order to execute the DEL command is very small and comparable to most other
@ -1211,15 +1260,16 @@ acllog-max-len 128
# aggregated value containing millions of elements, the server can block for
# a long time (even seconds) in order to complete the operation.
#
# For the above reasons the server also offers non blocking deletion primitives
# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
# FLUSHDB commands, in order to reclaim memory in background. Those commands
# are executed in constant time. Another thread will incrementally free the
# object in the background as fast as possible.
# For the above reasons, lazy freeing (or asynchronous freeing), has been
# introduced. With lazy freeing, keys are deleted in constant time. Another
# thread will incrementally free the object in the background as fast as
# possible.
#
# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
# It's up to the design of the application to understand when it is a good
# idea to use one or the other. However the server sometimes has to
# Starting from Valkey 8.0, lazy freeing is enabled by default. It is possible
# to retain the synchronous freeing behaviour by setting the lazyfree related
# configuration directives to 'no'.
# Commands like DEL, FLUSHALL and FLUSHDB delete keys, but the server can also
# delete keys or flush the whole database as a side effect of other operations.
# Specifically the server deletes objects independently of a user call in the
# following scenarios:
@ -1236,32 +1286,34 @@ acllog-max-len 128
# itself removes any old content of the specified key in order to replace
# it with the specified string.
# 4) During replication, when a replica performs a full resynchronization with
# its master, the content of the whole database is removed in order to
# its primary, the content of the whole database is removed in order to
# load the RDB file just transferred.
#
# In all the above cases the default is to delete objects in a blocking way,
# like if DEL was called. However you can configure each case specifically
# in order to instead release memory in a non-blocking way like if UNLINK
# was called, using the following configuration directives.
# In all the above cases, the default is to release memory in a non-blocking
# way.
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
# It is also possible, for the case when to replace the user code DEL calls
# with UNLINK calls is not easy, to modify the default behavior of the DEL
# command to act exactly like UNLINK, using the following configuration
# directive:
# For keys deleted using the DEL command, lazy freeing is controlled by the
# configuration directive 'lazyfree-lazy-user-del'. The default is 'yes'. The
# UNLINK command is identical to the DEL command, except that UNLINK always
# frees the memory lazily, regardless of this configuration directive:
lazyfree-lazy-user-del no
lazyfree-lazy-user-del yes
# FLUSHDB, FLUSHALL, SCRIPT FLUSH and FUNCTION FLUSH support both asynchronous and synchronous
# deletion, which can be controlled by passing the [SYNC|ASYNC] flags into the
# commands. When neither flag is passed, this directive will be used to determine
# if the data should be deleted asynchronously.
lazyfree-lazy-user-flush no
# There are many problems with running flush synchronously. Even in single CPU
# environments, the thread managers should balance between the freeing and
# serving incoming requests. The default value is yes.
lazyfree-lazy-user-flush yes
################################ THREADED I/O #################################
@ -1277,9 +1329,8 @@ lazyfree-lazy-user-flush no
# 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
# that have at least 3 or more cores, leaving at least one spare core.
# We also recommend using threaded I/O only if you actually have performance problems, with
# instances being able to use a quite big percentage of CPU time, otherwise
# there is no point in using this feature.
#
@ -1290,21 +1341,23 @@ lazyfree-lazy-user-flush no
# 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:
# When I/O threads are enabled, we use threads for reads and writes, that is
# to thread the write and read syscall and transfer the client buffers to the
# socket and to enable threading of reads and protocol parsing.
#
# io-threads-do-reads no
# When multiple commands are parsed by the I/O threads and ready for execution,
# we take advantage of knowing the next set of commands and prefetch their
# required dictionary entries in a batch. This reduces memory access costs.
#
# Usually threading reads doesn't help much.
# The optimal batch size depends on the specific workflow of the user.
# The default batch size is 16, which can be modified using the
# 'prefetch-batch-max-size' config.
#
# NOTE 1: This configuration directive cannot be changed at runtime via
# CONFIG SET. Also, this feature currently does not work when SSL is
# enabled.
# When the config is set to 0, prefetching is disabled.
#
# NOTE 2: If you want to test the server speedup using valkey-benchmark, make
# prefetch-batch-max-size 16
#
# NOTE: If you want to test the server speedup using valkey-benchmark, make
# sure you also run the benchmark itself in threaded mode, using the
# --threads option to match the number of server threads, otherwise you'll not
# be able to notice the improvements.
@ -1317,7 +1370,7 @@ lazyfree-lazy-user-flush no
# Enabling this feature makes the server 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.
# replicas killed before primaries.
#
# The server supports these options:
#
@ -1331,7 +1384,7 @@ lazyfree-lazy-user-flush no
oom-score-adj no
# When oom-score-adj is used, this directive controls the specific values used
# for master, replica and background child processes. Values range -2000 to
# for primary, replica and background child processes. Values range -2000 to
# 2000 (higher means more likely to be killed).
#
# Unprivileged processes (not root, and without CAP_SYS_RESOURCE capabilities)
@ -1371,6 +1424,10 @@ disable-thp yes
# If the AOF is enabled on startup the server will load the AOF, that is the file
# with the better durability guarantees.
#
# Note that changing this value in a config file of an existing database and
# restarting the server can lead to data loss. A conversion needs to be done
# by setting it via CONFIG command on a live server first.
#
# Please check https://valkey.io/topics/persistence for more information.
appendonly no
@ -1515,7 +1572,7 @@ aof-timestamp-enabled no
# Maximum time to wait for replicas when shutting down, in seconds.
#
# During shut down, a grace period allows any lagging replicas to catch up with
# the latest replication offset before the master exists. This period can
# the latest replication offset before the primary exists. This period can
# prevent data loss, especially for deployments without configured disk backups.
#
# The 'shutdown-timeout' value is the grace period's duration in seconds. It is
@ -1591,7 +1648,7 @@ aof-timestamp-enabled no
# you to specify the cluster bus port when executing cluster meet.
# cluster-port 0
# A replica of a failing master will avoid to start a failover if its data
# A replica of a failing primary will avoid to start a failover if its data
# looks too old.
#
# There is no simple way for a replica to actually have an exact measure of
@ -1599,35 +1656,35 @@ aof-timestamp-enabled no
#
# 1) If there are multiple replicas able to failover, they exchange messages
# in order to try to give an advantage to the replica with the best
# replication offset (more data from the master processed).
# replication offset (more data from the primary processed).
# Replicas will try to get their rank by offset, and apply to the start
# of the failover a delay proportional to their rank.
#
# 2) Every single replica computes the time of the last interaction with
# its master. This can be the last ping or command received (if the master
# its primary. This can be the last ping or command received (if the primary
# is still in the "connected" state), or the time that elapsed since the
# disconnection with the master (if the replication link is currently down).
# disconnection with the primary (if the replication link is currently down).
# If the last interaction is too old, the replica will not try to failover
# at all.
#
# The point "2" can be tuned by user. Specifically a replica will not perform
# the failover if, since the last interaction with the master, the time
# the failover if, since the last interaction with the primary, the time
# elapsed is greater than:
#
# (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period
#
# So for example if node-timeout is 30 seconds, and the cluster-replica-validity-factor
# is 10, and assuming a default repl-ping-replica-period of 10 seconds, the
# replica will not try to failover if it was not able to talk with the master
# replica will not try to failover if it was not able to talk with the primary
# for longer than 310 seconds.
#
# A large cluster-replica-validity-factor may allow replicas with too old data to failover
# a master, while a too small value may prevent the cluster from being able to
# a primary, while a too small value may prevent the cluster from being able to
# elect a replica at all.
#
# For maximum availability, it is possible to set the cluster-replica-validity-factor
# to a value of 0, which means, that replicas will always try to failover the
# master regardless of the last time they interacted with the master.
# primary regardless of the last time they interacted with the primary.
# (However they'll always try to apply a delay proportional to their
# offset rank).
#
@ -1636,19 +1693,19 @@ aof-timestamp-enabled no
#
# cluster-replica-validity-factor 10
# Cluster replicas are able to migrate to orphaned masters, that are masters
# Cluster replicas are able to migrate to orphaned primaries, that are primaries
# that are left without working replicas. This improves the cluster ability
# to resist to failures as otherwise an orphaned master can't be failed over
# to resist to failures as otherwise an orphaned primary can't be failed over
# in case of failure if it has no working replicas.
#
# Replicas migrate to orphaned masters only if there are still at least a
# given number of other working replicas for their old master. This number
# Replicas migrate to orphaned primaries only if there are still at least a
# given number of other working replicas for their old primary. This number
# is the "migration barrier". A migration barrier of 1 means that a replica
# will migrate only if there is at least 1 other working replica for its master
# will migrate only if there is at least 1 other working replica for its primary
# and so forth. It usually reflects the number of replicas you want for every
# master in your cluster.
# primary in your cluster.
#
# Default is 1 (replicas migrate only if their masters remain with at least
# Default is 1 (replicas migrate only if their primaries remain with at least
# one replica). To disable migration just set it to a very large value or
# set cluster-allow-replica-migration to 'no'.
# A value of 0 can be set but is useful only for debugging and dangerous
@ -1657,8 +1714,10 @@ aof-timestamp-enabled no
# cluster-migration-barrier 1
# Turning off this option allows to use less automatic cluster configuration.
# It both disables migration to orphaned masters and migration from masters
# that became empty.
# It disables migration of replicas to orphaned primaries. Masters that become
# empty due to losing their last slots to another primary will not automatically
# replicate from the primary that took over their last slots. Instead, they will
# remain as empty primaries without any slots.
#
# Default is 'yes' (allow automatic migrations).
#
@ -1678,7 +1737,7 @@ aof-timestamp-enabled no
# cluster-require-full-coverage yes
# This option, when set to yes, prevents replicas from trying to failover its
# master during master failures. However the replica can still perform a
# primary during primary failures. However the replica can still perform a
# manual failover, if forced to do so.
#
# This is useful in different scenarios, especially in the case of multiple
@ -1697,9 +1756,9 @@ aof-timestamp-enabled no
#
# The second use case is for configurations that don't meet the recommended
# three shards but want to enable cluster mode and scale later. A
# master outage in a 1 or 2 shard configuration causes a read/write outage to the
# primary outage in a 1 or 2 shard configuration causes a read/write outage to the
# entire cluster without this option set, with it set there is only a write outage.
# Without a quorum of masters, slot ownership will not change automatically.
# Without a quorum of primaries, slot ownership will not change automatically.
#
# cluster-allow-reads-when-down no
@ -1754,6 +1813,26 @@ aof-timestamp-enabled no
#
# cluster-preferred-endpoint-type ip
# The cluster blacklist is used when removing a node from the cluster completely.
# When CLUSTER FORGET is called for a node, that node is put into the blacklist for
# some time so that when gossip messages are received from other nodes that still
# remember it, it is not re-added. This gives time for CLUSTER FORGET to be sent to
# every node in the cluster. The blacklist TTL is 60 seconds by default, which should
# be sufficient for most clusters, but you may considering increasing this if you see
# nodes getting re-added while using CLUSTER FORGET.
#
# cluster-blacklist-ttl 60
# Clusters can be configured to track per-slot resource statistics,
# which are accessible by the CLUSTER SLOT-STATS command.
#
# By default, the 'cluster-slot-stats-enabled' is disabled, and only 'key-count' is captured.
# By enabling the 'cluster-slot-stats-enabled' config, the cluster will begin to capture advanced statistics.
# These statistics can be leveraged to assess general slot usage trends, identify hot / cold slots,
# migrate slots for a balanced cluster workload, and / or re-write application logic to better utilize slots.
#
# cluster-slot-stats-enabled no
# In order to setup your cluster make sure to read the documentation
# available at https://valkey.io web site.
@ -1765,22 +1844,28 @@ aof-timestamp-enabled no
#
# In order to make a cluster work in such environments, a static
# configuration where each node knows its public address is needed. The
# following four options are used for this scope, and are:
# following options are used for this scope, and are:
#
# * cluster-announce-ip
# * cluster-announce-client-ipv4
# * cluster-announce-client-ipv6
# * cluster-announce-port
# * cluster-announce-tls-port
# * cluster-announce-bus-port
#
# Each instructs the node about its address, client ports (for connections
# without and with TLS) and cluster message bus port. The information is then
# published in the header of the bus packets so that other nodes will be able to
# correctly map the address of the node publishing the information.
# Each instructs the node about its address, possibly other addresses to expose
# to clients, client ports (for connections without and with TLS) and cluster
# message bus port. The information is then published in the bus packets so that
# other nodes will be able to correctly map the address of the node publishing
# the information.
#
# If tls-cluster is set to yes and cluster-announce-tls-port is omitted or set
# to zero, then cluster-announce-port refers to the TLS port. Note also that
# cluster-announce-tls-port has no effect if tls-cluster is set to no.
#
# If cluster-announce-client-ipv4 and cluster-announce-client-ipv6 are omitted,
# then cluster-announce-ip is exposed to clients.
#
# If the above options are not used, the normal cluster auto-detection
# will be used instead.
#
@ -1792,6 +1877,8 @@ aof-timestamp-enabled no
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-client-ipv4 123.123.123.5
# cluster-announce-client-ipv6 2001:db8::8a2e:370:7334
# cluster-announce-tls-port 6379
# cluster-announce-port 0
# cluster-announce-bus-port 6380
@ -2059,7 +2146,7 @@ client-output-buffer-limit pubsub 32mb 8mb 60
# amount by default in order to avoid that a protocol desynchronization (for
# instance due to a bug in the client) will lead to unbound memory usage in
# the query buffer. However you can configure it here if you have very special
# needs, such us huge multi/exec requests or alike.
# needs, such as a command with huge argument, or huge multi/exec requests or alike.
#
# client-query-buffer-limit 1gb
@ -2184,6 +2271,26 @@ rdb-save-incremental-fsync yes
# lfu-log-factor 10
# lfu-decay-time 1
# The maximum number of new client connections accepted per event-loop cycle. This configuration
# is set independently for TLS connections.
#
# By default, up to 10 new connection will be accepted per event-loop cycle for normal connections
# and up to 1 new connection per event-loop cycle for TLS connections.
#
# Adjusting this to a larger number can slightly improve efficiency for new connections
# at the risk of causing timeouts for regular commands on established connections. It is
# not advised to change this without ensuring that all clients have limited connection
# pools and exponential backoff in the case of command/connection timeouts.
#
# If your application is establishing a large number of new connections per second you should
# also consider tuning the value of tcp-backlog, which allows the kernel to buffer more
# pending connections before dropping or rejecting connections.
#
# max-new-connections-per-cycle 10
# max-new-tls-connections-per-cycle 1
########################### ACTIVE DEFRAGMENTATION #######################
#
# What is active defragmentation?
@ -2264,17 +2371,17 @@ jemalloc-bg-thread yes
# the bgsave child process. The syntax to specify the cpu list is the same as
# the taskset command:
#
# Set redis server/io threads to cpu affinity 0,2,4,6:
# server_cpulist 0-7:2
# 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
# bio-cpulist 1,3
#
# Set aof rewrite child process to cpu affinity 8,9,10,11:
# aof_rewrite_cpulist 8-11
# aof-rewrite-cpulist 8-11
#
# Set bgsave child process to cpu affinity 1,10,11
# bgsave_cpulist 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
@ -2282,3 +2389,9 @@ jemalloc-bg-thread yes
# to suppress
#
# ignore-warnings ARM64-COW-BUG
# Inform Valkey of the availability zone if running in a cloud environment. Currently
# this is only exposed via the info command for clients to use, but in the future we
# we may also use this when making decisions for replication.
#
# availability-zone "zone-name"

View File

@ -51,6 +51,7 @@
#
# loadmodule /path/to/my_module.so
# loadmodule /path/to/other_module.so
# loadmodule /path/to/args_module.so [arg [arg ...]]
################################## NETWORK #####################################
@ -86,7 +87,7 @@
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bind 127.0.0.1 -::1
# By default, outgoing connections (from replica to master, from Sentinel to
# By default, outgoing connections (from replica to primary, from Sentinel to
# instances, cluster bus, etc.) are not bound to a specific local address. In
# most cases, this means the operating system will handle that based on routing
# and the interface through which the connection goes out.
@ -152,6 +153,9 @@ tcp-backlog 511
# incoming connections. There is no default, so the server will not listen
# on a unix socket when not specified.
#
# unixsocket /run/valkey.sock
# unixsocketgroup wheel
# unixsocketperm 700
unixsocket indexing.sock
unixsocketperm 700
@ -192,7 +196,7 @@ tcp-keepalive 300
# tls-port 6379
# Configure a X.509 certificate and private key to use for authenticating the
# server to connected clients, masters or cluster peers. These files should be
# server to connected clients, primaries or cluster peers. These files should be
# PEM formatted.
#
# tls-cert-file valkey.crt
@ -204,7 +208,7 @@ tcp-keepalive 300
# tls-key-file-pass secret
# Normally the server uses the same certificate for both server functions (accepting
# connections) and client functions (replicating from a master, establishing
# connections) and client functions (replicating from a primary, establishing
# cluster bus connections, etc.).
#
# Sometimes certificates are issued with attributes that designate them as
@ -244,7 +248,7 @@ tcp-keepalive 300
# tls-auth-clients optional
# By default, a replica does not attempt to establish a TLS connection
# with its master.
# with its primary.
#
# Use the following directive to enable TLS on replication links.
#
@ -328,7 +332,7 @@ daemonize yes
#
# When the server runs non daemonized, no pid file is created if none is
# specified in the configuration. When the server is daemonized, the pid file
# is used even if not specified, defaulting to "/var/run/redis.pid".
# is used even if not specified, defaulting to "/var/run/valkey.pid".
#
# Creating a pid file is best effort: if the server is not able to create it
# nothing bad happens, the server will start and run normally.
@ -356,7 +360,7 @@ logfile ""
# syslog-enabled no
# Specify the syslog identity.
# syslog-ident redis
# syslog-ident valkey
# Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7.
# syslog-facility local0
@ -385,6 +389,14 @@ databases 16
# ASCII art logo in startup logs by setting the following option to yes.
always-show-logo no
# User data, including keys, values, client names, and ACL usernames, can be
# logged as part of assertions and other error cases. To prevent sensitive user
# information, such as PII, from being recorded in the server log file, this
# user data is hidden from the log by default. If you need to log user data for
# debugging or troubleshooting purposes, you can disable this feature by
# changing the config value to no.
hide-user-data-from-log yes
# By default, the server modifies the process title (as seen in 'top' and 'ps') to
# provide some runtime information. It is possible to disable this and leave
# the process name as executed by setting the following to no.
@ -412,6 +424,15 @@ proc-title-template "{title} {listen-addr} {server-mode}"
# is derived from the environment variables.
locale-collate ""
# Valkey is largely compatible with Redis OSS, apart from a few cases where
# Valkey identifies itself itself as "Valkey" rather than "Redis". Extended
# Redis OSS compatibility mode makes Valkey pretend to be Redis. Enable this
# only if you have problems with tools or clients. This is a temporary
# configuration added in Valkey 8.0 and is scheduled to have no effect in Valkey
# 9.0 and be completely removed in Valkey 10.0.
#
# extended-redis-compatibility no
################################ SNAPSHOTTING ################################
# Save the DB to disk.
@ -433,6 +454,7 @@ locale-collate ""
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000
save 3600 1
# By default the server will stop accepting writes if RDB snapshots are enabled
@ -472,7 +494,7 @@ rdbchecksum yes
# no - Never perform full sanitization
# yes - Always perform full sanitization
# clients - Perform full sanitization only for user connections.
# Excludes: RDB files, RESTORE commands received from the master
# Excludes: RDB files, RESTORE commands received from the primary
# connection, and client connections which have the
# skip-sanitize-payload ACL flag.
# The default should be 'clients' but since it currently affects cluster
@ -486,13 +508,13 @@ dbfilename dump.rdb
# Remove RDB files used by replication in instances without persistence
# enabled. By default this option is disabled, however there are environments
# where for regulations or other security concerns, RDB files persisted on
# disk by masters in order to feed replicas, or stored on disk by replicas
# disk by primaries in order to feed replicas, or stored on disk by replicas
# in order to load them for the initial synchronization, should be deleted
# ASAP. Note that this option ONLY WORKS in instances that have both AOF
# and RDB persistence disabled, otherwise is completely ignored.
#
# An alternative (and sometimes better) way to obtain the same effect is
# to use diskless replication on both master and replicas instances. However
# to use diskless replication on both primary and replicas instances. However
# in the case of replicas, diskless is not always an option.
rdb-del-sync-files no
@ -503,6 +525,9 @@ rdb-del-sync-files no
#
# The Append Only File will also be created inside this directory.
#
# The Cluster config file is written relative this directory, if the
# 'cluster-config-file' configuration directive is a relative path.
#
# Note that you must specify a directory here, not a file name.
dir ./
@ -516,38 +541,38 @@ dir ./
# | (receive writes) | | (exact copy) |
# +------------------+ +---------------+
#
# 1) Replication is asynchronous, but you can configure a master to
# 1) Replication is asynchronous, but you can configure a primary to
# stop accepting writes if it appears to be not connected with at least
# a given number of replicas.
# 2) Replicas are able to perform a partial resynchronization with the
# master if the replication link is lost for a relatively small amount of
# primary if the replication link is lost for a relatively small amount of
# time. You may want to configure the replication backlog size (see the next
# sections of this file) with a sensible value depending on your needs.
# 3) Replication is automatic and does not need user intervention. After a
# network partition replicas automatically try to reconnect to masters
# network partition replicas automatically try to reconnect to primaries
# and resynchronize with them.
#
# replicaof <masterip> <masterport>
# replicaof <primary_ip> <primary_port>
# If the master is password protected (using the "requirepass" configuration
# If the primary is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the replica to authenticate before
# starting the replication synchronization process, otherwise the master will
# starting the replication synchronization process, otherwise the primary will
# refuse the replica request.
#
# masterauth <master-password>
# primaryauth <primary-password>
#
# However this is not enough if you are using ACLs
# and the default user is not capable of running the PSYNC
# command and/or other commands needed for replication. In this case it's
# better to configure a special user to use with replication, and specify the
# masteruser configuration as such:
# primaryuser configuration as such:
#
# masteruser <username>
# primaryuser <username>
#
# When masteruser is specified, the replica will authenticate against its
# master using the new AUTH form: AUTH <username> <password>.
# When primaryuser is specified, the replica will authenticate against its
# primary using the new AUTH form: AUTH <username> <password>.
# When a replica loses its connection with the master, or when the replication
# When a replica loses its connection with the primary, or when the replication
# is still in progress, the replica can act in two different ways:
#
# 1) if replica-serve-stale-data is set to 'yes' (the default) the replica will
@ -565,7 +590,7 @@ replica-serve-stale-data yes
# You can configure a replica instance to accept writes or not. Writing against
# a replica instance may be useful to store some ephemeral data (because data
# written on a replica will be easily deleted after resync with the master) but
# written on a replica will be easily deleted after resync with the primary) but
# may also cause problems if clients are writing to it because of a
# misconfiguration.
#
@ -583,15 +608,15 @@ replica-read-only yes
#
# New replicas and reconnecting replicas that are not able to continue the
# replication process just receiving differences, need to do what is called a
# "full synchronization". An RDB file is transmitted from the master to the
# "full synchronization". An RDB file is transmitted from the primary to the
# replicas.
#
# The transmission can happen in two different ways:
#
# 1) Disk-backed: The master creates a new process that writes the RDB
# 1) Disk-backed: The primary creates a new process that writes the RDB
# file on disk. Later the file is transferred by the parent
# process to the replicas incrementally.
# 2) Diskless: The master creates a new process that directly writes the
# 2) Diskless: The primary creates a new process that directly writes the
# RDB file to replica sockets, without touching the disk at all.
#
# With disk-backed replication, while the RDB file is generated, more replicas
@ -600,7 +625,7 @@ replica-read-only yes
# once the transfer starts, new replicas arriving will be queued and a new
# transfer will start when the current one terminates.
#
# When diskless replication is used, the master waits a configurable amount of
# When diskless replication is used, the primary waits a configurable amount of
# time (in seconds) before starting the transfer in the hope that multiple
# replicas will arrive and the transfer can be parallelized.
#
@ -630,15 +655,15 @@ repl-diskless-sync-max-replicas 0
# WARNING: Since in this setup the replica does not immediately store an RDB on
# disk, it may cause data loss during failovers. RDB diskless load + server
# modules not handling I/O reads may cause the server to abort in case of I/O errors
# during the initial synchronization stage with the master.
# during the initial synchronization stage with the primary.
# -----------------------------------------------------------------------------
#
# Replica can load the RDB it reads from the replication link directly from the
# socket, or store the RDB to a file and read that file after it was completely
# received from the master.
# received from the primary.
#
# In many cases the disk is slower than the network, and storing and loading
# the RDB file may increase replication time (and even increase the master's
# the RDB file may increase replication time (and even increase the primary's
# Copy on Write memory and replica buffers).
# However, when parsing the RDB file directly from the socket, in order to avoid
# data loss it's only safe to flush the current dataset when the new dataset is
@ -649,7 +674,7 @@ repl-diskless-sync-max-replicas 0
# "swapdb" - Keep current db contents in RAM while parsing the data directly
# from the socket. Replicas in this mode can keep serving current
# dataset while replication is in progress, except for cases where
# they can't recognize master as having a data set from same
# they can't recognize primary as having a data set from same
# replication history.
# Note that this requires sufficient memory, if you don't have it,
# you risk an OOM kill.
@ -658,6 +683,29 @@ repl-diskless-sync-max-replicas 0
# during replication.
repl-diskless-load disabled
# This dual channel replication sync feature optimizes the full synchronization process
# between a primary and its replicas. When enabled, it reduces both memory and CPU load
# on the primary server.
#
# How it works:
# 1. During full sync, instead of accumulating replication data on the primary server,
# the data is sent directly to the syncing replica.
# 2. The primary's background save (bgsave) process streams the RDB snapshot directly
# to the replica over a separate connection.
#
# Tradeoff:
# While this approach reduces load on the primary, it shifts the burden of storing
# the replication buffer to the replica. This means the replica must have sufficient
# memory to accommodate the buffer during synchronization. However, this tradeoff is
# generally beneficial as it prevents potential performance degradation on the primary
# server, which is typically handling more critical operations.
#
# 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.
dual-channel-replication-enabled no
# Master send PINGs to its replicas in a predefined interval. It's possible to
# change this interval with the repl_ping_replica_period option. The default
# value is 10 seconds.
@ -668,11 +716,11 @@ repl-diskless-load disabled
#
# 1) Bulk transfer I/O during SYNC, from the point of view of replica.
# 2) Master timeout from the point of view of replicas (data, pings).
# 3) Replica timeout from the point of view of masters (REPLCONF ACK pings).
# 3) Replica timeout from the point of view of primaries (REPLCONF ACK pings).
#
# It is important to make sure that this value is greater than the value
# specified for repl-ping-replica-period otherwise a timeout will be detected
# every time there is low traffic between the master and the replica. The default
# every time there is low traffic between the primary and the replica. The default
# value is 60 seconds.
#
# repl-timeout 60
@ -688,7 +736,7 @@ repl-diskless-load disabled
# be reduced but more bandwidth will be used for replication.
#
# By default we optimize for low latency, but in very high traffic conditions
# or when the master and replicas are many hops away, turning this to "yes" may
# or when the primary and replicas are many hops away, turning this to "yes" may
# be a good idea.
repl-disable-tcp-nodelay no
@ -703,15 +751,15 @@ repl-disable-tcp-nodelay no
#
# The backlog is only allocated if there is at least one replica connected.
#
# repl-backlog-size 1mb
# repl-backlog-size 10mb
# After a master has no connected replicas for some time, the backlog will be
# After a primary has no connected replicas for some time, the backlog will be
# freed. The following option configures the amount of seconds that need to
# elapse, starting from the time the last replica disconnected, for the backlog
# buffer to be freed.
#
# Note that replicas never free the backlog for timeout, since they may be
# promoted to masters later, and should be able to correctly "partially
# promoted to primaries later, and should be able to correctly "partially
# resynchronize" with other replicas: hence they should always accumulate backlog.
#
# A value of 0 means to never release the backlog.
@ -720,21 +768,21 @@ repl-disable-tcp-nodelay no
# The replica priority is an integer number published by the server in the INFO
# output. It is used by Sentinel in order to select a replica to promote
# into a master if the master is no longer working correctly.
# into a primary if the primary is no longer working correctly.
#
# A replica with a low priority number is considered better for promotion, so
# for instance if there are three replicas with priority 10, 100, 25 Sentinel
# will pick the one with priority 10, that is the lowest.
#
# However a special priority of 0 marks the replica as not able to perform the
# role of master, so a replica with priority of 0 will never be selected by
# role of primary, so a replica with priority of 0 will never be selected by
# Sentinel for promotion.
#
# By default the priority is 100.
replica-priority 100
# The propagation error behavior controls how the server will behave when it is
# unable to handle a command being processed in the replication stream from a master
# unable to handle a command being processed in the replication stream from a primary
# or processed while reading from an AOF file. Errors that occur during propagation
# are unexpected, and can cause data inconsistency.
#
@ -747,7 +795,7 @@ replica-priority 100
# propagation-error-behavior ignore
# Replica ignore disk write errors controls the behavior of a replica when it is
# unable to persist a write command received from its master to disk. By default,
# unable to persist a write command received from its primary to disk. By default,
# this configuration is set to 'no' and will crash the replica in this condition.
# It is not recommended to change this default.
#
@ -756,16 +804,16 @@ replica-priority 100
# -----------------------------------------------------------------------------
# By default, Sentinel includes all replicas in its reports. A replica
# can be excluded from Sentinel's announcements. An unannounced replica
# will be ignored by the 'sentinel replicas <master>' command and won't be
# will be ignored by the 'sentinel replicas <primary>' command and won't be
# exposed to Sentinel's clients.
#
# This option does not change the behavior of replica-priority. Even with
# replica-announced set to 'no', the replica can be promoted to master. To
# replica-announced set to 'no', the replica can be promoted to primary. To
# prevent this behavior, set replica-priority to 0.
#
# replica-announced yes
# It is possible for a master to stop accepting writes if there are less than
# It is possible for a primary to stop accepting writes if there are less than
# N replicas connected, having a lag less or equal than M seconds.
#
# The N replicas need to be in "online" state.
@ -787,18 +835,18 @@ replica-priority 100
# By default min-replicas-to-write is set to 0 (feature disabled) and
# min-replicas-max-lag is set to 10.
# A master is able to list the address and port of the attached
# A primary is able to list the address and port of the attached
# replicas in different ways. For example the "INFO replication" section
# offers this information, which is used, among other tools, by
# Sentinel in order to discover replica instances.
# Another place where this info is available is in the output of the
# "ROLE" command of a master.
# "ROLE" command of a primary.
#
# The listed IP address and port normally reported by a replica is
# obtained in the following way:
#
# IP: The address is auto detected by checking the peer address
# of the socket used by the replica to connect with the master.
# of the socket used by the replica to connect with the primary.
#
# Port: The port is communicated by the replica during the replication
# handshake, and is normally the port that the replica is using to
@ -807,7 +855,7 @@ replica-priority 100
# However when port forwarding or Network Address Translation (NAT) is
# used, the replica may actually be reachable via different IP and port
# pairs. The following two options can be used by a replica in order to
# report to its master a specific set of IP and port, so that both INFO
# report to its primary a specific set of IP and port, so that both INFO
# and ROLE will report those values.
#
# There is no need to use both the options if you need to override just
@ -1151,7 +1199,8 @@ acllog-max-len 128
# configuration directive.
#
# The default of 5 produces good enough results. 10 Approximates very closely
# true LRU but costs more CPU. 3 is faster but not very accurate.
# true LRU but costs more CPU. 3 is faster but not very accurate. The maximum
# value that can be set is 64.
#
# maxmemory-samples 5
@ -1164,11 +1213,11 @@ acllog-max-len 128
# maxmemory-eviction-tenacity 10
# By default a replica will ignore its maxmemory setting
# (unless it is promoted to master after a failover or manually). It means
# that the eviction of keys will be just handled by the master, sending the
# DEL commands to the replica as keys evict in the master side.
# (unless it is promoted to primary after a failover or manually). It means
# that the eviction of keys will be just handled by the primary, sending the
# DEL commands to the replica as keys evict in the primary side.
#
# This behavior ensures that masters and replicas stay consistent, and is usually
# This behavior ensures that primaries and replicas stay consistent, and is usually
# what you want, however if your replica is writable, or you want the replica
# to have a different memory setting, and you are sure all the writes performed
# to the replica are idempotent, then you may change this default (but be sure
@ -1179,7 +1228,7 @@ acllog-max-len 128
# be larger on the replica, or data structures may sometimes take more memory
# and so forth). So make sure you monitor your replicas and make sure they
# have enough memory to never hit a real out-of-memory condition before the
# master hits the configured maxmemory setting.
# primary hits the configured maxmemory setting.
#
# replica-ignore-maxmemory yes
@ -1202,8 +1251,8 @@ acllog-max-len 128
############################# LAZY FREEING ####################################
# The server has two primitives to delete keys. One is called DEL and is a blocking
# deletion of the object. It means that the server stops processing new commands
# When keys are deleted, the served has historically freed their memory using
# blocking operations. It means that the server stopped processing new commands
# in order to reclaim all the memory associated with an object in a synchronous
# way. If the key deleted is associated with a small object, the time needed
# in order to execute the DEL command is very small and comparable to most other
@ -1211,15 +1260,16 @@ acllog-max-len 128
# aggregated value containing millions of elements, the server can block for
# a long time (even seconds) in order to complete the operation.
#
# For the above reasons the server also offers non blocking deletion primitives
# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
# FLUSHDB commands, in order to reclaim memory in background. Those commands
# are executed in constant time. Another thread will incrementally free the
# object in the background as fast as possible.
# For the above reasons, lazy freeing (or asynchronous freeing), has been
# introduced. With lazy freeing, keys are deleted in constant time. Another
# thread will incrementally free the object in the background as fast as
# possible.
#
# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
# It's up to the design of the application to understand when it is a good
# idea to use one or the other. However the server sometimes has to
# Starting from Valkey 8.0, lazy freeing is enabled by default. It is possible
# to retain the synchronous freeing behaviour by setting the lazyfree related
# configuration directives to 'no'.
# Commands like DEL, FLUSHALL and FLUSHDB delete keys, but the server can also
# delete keys or flush the whole database as a side effect of other operations.
# Specifically the server deletes objects independently of a user call in the
# following scenarios:
@ -1236,32 +1286,34 @@ acllog-max-len 128
# itself removes any old content of the specified key in order to replace
# it with the specified string.
# 4) During replication, when a replica performs a full resynchronization with
# its master, the content of the whole database is removed in order to
# its primary, the content of the whole database is removed in order to
# load the RDB file just transferred.
#
# In all the above cases the default is to delete objects in a blocking way,
# like if DEL was called. However you can configure each case specifically
# in order to instead release memory in a non-blocking way like if UNLINK
# was called, using the following configuration directives.
# In all the above cases, the default is to release memory in a non-blocking
# way.
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
# It is also possible, for the case when to replace the user code DEL calls
# with UNLINK calls is not easy, to modify the default behavior of the DEL
# command to act exactly like UNLINK, using the following configuration
# directive:
# For keys deleted using the DEL command, lazy freeing is controlled by the
# configuration directive 'lazyfree-lazy-user-del'. The default is 'yes'. The
# UNLINK command is identical to the DEL command, except that UNLINK always
# frees the memory lazily, regardless of this configuration directive:
lazyfree-lazy-user-del no
lazyfree-lazy-user-del yes
# FLUSHDB, FLUSHALL, SCRIPT FLUSH and FUNCTION FLUSH support both asynchronous and synchronous
# deletion, which can be controlled by passing the [SYNC|ASYNC] flags into the
# commands. When neither flag is passed, this directive will be used to determine
# if the data should be deleted asynchronously.
lazyfree-lazy-user-flush no
# There are many problems with running flush synchronously. Even in single CPU
# environments, the thread managers should balance between the freeing and
# serving incoming requests. The default value is yes.
lazyfree-lazy-user-flush yes
################################ THREADED I/O #################################
@ -1277,9 +1329,8 @@ lazyfree-lazy-user-flush no
# 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
# that have at least 3 or more cores, leaving at least one spare core.
# We also recommend using threaded I/O only if you actually have performance problems, with
# instances being able to use a quite big percentage of CPU time, otherwise
# there is no point in using this feature.
#
@ -1290,21 +1341,23 @@ lazyfree-lazy-user-flush no
# 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:
# When I/O threads are enabled, we use threads for reads and writes, that is
# to thread the write and read syscall and transfer the client buffers to the
# socket and to enable threading of reads and protocol parsing.
#
# io-threads-do-reads no
# When multiple commands are parsed by the I/O threads and ready for execution,
# we take advantage of knowing the next set of commands and prefetch their
# required dictionary entries in a batch. This reduces memory access costs.
#
# Usually threading reads doesn't help much.
# The optimal batch size depends on the specific workflow of the user.
# The default batch size is 16, which can be modified using the
# 'prefetch-batch-max-size' config.
#
# NOTE 1: This configuration directive cannot be changed at runtime via
# CONFIG SET. Also, this feature currently does not work when SSL is
# enabled.
# When the config is set to 0, prefetching is disabled.
#
# NOTE 2: If you want to test the server speedup using valkey-benchmark, make
# prefetch-batch-max-size 16
#
# NOTE: If you want to test the server speedup using valkey-benchmark, make
# sure you also run the benchmark itself in threaded mode, using the
# --threads option to match the number of server threads, otherwise you'll not
# be able to notice the improvements.
@ -1317,7 +1370,7 @@ lazyfree-lazy-user-flush no
# Enabling this feature makes the server 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.
# replicas killed before primaries.
#
# The server supports these options:
#
@ -1331,7 +1384,7 @@ lazyfree-lazy-user-flush no
oom-score-adj no
# When oom-score-adj is used, this directive controls the specific values used
# for master, replica and background child processes. Values range -2000 to
# for primary, replica and background child processes. Values range -2000 to
# 2000 (higher means more likely to be killed).
#
# Unprivileged processes (not root, and without CAP_SYS_RESOURCE capabilities)
@ -1371,6 +1424,10 @@ disable-thp yes
# If the AOF is enabled on startup the server will load the AOF, that is the file
# with the better durability guarantees.
#
# Note that changing this value in a config file of an existing database and
# restarting the server can lead to data loss. A conversion needs to be done
# by setting it via CONFIG command on a live server first.
#
# Please check https://valkey.io/topics/persistence for more information.
appendonly no
@ -1515,7 +1572,7 @@ aof-timestamp-enabled no
# Maximum time to wait for replicas when shutting down, in seconds.
#
# During shut down, a grace period allows any lagging replicas to catch up with
# the latest replication offset before the master exists. This period can
# the latest replication offset before the primary exists. This period can
# prevent data loss, especially for deployments without configured disk backups.
#
# The 'shutdown-timeout' value is the grace period's duration in seconds. It is
@ -1591,7 +1648,7 @@ aof-timestamp-enabled no
# you to specify the cluster bus port when executing cluster meet.
# cluster-port 0
# A replica of a failing master will avoid to start a failover if its data
# A replica of a failing primary will avoid to start a failover if its data
# looks too old.
#
# There is no simple way for a replica to actually have an exact measure of
@ -1599,35 +1656,35 @@ aof-timestamp-enabled no
#
# 1) If there are multiple replicas able to failover, they exchange messages
# in order to try to give an advantage to the replica with the best
# replication offset (more data from the master processed).
# replication offset (more data from the primary processed).
# Replicas will try to get their rank by offset, and apply to the start
# of the failover a delay proportional to their rank.
#
# 2) Every single replica computes the time of the last interaction with
# its master. This can be the last ping or command received (if the master
# its primary. This can be the last ping or command received (if the primary
# is still in the "connected" state), or the time that elapsed since the
# disconnection with the master (if the replication link is currently down).
# disconnection with the primary (if the replication link is currently down).
# If the last interaction is too old, the replica will not try to failover
# at all.
#
# The point "2" can be tuned by user. Specifically a replica will not perform
# the failover if, since the last interaction with the master, the time
# the failover if, since the last interaction with the primary, the time
# elapsed is greater than:
#
# (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period
#
# So for example if node-timeout is 30 seconds, and the cluster-replica-validity-factor
# is 10, and assuming a default repl-ping-replica-period of 10 seconds, the
# replica will not try to failover if it was not able to talk with the master
# replica will not try to failover if it was not able to talk with the primary
# for longer than 310 seconds.
#
# A large cluster-replica-validity-factor may allow replicas with too old data to failover
# a master, while a too small value may prevent the cluster from being able to
# a primary, while a too small value may prevent the cluster from being able to
# elect a replica at all.
#
# For maximum availability, it is possible to set the cluster-replica-validity-factor
# to a value of 0, which means, that replicas will always try to failover the
# master regardless of the last time they interacted with the master.
# primary regardless of the last time they interacted with the primary.
# (However they'll always try to apply a delay proportional to their
# offset rank).
#
@ -1636,19 +1693,19 @@ aof-timestamp-enabled no
#
# cluster-replica-validity-factor 10
# Cluster replicas are able to migrate to orphaned masters, that are masters
# Cluster replicas are able to migrate to orphaned primaries, that are primaries
# that are left without working replicas. This improves the cluster ability
# to resist to failures as otherwise an orphaned master can't be failed over
# to resist to failures as otherwise an orphaned primary can't be failed over
# in case of failure if it has no working replicas.
#
# Replicas migrate to orphaned masters only if there are still at least a
# given number of other working replicas for their old master. This number
# Replicas migrate to orphaned primaries only if there are still at least a
# given number of other working replicas for their old primary. This number
# is the "migration barrier". A migration barrier of 1 means that a replica
# will migrate only if there is at least 1 other working replica for its master
# will migrate only if there is at least 1 other working replica for its primary
# and so forth. It usually reflects the number of replicas you want for every
# master in your cluster.
# primary in your cluster.
#
# Default is 1 (replicas migrate only if their masters remain with at least
# Default is 1 (replicas migrate only if their primaries remain with at least
# one replica). To disable migration just set it to a very large value or
# set cluster-allow-replica-migration to 'no'.
# A value of 0 can be set but is useful only for debugging and dangerous
@ -1657,8 +1714,10 @@ aof-timestamp-enabled no
# cluster-migration-barrier 1
# Turning off this option allows to use less automatic cluster configuration.
# It both disables migration to orphaned masters and migration from masters
# that became empty.
# It disables migration of replicas to orphaned primaries. Masters that become
# empty due to losing their last slots to another primary will not automatically
# replicate from the primary that took over their last slots. Instead, they will
# remain as empty primaries without any slots.
#
# Default is 'yes' (allow automatic migrations).
#
@ -1678,7 +1737,7 @@ aof-timestamp-enabled no
# cluster-require-full-coverage yes
# This option, when set to yes, prevents replicas from trying to failover its
# master during master failures. However the replica can still perform a
# primary during primary failures. However the replica can still perform a
# manual failover, if forced to do so.
#
# This is useful in different scenarios, especially in the case of multiple
@ -1697,9 +1756,9 @@ aof-timestamp-enabled no
#
# The second use case is for configurations that don't meet the recommended
# three shards but want to enable cluster mode and scale later. A
# master outage in a 1 or 2 shard configuration causes a read/write outage to the
# primary outage in a 1 or 2 shard configuration causes a read/write outage to the
# entire cluster without this option set, with it set there is only a write outage.
# Without a quorum of masters, slot ownership will not change automatically.
# Without a quorum of primaries, slot ownership will not change automatically.
#
# cluster-allow-reads-when-down no
@ -1754,6 +1813,26 @@ aof-timestamp-enabled no
#
# cluster-preferred-endpoint-type ip
# The cluster blacklist is used when removing a node from the cluster completely.
# When CLUSTER FORGET is called for a node, that node is put into the blacklist for
# some time so that when gossip messages are received from other nodes that still
# remember it, it is not re-added. This gives time for CLUSTER FORGET to be sent to
# every node in the cluster. The blacklist TTL is 60 seconds by default, which should
# be sufficient for most clusters, but you may considering increasing this if you see
# nodes getting re-added while using CLUSTER FORGET.
#
# cluster-blacklist-ttl 60
# Clusters can be configured to track per-slot resource statistics,
# which are accessible by the CLUSTER SLOT-STATS command.
#
# By default, the 'cluster-slot-stats-enabled' is disabled, and only 'key-count' is captured.
# By enabling the 'cluster-slot-stats-enabled' config, the cluster will begin to capture advanced statistics.
# These statistics can be leveraged to assess general slot usage trends, identify hot / cold slots,
# migrate slots for a balanced cluster workload, and / or re-write application logic to better utilize slots.
#
# cluster-slot-stats-enabled no
# In order to setup your cluster make sure to read the documentation
# available at https://valkey.io web site.
@ -1765,22 +1844,28 @@ aof-timestamp-enabled no
#
# In order to make a cluster work in such environments, a static
# configuration where each node knows its public address is needed. The
# following four options are used for this scope, and are:
# following options are used for this scope, and are:
#
# * cluster-announce-ip
# * cluster-announce-client-ipv4
# * cluster-announce-client-ipv6
# * cluster-announce-port
# * cluster-announce-tls-port
# * cluster-announce-bus-port
#
# Each instructs the node about its address, client ports (for connections
# without and with TLS) and cluster message bus port. The information is then
# published in the header of the bus packets so that other nodes will be able to
# correctly map the address of the node publishing the information.
# Each instructs the node about its address, possibly other addresses to expose
# to clients, client ports (for connections without and with TLS) and cluster
# message bus port. The information is then published in the bus packets so that
# other nodes will be able to correctly map the address of the node publishing
# the information.
#
# If tls-cluster is set to yes and cluster-announce-tls-port is omitted or set
# to zero, then cluster-announce-port refers to the TLS port. Note also that
# cluster-announce-tls-port has no effect if tls-cluster is set to no.
#
# If cluster-announce-client-ipv4 and cluster-announce-client-ipv6 are omitted,
# then cluster-announce-ip is exposed to clients.
#
# If the above options are not used, the normal cluster auto-detection
# will be used instead.
#
@ -1792,6 +1877,8 @@ aof-timestamp-enabled no
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-client-ipv4 123.123.123.5
# cluster-announce-client-ipv6 2001:db8::8a2e:370:7334
# cluster-announce-tls-port 6379
# cluster-announce-port 0
# cluster-announce-bus-port 6380
@ -2059,7 +2146,7 @@ client-output-buffer-limit pubsub 32mb 8mb 60
# amount by default in order to avoid that a protocol desynchronization (for
# instance due to a bug in the client) will lead to unbound memory usage in
# the query buffer. However you can configure it here if you have very special
# needs, such us huge multi/exec requests or alike.
# needs, such as a command with huge argument, or huge multi/exec requests or alike.
#
# client-query-buffer-limit 1gb
@ -2184,6 +2271,26 @@ rdb-save-incremental-fsync yes
# lfu-log-factor 10
# lfu-decay-time 1
# The maximum number of new client connections accepted per event-loop cycle. This configuration
# is set independently for TLS connections.
#
# By default, up to 10 new connection will be accepted per event-loop cycle for normal connections
# and up to 1 new connection per event-loop cycle for TLS connections.
#
# Adjusting this to a larger number can slightly improve efficiency for new connections
# at the risk of causing timeouts for regular commands on established connections. It is
# not advised to change this without ensuring that all clients have limited connection
# pools and exponential backoff in the case of command/connection timeouts.
#
# If your application is establishing a large number of new connections per second you should
# also consider tuning the value of tcp-backlog, which allows the kernel to buffer more
# pending connections before dropping or rejecting connections.
#
# max-new-connections-per-cycle 10
# max-new-tls-connections-per-cycle 1
########################### ACTIVE DEFRAGMENTATION #######################
#
# What is active defragmentation?
@ -2264,17 +2371,17 @@ jemalloc-bg-thread yes
# the bgsave child process. The syntax to specify the cpu list is the same as
# the taskset command:
#
# Set redis server/io threads to cpu affinity 0,2,4,6:
# server_cpulist 0-7:2
# 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
# bio-cpulist 1,3
#
# Set aof rewrite child process to cpu affinity 8,9,10,11:
# aof_rewrite_cpulist 8-11
# aof-rewrite-cpulist 8-11
#
# Set bgsave child process to cpu affinity 1,10,11
# bgsave_cpulist 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
@ -2282,3 +2389,9 @@ jemalloc-bg-thread yes
# to suppress
#
# ignore-warnings ARM64-COW-BUG
# Inform Valkey of the availability zone if running in a cloud environment. Currently
# this is only exposed via the info command for clients to use, but in the future we
# we may also use this when making decisions for replication.
#
# availability-zone "zone-name"

124
poetry.lock generated
View File

@ -2695,6 +2695,98 @@ tests = ["check-manifest", "coverage", "defusedxml", "markdown2", "olefile", "pa
typing = ["typing-extensions"]
xmp = ["defusedxml"]
[[package]]
name = "pillow"
version = "11.0.0"
description = "Python Imaging Library (Fork)"
optional = false
python-versions = ">=3.9"
files = [
{file = "pillow-11.0.0-cp310-cp310-macosx_10_10_x86_64.whl", hash = "sha256:6619654954dc4936fcff82db8eb6401d3159ec6be81e33c6000dfd76ae189947"},
{file = "pillow-11.0.0-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:b3c5ac4bed7519088103d9450a1107f76308ecf91d6dabc8a33a2fcfb18d0fba"},
{file = "pillow-11.0.0-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a65149d8ada1055029fcb665452b2814fe7d7082fcb0c5bed6db851cb69b2086"},
{file = "pillow-11.0.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:88a58d8ac0cc0e7f3a014509f0455248a76629ca9b604eca7dc5927cc593c5e9"},
{file = "pillow-11.0.0-cp310-cp310-manylinux_2_28_aarch64.whl", hash = "sha256:c26845094b1af3c91852745ae78e3ea47abf3dbcd1cf962f16b9a5fbe3ee8488"},
{file = "pillow-11.0.0-cp310-cp310-manylinux_2_28_x86_64.whl", hash = "sha256:1a61b54f87ab5786b8479f81c4b11f4d61702830354520837f8cc791ebba0f5f"},
{file = "pillow-11.0.0-cp310-cp310-musllinux_1_2_aarch64.whl", hash = "sha256:674629ff60030d144b7bca2b8330225a9b11c482ed408813924619c6f302fdbb"},
{file = "pillow-11.0.0-cp310-cp310-musllinux_1_2_x86_64.whl", hash = "sha256:598b4e238f13276e0008299bd2482003f48158e2b11826862b1eb2ad7c768b97"},
{file = "pillow-11.0.0-cp310-cp310-win32.whl", hash = "sha256:9a0f748eaa434a41fccf8e1ee7a3eed68af1b690e75328fd7a60af123c193b50"},
{file = "pillow-11.0.0-cp310-cp310-win_amd64.whl", hash = "sha256:a5629742881bcbc1f42e840af185fd4d83a5edeb96475a575f4da50d6ede337c"},
{file = "pillow-11.0.0-cp310-cp310-win_arm64.whl", hash = "sha256:ee217c198f2e41f184f3869f3e485557296d505b5195c513b2bfe0062dc537f1"},
{file = "pillow-11.0.0-cp311-cp311-macosx_10_10_x86_64.whl", hash = "sha256:1c1d72714f429a521d8d2d018badc42414c3077eb187a59579f28e4270b4b0fc"},
{file = "pillow-11.0.0-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:499c3a1b0d6fc8213519e193796eb1a86a1be4b1877d678b30f83fd979811d1a"},
{file = "pillow-11.0.0-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:c8b2351c85d855293a299038e1f89db92a2f35e8d2f783489c6f0b2b5f3fe8a3"},
{file = "pillow-11.0.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:6f4dba50cfa56f910241eb7f883c20f1e7b1d8f7d91c750cd0b318bad443f4d5"},
{file = "pillow-11.0.0-cp311-cp311-manylinux_2_28_aarch64.whl", hash = "sha256:5ddbfd761ee00c12ee1be86c9c0683ecf5bb14c9772ddbd782085779a63dd55b"},
{file = "pillow-11.0.0-cp311-cp311-manylinux_2_28_x86_64.whl", hash = "sha256:45c566eb10b8967d71bf1ab8e4a525e5a93519e29ea071459ce517f6b903d7fa"},
{file = "pillow-11.0.0-cp311-cp311-musllinux_1_2_aarch64.whl", hash = "sha256:b4fd7bd29610a83a8c9b564d457cf5bd92b4e11e79a4ee4716a63c959699b306"},
{file = "pillow-11.0.0-cp311-cp311-musllinux_1_2_x86_64.whl", hash = "sha256:cb929ca942d0ec4fac404cbf520ee6cac37bf35be479b970c4ffadf2b6a1cad9"},
{file = "pillow-11.0.0-cp311-cp311-win32.whl", hash = "sha256:006bcdd307cc47ba43e924099a038cbf9591062e6c50e570819743f5607404f5"},
{file = "pillow-11.0.0-cp311-cp311-win_amd64.whl", hash = "sha256:52a2d8323a465f84faaba5236567d212c3668f2ab53e1c74c15583cf507a0291"},
{file = "pillow-11.0.0-cp311-cp311-win_arm64.whl", hash = "sha256:16095692a253047fe3ec028e951fa4221a1f3ed3d80c397e83541a3037ff67c9"},
{file = "pillow-11.0.0-cp312-cp312-macosx_10_13_x86_64.whl", hash = "sha256:d2c0a187a92a1cb5ef2c8ed5412dd8d4334272617f532d4ad4de31e0495bd923"},
{file = "pillow-11.0.0-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:084a07ef0821cfe4858fe86652fffac8e187b6ae677e9906e192aafcc1b69903"},
{file = "pillow-11.0.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:8069c5179902dcdce0be9bfc8235347fdbac249d23bd90514b7a47a72d9fecf4"},
{file = "pillow-11.0.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:f02541ef64077f22bf4924f225c0fd1248c168f86e4b7abdedd87d6ebaceab0f"},
{file = "pillow-11.0.0-cp312-cp312-manylinux_2_28_aarch64.whl", hash = "sha256:fcb4621042ac4b7865c179bb972ed0da0218a076dc1820ffc48b1d74c1e37fe9"},
{file = "pillow-11.0.0-cp312-cp312-manylinux_2_28_x86_64.whl", hash = "sha256:00177a63030d612148e659b55ba99527803288cea7c75fb05766ab7981a8c1b7"},
{file = "pillow-11.0.0-cp312-cp312-musllinux_1_2_aarch64.whl", hash = "sha256:8853a3bf12afddfdf15f57c4b02d7ded92c7a75a5d7331d19f4f9572a89c17e6"},
{file = "pillow-11.0.0-cp312-cp312-musllinux_1_2_x86_64.whl", hash = "sha256:3107c66e43bda25359d5ef446f59c497de2b5ed4c7fdba0894f8d6cf3822dafc"},
{file = "pillow-11.0.0-cp312-cp312-win32.whl", hash = "sha256:86510e3f5eca0ab87429dd77fafc04693195eec7fd6a137c389c3eeb4cfb77c6"},
{file = "pillow-11.0.0-cp312-cp312-win_amd64.whl", hash = "sha256:8ec4a89295cd6cd4d1058a5e6aec6bf51e0eaaf9714774e1bfac7cfc9051db47"},
{file = "pillow-11.0.0-cp312-cp312-win_arm64.whl", hash = "sha256:27a7860107500d813fcd203b4ea19b04babe79448268403172782754870dac25"},
{file = "pillow-11.0.0-cp313-cp313-macosx_10_13_x86_64.whl", hash = "sha256:bcd1fb5bb7b07f64c15618c89efcc2cfa3e95f0e3bcdbaf4642509de1942a699"},
{file = "pillow-11.0.0-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:0e038b0745997c7dcaae350d35859c9715c71e92ffb7e0f4a8e8a16732150f38"},
{file = "pillow-11.0.0-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:0ae08bd8ffc41aebf578c2af2f9d8749d91f448b3bfd41d7d9ff573d74f2a6b2"},
{file = "pillow-11.0.0-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:d69bfd8ec3219ae71bcde1f942b728903cad25fafe3100ba2258b973bd2bc1b2"},
{file = "pillow-11.0.0-cp313-cp313-manylinux_2_28_aarch64.whl", hash = "sha256:61b887f9ddba63ddf62fd02a3ba7add935d053b6dd7d58998c630e6dbade8527"},
{file = "pillow-11.0.0-cp313-cp313-manylinux_2_28_x86_64.whl", hash = "sha256:c6a660307ca9d4867caa8d9ca2c2658ab685de83792d1876274991adec7b93fa"},
{file = "pillow-11.0.0-cp313-cp313-musllinux_1_2_aarch64.whl", hash = "sha256:73e3a0200cdda995c7e43dd47436c1548f87a30bb27fb871f352a22ab8dcf45f"},
{file = "pillow-11.0.0-cp313-cp313-musllinux_1_2_x86_64.whl", hash = "sha256:fba162b8872d30fea8c52b258a542c5dfd7b235fb5cb352240c8d63b414013eb"},
{file = "pillow-11.0.0-cp313-cp313-win32.whl", hash = "sha256:f1b82c27e89fffc6da125d5eb0ca6e68017faf5efc078128cfaa42cf5cb38798"},
{file = "pillow-11.0.0-cp313-cp313-win_amd64.whl", hash = "sha256:8ba470552b48e5835f1d23ecb936bb7f71d206f9dfeee64245f30c3270b994de"},
{file = "pillow-11.0.0-cp313-cp313-win_arm64.whl", hash = "sha256:846e193e103b41e984ac921b335df59195356ce3f71dcfd155aa79c603873b84"},
{file = "pillow-11.0.0-cp313-cp313t-macosx_10_13_x86_64.whl", hash = "sha256:4ad70c4214f67d7466bea6a08061eba35c01b1b89eaa098040a35272a8efb22b"},
{file = "pillow-11.0.0-cp313-cp313t-macosx_11_0_arm64.whl", hash = "sha256:6ec0d5af64f2e3d64a165f490d96368bb5dea8b8f9ad04487f9ab60dc4bb6003"},
{file = "pillow-11.0.0-cp313-cp313t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:c809a70e43c7977c4a42aefd62f0131823ebf7dd73556fa5d5950f5b354087e2"},
{file = "pillow-11.0.0-cp313-cp313t-manylinux_2_28_x86_64.whl", hash = "sha256:4b60c9520f7207aaf2e1d94de026682fc227806c6e1f55bba7606d1c94dd623a"},
{file = "pillow-11.0.0-cp313-cp313t-musllinux_1_2_x86_64.whl", hash = "sha256:1e2688958a840c822279fda0086fec1fdab2f95bf2b717b66871c4ad9859d7e8"},
{file = "pillow-11.0.0-cp313-cp313t-win32.whl", hash = "sha256:607bbe123c74e272e381a8d1957083a9463401f7bd01287f50521ecb05a313f8"},
{file = "pillow-11.0.0-cp313-cp313t-win_amd64.whl", hash = "sha256:5c39ed17edea3bc69c743a8dd3e9853b7509625c2462532e62baa0732163a904"},
{file = "pillow-11.0.0-cp313-cp313t-win_arm64.whl", hash = "sha256:75acbbeb05b86bc53cbe7b7e6fe00fbcf82ad7c684b3ad82e3d711da9ba287d3"},
{file = "pillow-11.0.0-cp39-cp39-macosx_10_10_x86_64.whl", hash = "sha256:2e46773dc9f35a1dd28bd6981332fd7f27bec001a918a72a79b4133cf5291dba"},
{file = "pillow-11.0.0-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:2679d2258b7f1192b378e2893a8a0a0ca472234d4c2c0e6bdd3380e8dfa21b6a"},
{file = "pillow-11.0.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:eda2616eb2313cbb3eebbe51f19362eb434b18e3bb599466a1ffa76a033fb916"},
{file = "pillow-11.0.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:20ec184af98a121fb2da42642dea8a29ec80fc3efbaefb86d8fdd2606619045d"},
{file = "pillow-11.0.0-cp39-cp39-manylinux_2_28_aarch64.whl", hash = "sha256:8594f42df584e5b4bb9281799698403f7af489fba84c34d53d1c4bfb71b7c4e7"},
{file = "pillow-11.0.0-cp39-cp39-manylinux_2_28_x86_64.whl", hash = "sha256:c12b5ae868897c7338519c03049a806af85b9b8c237b7d675b8c5e089e4a618e"},
{file = "pillow-11.0.0-cp39-cp39-musllinux_1_2_aarch64.whl", hash = "sha256:70fbbdacd1d271b77b7721fe3cdd2d537bbbd75d29e6300c672ec6bb38d9672f"},
{file = "pillow-11.0.0-cp39-cp39-musllinux_1_2_x86_64.whl", hash = "sha256:5178952973e588b3f1360868847334e9e3bf49d19e169bbbdfaf8398002419ae"},
{file = "pillow-11.0.0-cp39-cp39-win32.whl", hash = "sha256:8c676b587da5673d3c75bd67dd2a8cdfeb282ca38a30f37950511766b26858c4"},
{file = "pillow-11.0.0-cp39-cp39-win_amd64.whl", hash = "sha256:94f3e1780abb45062287b4614a5bc0874519c86a777d4a7ad34978e86428b8dd"},
{file = "pillow-11.0.0-cp39-cp39-win_arm64.whl", hash = "sha256:290f2cc809f9da7d6d622550bbf4c1e57518212da51b6a30fe8e0a270a5b78bd"},
{file = "pillow-11.0.0-pp310-pypy310_pp73-macosx_10_15_x86_64.whl", hash = "sha256:1187739620f2b365de756ce086fdb3604573337cc28a0d3ac4a01ab6b2d2a6d2"},
{file = "pillow-11.0.0-pp310-pypy310_pp73-macosx_11_0_arm64.whl", hash = "sha256:fbbcb7b57dc9c794843e3d1258c0fbf0f48656d46ffe9e09b63bbd6e8cd5d0a2"},
{file = "pillow-11.0.0-pp310-pypy310_pp73-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:5d203af30149ae339ad1b4f710d9844ed8796e97fda23ffbc4cc472968a47d0b"},
{file = "pillow-11.0.0-pp310-pypy310_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:21a0d3b115009ebb8ac3d2ebec5c2982cc693da935f4ab7bb5c8ebe2f47d36f2"},
{file = "pillow-11.0.0-pp310-pypy310_pp73-manylinux_2_28_aarch64.whl", hash = "sha256:73853108f56df97baf2bb8b522f3578221e56f646ba345a372c78326710d3830"},
{file = "pillow-11.0.0-pp310-pypy310_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:e58876c91f97b0952eb766123bfef372792ab3f4e3e1f1a2267834c2ab131734"},
{file = "pillow-11.0.0-pp310-pypy310_pp73-win_amd64.whl", hash = "sha256:224aaa38177597bb179f3ec87eeefcce8e4f85e608025e9cfac60de237ba6316"},
{file = "pillow-11.0.0-pp39-pypy39_pp73-macosx_11_0_arm64.whl", hash = "sha256:5bd2d3bdb846d757055910f0a59792d33b555800813c3b39ada1829c372ccb06"},
{file = "pillow-11.0.0-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:375b8dd15a1f5d2feafff536d47e22f69625c1aa92f12b339ec0b2ca40263273"},
{file = "pillow-11.0.0-pp39-pypy39_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:daffdf51ee5db69a82dd127eabecce20729e21f7a3680cf7cbb23f0829189790"},
{file = "pillow-11.0.0-pp39-pypy39_pp73-win_amd64.whl", hash = "sha256:7326a1787e3c7b0429659e0a944725e1b03eeaa10edd945a86dead1913383944"},
{file = "pillow-11.0.0.tar.gz", hash = "sha256:72bacbaf24ac003fea9bff9837d1eedb6088758d41e100c1552930151f677739"},
]
[package.extras]
docs = ["furo", "olefile", "sphinx (>=8.1)", "sphinx-copybutton", "sphinx-inline-tabs", "sphinxext-opengraph"]
fpx = ["olefile"]
mic = ["olefile"]
tests = ["check-manifest", "coverage", "defusedxml", "markdown2", "olefile", "packaging", "pyroma", "pytest", "pytest-cov", "pytest-timeout"]
typing = ["typing-extensions"]
xmp = ["defusedxml"]
[[package]]
name = "pkgutil-resolve-name"
version = "1.3.10"
@ -2952,13 +3044,13 @@ files = [
[[package]]
name = "publicsuffixlist"
version = "1.0.2.20241015"
version = "1.0.2.20241017"
description = "publicsuffixlist implement"
optional = false
python-versions = ">=3.5"
files = [
{file = "publicsuffixlist-1.0.2.20241015-py2.py3-none-any.whl", hash = "sha256:ca405fb3e40ef11cedbd38192447d28fd994eb0e93c00bbea5b585c0bc98a1b4"},
{file = "publicsuffixlist-1.0.2.20241015.tar.gz", hash = "sha256:aba38be392cbbcc97286a8250c0405fcf81c7a9f3346fa0ae7c48e55512682f3"},
{file = "publicsuffixlist-1.0.2.20241017-py2.py3-none-any.whl", hash = "sha256:7420cc5a8fc10418043d2f5bcd8bb3fa3800a83d33136130c71607c366bb7e4c"},
{file = "publicsuffixlist-1.0.2.20241017.tar.gz", hash = "sha256:387a7b318bbd7a8de159014a0a1b81d58c3c2ea6a5f0d5c9a0444056fd694bbf"},
]
[package.extras]
@ -3374,19 +3466,19 @@ docs = ["Sphinx (<7.2)", "Sphinx (>=7.2,<8.0)", "Sphinx (>=8,<9)"]
[[package]]
name = "pymisp"
version = "2.5.0"
version = "2.5.1"
description = "Python API for MISP."
optional = false
python-versions = "<4.0,>=3.8"
files = [
{file = "pymisp-2.5.0-py3-none-any.whl", hash = "sha256:b15915aa88376b94cb608ce38469e3bbdc7ca5507709e64dfeb46b874a17969b"},
{file = "pymisp-2.5.0.tar.gz", hash = "sha256:d3bfc7a337e4382026343f05aa442bfdecc3e11a4f3a5479ad0e6087dcde7e78"},
{file = "pymisp-2.5.1-py3-none-any.whl", hash = "sha256:29afd529b1e18ebf7a242c68ab240561dbf5b706d11612d75fc692413fd92990"},
{file = "pymisp-2.5.1.tar.gz", hash = "sha256:8aa3aa9e8ad9d9eb7a31e8ad5c07741855d4bac6efa65d83ea6a62689efae2c2"},
]
[package.dependencies]
deprecated = ">=1.2.14,<2.0.0"
lief = {version = ">=0.15.0,<0.16.0", optional = true, markers = "extra == \"fileobjects\""}
publicsuffixlist = ">=1.0.2.20241003,<2.0.0.0"
publicsuffixlist = ">=1.0.2.20241017,<2.0.0.0"
pydeep2 = {version = ">=0.5.1,<0.6.0", optional = true, markers = "extra == \"fileobjects\""}
pyfaup = {version = ">=1.2,<2.0", optional = true, markers = "extra == \"url\""}
python-dateutil = ">=2.9.0.post0,<3.0.0"
@ -3395,8 +3487,8 @@ requests = ">=2.32.3,<3.0.0"
[package.extras]
brotli = ["urllib3[brotli]"]
docs = ["Sphinx (>=8,<9)", "docutils (>=0.21.1,<0.22.0)", "recommonmark (>=0.7.1,<0.8.0)", "sphinx-autodoc-typehints (>=2.4.4,<3.0.0)"]
email = ["RTFDE (>=0.1.1,<0.2.0)", "extract_msg (>=0.49,<0.50)", "oletools (>=0.60.1,<0.61.0)"]
docs = ["Sphinx (>=8,<9)", "docutils (>=0.21.1,<0.22.0)", "recommonmark (>=0.7.1,<0.8.0)", "sphinx-autodoc-typehints (>=2.5.0,<3.0.0)"]
email = ["RTFDE (>=0.1.1,<0.2.0)", "extract_msg (>=0.51,<0.52)", "oletools (>=0.60.1,<0.61.0)"]
fileobjects = ["lief (>=0.15.0,<0.16.0)", "pydeep2 (>=0.5.1,<0.6.0)", "python-magic (>=0.4.27,<0.5.0)"]
openioc = ["beautifulsoup4 (>=4.12.3,<5.0.0)"]
pdfexport = ["reportlab (>=4.2.5,<5.0.0)"]
@ -4013,13 +4105,13 @@ test = ["pytest"]
[[package]]
name = "setuptools"
version = "75.1.0"
version = "75.2.0"
description = "Easily download, build, install, upgrade, and uninstall Python packages"
optional = false
python-versions = ">=3.8"
files = [
{file = "setuptools-75.1.0-py3-none-any.whl", hash = "sha256:35ab7fd3bcd95e6b7fd704e4a1539513edad446c097797f2985e0e4b960772f2"},
{file = "setuptools-75.1.0.tar.gz", hash = "sha256:d59a21b17a275fb872a9c3dae73963160ae079f1049ed956880cd7c09b120538"},
{file = "setuptools-75.2.0-py3-none-any.whl", hash = "sha256:a7fcb66f68b4d9e8e66b42f9876150a3371558f98fa32222ffaa5bced76406f8"},
{file = "setuptools-75.2.0.tar.gz", hash = "sha256:753bb6ebf1f465a1912e19ed1d41f403a79173a9acf66a42e7e6aec45c3c16ec"},
]
[package.extras]
@ -4279,13 +4371,13 @@ types-urllib3 = "*"
[[package]]
name = "types-requests"
version = "2.32.0.20240914"
version = "2.32.0.20241016"
description = "Typing stubs for requests"
optional = false
python-versions = ">=3.8"
files = [
{file = "types-requests-2.32.0.20240914.tar.gz", hash = "sha256:2850e178db3919d9bf809e434eef65ba49d0e7e33ac92d588f4a5e295fffd405"},
{file = "types_requests-2.32.0.20240914-py3-none-any.whl", hash = "sha256:59c2f673eb55f32a99b2894faf6020e1a9f4a402ad0f192bfee0b64469054310"},
{file = "types-requests-2.32.0.20241016.tar.gz", hash = "sha256:0d9cad2f27515d0e3e3da7134a1b6f28fb97129d86b867f24d9c726452634d95"},
{file = "types_requests-2.32.0.20241016-py3-none-any.whl", hash = "sha256:4195d62d6d3e043a4eaaf08ff8a62184584d2e8684e9d2aa178c7915a7da3747"},
]
[package.dependencies]
@ -4697,4 +4789,4 @@ type = ["pytest-mypy"]
[metadata]
lock-version = "2.0"
python-versions = ">=3.8.1,<3.13"
content-hash = "3289656ed6b4790b8f1c1f4a5d9e0a029a45c570397ca433ebfcd82e6a2209ca"
content-hash = "ebeed49d8baecb2e60479e29c556f632af9d36112847cf5f28a60ee5e6438c2c"

View File

@ -56,8 +56,11 @@ dnspython = [
{version = "^2.7.0", python = ">=3.9"}
]
pytaxonomies = "^1.5.0"
pymisp = {version = "^2.5.0", extras = ["url", "fileobjects"]}
Pillow = "^10.4.0"
pymisp = {version = "^2.5.1", extras = ["url", "fileobjects"]}
Pillow = [
{version = "<11", python = "<3.9"},
{version = "^11", python = ">=3.9"}
]
flask-restx = "^1.3.0"
rich = "^13.9.2"
pyphishtanklookup = "^1.4.0"
@ -74,7 +77,7 @@ pypandora = "^1.9.0"
lacuscore = "^1.11.1"
pylacus = "^1.11.1"
pyipasnhistory = "^2.1.2"
publicsuffixlist = "^1.0.2.20241015"
publicsuffixlist = "^1.0.2.20241017"
pyfaup = "^1.2"
chardet = "^5.2.0"
pysecuritytxt = "^1.3.2"