"Fossies" - the Fresh Open Source Software Archive

Member "redis-7.0.8/redis.conf" (16 Jan 2023, 106545 Bytes) of package /linux/misc/redis-7.0.8.tar.gz:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) Generic config files source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

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