apiVersion: v1
data:
  redis.conf: "# Redis configuration file example.\n#\n# Note that in order to read
    the configuration file, Redis must be\n# started with the file path as first argument:\n#\n#
    ./redis-server /path/to/redis.conf\n\n# Note on units: when memory size is needed,
    it is possible to specify\n# it in the usual form of 1k 5GB 4M and so forth:\n#\n#
    1k => 1000 bytes\n# 1kb => 1024 bytes\n# 1m => 1000000 bytes\n# 1mb => 1024*1024
    bytes\n# 1g => 1000000000 bytes\n# 1gb => 1024*1024*1024 bytes\n#\n# units are
    case insensitive so 1GB 1Gb 1gB are all the same.\n\n##################################
    INCLUDES ###################################\n\n# Include one or more other config
    files here.  This is useful if you\n# have a standard template that goes to all
    Redis servers but also need\n# to customize a few per-server settings.  Include
    files can include\n# other files, so use this wisely.\n#\n# Notice option \"include\"
    won't be rewritten by command \"CONFIG REWRITE\"\n# from admin or Redis Sentinel.
    Since Redis always uses the last processed\n# line as value of a configuration
    directive, you'd better put includes\n# at the beginning of this file to avoid
    overwriting config change at runtime.\n#\n# If instead you are interested in using
    includes to override configuration\n# options, it is better to use include as
    the last line.\n#\n# include /path/to/local.conf\n# include /path/to/other.conf\n\n##################################
    MODULES #####################################\n\n# Load modules at startup. If
    the server is not able to load modules\n# it will abort. It is possible to use
    multiple loadmodule directives.\n#\n# loadmodule /path/to/my_module.so\n# loadmodule
    /path/to/other_module.so\n\n################################## NETWORK #####################################\n\n#
    By default, if no \"bind\" configuration directive is specified, Redis listens\n#
    for connections from all the network interfaces available on the server.\n# It
    is possible to listen to just one or multiple selected interfaces using\n# the
    \"bind\" configuration directive, followed by one or more IP addresses.\n#\n#
    Examples:\n#\n# bind 192.168.1.100 10.0.0.1\n# bind 127.0.0.1 ::1\n#\n# ~~~ WARNING
    ~~~ If the computer running Redis is directly exposed to the\n# internet, binding
    to all the interfaces is dangerous and will expose the\n# instance to everybody
    on the internet. So by default we uncomment the\n# following bind directive, that
    will force Redis to listen only into\n# the IPv4 loopback interface address (this
    means Redis will be able to\n# accept connections only from clients running into
    the same computer it\n# is running).\n#\n# IF YOU ARE SURE YOU WANT YOUR INSTANCE
    TO LISTEN TO ALL THE INTERFACES\n# JUST COMMENT THE FOLLOWING LINE.\n# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nbind
    127.0.0.1\n\n# Protected mode is a layer of security protection, in order to avoid
    that\n# Redis instances left open on the internet are accessed and exploited.\n#\n#
    When protected mode is on and if:\n#\n# 1) The server is not binding explicitly
    to a set of addresses using the\n#    \"bind\" directive.\n# 2) No password is
    configured.\n#\n# The server only accepts connections from clients connecting
    from the\n# IPv4 and IPv6 loopback addresses 127.0.0.1 and ::1, and from Unix
    domain\n# sockets.\n#\n# By default protected mode is enabled. You should disable
    it only if\n# you are sure you want clients from other hosts to connect to Redis\n#
    even if no authentication is configured, nor a specific set of interfaces\n# are
    explicitly listed using the \"bind\" directive.\nprotected-mode no\n\n# Accept
    connections on the specified port, default is 6379 (IANA #815344).\n# If port
    0 is specified Redis will not listen on a TCP socket.\nport 6379\n\n# TCP listen()
    backlog.\n#\n# In high requests-per-second environments you need an high backlog
    in order\n# to avoid slow clients connections issues. Note that the Linux kernel\n#
    will silently truncate it to the value of /proc/sys/net/core/somaxconn so\n# make
    sure to raise both the value of somaxconn and tcp_max_syn_backlog\n# in order
    to get the desired effect.\ntcp-backlog 511\n\n# Unix socket.\n#\n# Specify the
    path for the Unix socket that will be used to listen for\n# incoming connections.
    There is no default, so Redis will not listen\n# on a unix socket when not specified.\n#\n#
    unixsocket /tmp/redis.sock\n# unixsocketperm 700\n\n# Close the connection after
    a client is idle for N seconds (0 to disable)\ntimeout 0\n\n# TCP keepalive.\n#\n#
    If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence\n# of communication.
    This is useful for two reasons:\n#\n# 1) Detect dead peers.\n# 2) Take the connection
    alive from the point of view of network\n#    equipment in the middle.\n#\n# On
    Linux, the specified value (in seconds) is the period used to send ACKs.\n# Note
    that to close the connection the double of the time is needed.\n# On other kernels
    the period depends on the kernel configuration.\n#\n# A reasonable value for this
    option is 300 seconds, which is the new\n# Redis default starting with Redis 3.2.1.\ntcp-keepalive
    300\n\n################################# TLS/SSL #####################################\n\n#
    By default, TLS/SSL is disabled. To enable it, the \"tls-port\" configuration\n#
    directive can be used to define TLS-listening ports. To enable TLS on the\n# default
    port, use:\n#\n# port 0\n# tls-port 6379\n\n# Configure a X.509 certificate and
    private key to use for authenticating the\n# server to connected clients, masters
    or cluster peers.  These files should be\n# PEM formatted.\n#\n# tls-cert-file
    redis.crt \n# tls-key-file redis.key\n\n# Configure a DH parameters file to enable
    Diffie-Hellman (DH) key exchange:\n#\n# tls-dh-params-file redis.dh\n\n# Configure
    a CA certificate(s) bundle or directory to authenticate TLS/SSL\n# clients and
    peers.  Redis requires an explicit configuration of at least one\n# of these,
    and will not implicitly use the system wide configuration.\n#\n# tls-ca-cert-file
    ca.crt\n# tls-ca-cert-dir /etc/ssl/certs\n\n# By default, clients (including replica
    servers) on a TLS port are required\n# to authenticate using valid client side
    certificates.\n#\n# It is possible to disable authentication using this directive.\n#\n#
    tls-auth-clients no\n\n# By default, a Redis replica does not attempt to establish
    a TLS connection\n# with its master.\n#\n# Use the following directive to enable
    TLS on replication links.\n#\n# tls-replication yes\n\n# By default, the Redis
    Cluster bus uses a plain TCP connection. To enable\n# TLS for the bus protocol,
    use the following directive:\n#\n# tls-cluster yes\n\n# Explicitly specify TLS
    versions to support. Allowed values are case insensitive\n# and include \"TLSv1\",
    \"TLSv1.1\", \"TLSv1.2\", \"TLSv1.3\" (OpenSSL >= 1.1.1) or\n# any combination.
    To enable only TLSv1.2 and TLSv1.3, use:\n#\n# tls-protocols \"TLSv1.2 TLSv1.3\"\n\n#
    Configure allowed ciphers.  See the ciphers(1ssl) manpage for more information\n#
    about the syntax of this string.\n#\n# Note: this configuration applies only to
    <= TLSv1.2.\n#\n# tls-ciphers DEFAULT:!MEDIUM\n\n# Configure allowed TLSv1.3 ciphersuites.
    \ See the ciphers(1ssl) manpage for more\n# information about the syntax of this
    string, and specifically for TLSv1.3\n# ciphersuites.\n#\n# tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256\n\n#
    When choosing a cipher, use the server's preference instead of the client\n# preference.
    By default, the server follows the client's preference.\n#\n# tls-prefer-server-ciphers
    yes\n\n################################# GENERAL #####################################\n\n#
    By default Redis does not run as a daemon. Use 'yes' if you need it.\n# Note that
    Redis will write a pid file in /var/run/redis.pid when daemonized.\ndaemonize
    no\n\n# If you run Redis from upstart or systemd, Redis can interact with your\n#
    supervision tree. Options:\n#   supervised no      - no supervision interaction\n#
    \  supervised upstart - signal upstart by putting Redis into SIGSTOP mode\n#   supervised
    systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET\n#   supervised
    auto    - detect upstart or systemd method based on\n#                        UPSTART_JOB
    or NOTIFY_SOCKET environment variables\n# Note: these supervision methods only
    signal \"process is ready.\"\n#       They do not enable continuous liveness pings
    back to your supervisor.\nsupervised no\n\n# If a pid file is specified, Redis
    writes it where specified at startup\n# and removes it at exit.\n#\n# When the
    server runs non daemonized, no pid file is created if none is\n# specified in
    the configuration. When the server is daemonized, the pid file\n# is used even
    if not specified, defaulting to \"/var/run/redis.pid\".\n#\n# Creating a pid file
    is best effort: if Redis is not able to create it\n# nothing bad happens, the
    server will start and run normally.\npidfile /var/run/redis_6379.pid\n\n# Specify
    the server verbosity level.\n# This can be one of:\n# debug (a lot of information,
    useful for development/testing)\n# verbose (many rarely useful info, but not a
    mess like the debug level)\n# notice (moderately verbose, what you want in production
    probably)\n# warning (only very important / critical messages are logged)\nloglevel
    notice\n\n# Specify the log file name. Also the empty string can be used to force\n#
    Redis to log on the standard output. Note that if you use standard\n# output for
    logging but daemonize, logs will be sent to /dev/null\nlogfile \"\"\n\n# To enable
    logging to the system logger, just set 'syslog-enabled' to yes,\n# and optionally
    update the other syslog parameters to suit your needs.\n# syslog-enabled no\n\n#
    Specify the syslog identity.\n# syslog-ident redis\n\n# Specify the syslog facility.
    Must be USER or between LOCAL0-LOCAL7.\n# syslog-facility local0\n\n# Set the
    number of databases. The default database is DB 0, you can select\n# a different
    one on a per-connection basis using SELECT <dbid> where\n# dbid is a number between
    0 and 'databases'-1\ndatabases 16\n\n# By default Redis shows an ASCII art logo
    only when started to log to the\n# standard output and if the standard output
    is a TTY. Basically this means\n# that normally a logo is displayed only in interactive
    sessions.\n#\n# However it is possible to force the pre-4.0 behavior and always
    show a\n# ASCII art logo in startup logs by setting the following option to yes.\nalways-show-logo
    yes\n\n################################ SNAPSHOTTING  ################################\n#\n#
    Save the DB on disk:\n#\n#   save <seconds> <changes>\n#\n#   Will save the DB
    if both the given number of seconds and the given\n#   number of write operations
    against the DB occurred.\n#\n#   In the example below the behaviour will be to
    save:\n#   after 900 sec (15 min) if at least 1 key changed\n#   after 300 sec
    (5 min) if at least 10 keys changed\n#   after 60 sec if at least 10000 keys changed\n#\n#
    \  Note: you can disable saving completely by commenting out all \"save\" lines.\n#\n#
    \  It is also possible to remove all the previously configured save\n#   points
    by adding a save directive with a single empty string argument\n#   like in the
    following example:\n#\n#   save \"\"\n\nsave 900 1\nsave 300 10\nsave 60 10000\n\n#
    By default Redis will stop accepting writes if RDB snapshots are enabled\n# (at
    least one save point) and the latest background save failed.\n# This will make
    the user aware (in a hard way) that data is not persisting\n# on disk properly,
    otherwise chances are that no one will notice and some\n# disaster will happen.\n#\n#
    If the background saving process will start working again Redis will\n# automatically
    allow writes again.\n#\n# However if you have setup your proper monitoring of
    the Redis server\n# and persistence, you may want to disable this feature so that
    Redis will\n# continue to work as usual even if there are problems with disk,\n#
    permissions, and so forth.\nstop-writes-on-bgsave-error yes\n\n# Compress string
    objects using LZF when dump .rdb databases?\n# For default that's set to 'yes'
    as it's almost always a win.\n# If you want to save some CPU in the saving child
    set it to 'no' but\n# the dataset will likely be bigger if you have compressible
    values or keys.\nrdbcompression yes\n\n# Since version 5 of RDB a CRC64 checksum
    is placed at the end of the file.\n# This makes the format more resistant to corruption
    but there is a performance\n# hit to pay (around 10%) when saving and loading
    RDB files, so you can disable it\n# for maximum performances.\n#\n# RDB files
    created with checksum disabled have a checksum of zero that will\n# tell the loading
    code to skip the check.\nrdbchecksum yes\n\n# The filename where to dump the DB\ndbfilename
    dump.rdb\n\n# Remove RDB files used by replication in instances without persistence\n#
    enabled. By default this option is disabled, however there are environments\n#
    where for regulations or other security concerns, RDB files persisted on\n# disk
    by masters in order to feed replicas, or stored on disk by replicas\n# in order
    to load them for the initial synchronization, should be deleted\n# ASAP. Note
    that this option ONLY WORKS in instances that have both AOF\n# and RDB persistence
    disabled, otherwise is completely ignored.\n#\n# An alternative (and sometimes
    better) way to obtain the same effect is\n# to use diskless replication on both
    master and replicas instances. However\n# in the case of replicas, diskless is
    not always an option.\nrdb-del-sync-files no\n\n# The working directory.\n#\n#
    The DB will be written inside this directory, with the filename specified\n# above
    using the 'dbfilename' configuration directive.\n#\n# The Append Only File will
    also be created inside this directory.\n#\n# Note that you must specify a directory
    here, not a file name.\ndir ./\n\n################################# REPLICATION
    #################################\n\n# Master-Replica replication. Use replicaof
    to make a Redis instance a copy of\n# another Redis server. A few things to understand
    ASAP about Redis replication.\n#\n#   +------------------+      +---------------+\n#
    \  |      Master      | ---> |    Replica    |\n#   | (receive writes) |      |
    \ (exact copy) |\n#   +------------------+      +---------------+\n#\n# 1) Redis
    replication is asynchronous, but you can configure a master to\n#    stop accepting
    writes if it appears to be not connected with at least\n#    a given number of
    replicas.\n# 2) Redis replicas are able to perform a partial resynchronization
    with the\n#    master if the replication link is lost for a relatively small amount
    of\n#    time. You may want to configure the replication backlog size (see the
    next\n#    sections of this file) with a sensible value depending on your needs.\n#
    3) Replication is automatic and does not need user intervention. After a\n#    network
    partition replicas automatically try to reconnect to masters\n#    and resynchronize
    with them.\n#\n# replicaof <masterip> <masterport>\n\n# If the master is password
    protected (using the \"requirepass\" configuration\n# directive below) it is possible
    to tell the replica to authenticate before\n# starting the replication synchronization
    process, otherwise the master will\n# refuse the replica request.\n#\n# masterauth
    <master-password>\n#\n# However this is not enough if you are using Redis ACLs
    (for Redis version\n# 6 or greater), and the default user is not capable of running
    the PSYNC\n# command and/or other commands needed for replication. In this case
    it's\n# better to configure a special user to use with replication, and specify
    the\n# masteruser configuration as such:\n#\n# masteruser <username>\n#\n# When
    masteruser is specified, the replica will authenticate against its\n# master using
    the new AUTH form: AUTH <username> <password>.\n\n# When a replica loses its connection
    with the master, or when the replication\n# is still in progress, the replica
    can act in two different ways:\n#\n# 1) if replica-serve-stale-data is set to
    'yes' (the default) the replica will\n#    still reply to client requests, possibly
    with out of date data, or the\n#    data set may just be empty if this is the
    first synchronization.\n#\n# 2) if replica-serve-stale-data is set to 'no' the
    replica will reply with\n#    an error \"SYNC with master in progress\" to all
    the kind of commands\n#    but to INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF,
    ROLE, CONFIG,\n#    SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH,
    PUBSUB,\n#    COMMAND, POST, HOST: and LATENCY.\n#\nreplica-serve-stale-data yes\n\n#
    You can configure a replica instance to accept writes or not. Writing against\n#
    a replica instance may be useful to store some ephemeral data (because data\n#
    written on a replica will be easily deleted after resync with the master) but\n#
    may also cause problems if clients are writing to it because of a\n# misconfiguration.\n#\n#
    Since Redis 2.6 by default replicas are read-only.\n#\n# Note: read only replicas
    are not designed to be exposed to untrusted clients\n# on the internet. It's just
    a protection layer against misuse of the instance.\n# Still a read only replica
    exports by default all the administrative commands\n# such as CONFIG, DEBUG, and
    so forth. To a limited extent you can improve\n# security of read only replicas
    using 'rename-command' to shadow all the\n# administrative / dangerous commands.\nreplica-read-only
    yes\n\n# Replication SYNC strategy: disk or socket.\n#\n# New replicas and reconnecting
    replicas that are not able to continue the\n# replication process just receiving
    differences, need to do what is called a\n# \"full synchronization\". An RDB file
    is transmitted from the master to the\n# replicas.\n#\n# The transmission can
    happen in two different ways:\n#\n# 1) Disk-backed: The Redis master creates a
    new process that writes the RDB\n#                 file on disk. Later the file
    is transferred by the parent\n#                 process to the replicas incrementally.\n#
    2) Diskless: The Redis master creates a new process that directly writes the\n#
    \             RDB file to replica sockets, without touching the disk at all.\n#\n#
    With disk-backed replication, while the RDB file is generated, more replicas\n#
    can be queued and served with the RDB file as soon as the current child\n# producing
    the RDB file finishes its work. With diskless replication instead\n# once the
    transfer starts, new replicas arriving will be queued and a new\n# transfer will
    start when the current one terminates.\n#\n# When diskless replication is used,
    the master waits a configurable amount of\n# time (in seconds) before starting
    the transfer in the hope that multiple\n# replicas will arrive and the transfer
    can be parallelized.\n#\n# With slow disks and fast (large bandwidth) networks,
    diskless replication\n# works better.\nrepl-diskless-sync no\n\n# When diskless
    replication is enabled, it is possible to configure the delay\n# the server waits
    in order to spawn the child that transfers the RDB via socket\n# to the replicas.\n#\n#
    This is important since once the transfer starts, it is not possible to serve\n#
    new replicas arriving, that will be queued for the next RDB transfer, so the\n#
    server waits a delay in order to let more replicas arrive.\n#\n# The delay is
    specified in seconds, and by default is 5 seconds. To disable\n# it entirely just
    set it to 0 seconds and the transfer will start ASAP.\nrepl-diskless-sync-delay
    5\n\n# -----------------------------------------------------------------------------\n#
    WARNING: RDB diskless load is experimental. Since in this setup the replica\n#
    does not immediately store an RDB on disk, it may cause data loss during\n# failovers.
    RDB diskless load + Redis modules not handling I/O reads may also\n# cause Redis
    to abort in case of I/O errors during the initial synchronization\n# stage with
    the master. Use only if your do what you are doing.\n# -----------------------------------------------------------------------------\n#\n#
    Replica can load the RDB it reads from the replication link directly from the\n#
    socket, or store the RDB to a file and read that file after it was completely\n#
    recived from the master.\n#\n# In many cases the disk is slower than the network,
    and storing and loading\n# the RDB file may increase replication time (and even
    increase the master's\n# Copy on Write memory and salve buffers).\n# However,
    parsing the RDB file directly from the socket may mean that we have\n# to flush
    the contents of the current database before the full rdb was\n# received. For
    this reason we have the following options:\n#\n# \"disabled\"    - Don't use diskless
    load (store the rdb file to the disk first)\n# \"on-empty-db\" - Use diskless
    load only when it is completely safe.\n# \"swapdb\"      - Keep a copy of the
    current db contents in RAM while parsing\n#                 the data directly
    from the socket. note that this requires\n#                 sufficient memory,
    if you don't have it, you risk an OOM kill.\nrepl-diskless-load disabled\n\n#
    Replicas send PINGs to server in a predefined interval. It's possible to\n# change
    this interval with the repl_ping_replica_period option. The default\n# value is
    10 seconds.\n#\n# repl-ping-replica-period 10\n\n# The following option sets the
    replication timeout for:\n#\n# 1) Bulk transfer I/O during SYNC, from the point
    of view of replica.\n# 2) Master timeout from the point of view of replicas (data,
    pings).\n# 3) Replica timeout from the point of view of masters (REPLCONF ACK
    pings).\n#\n# It is important to make sure that this value is greater than the
    value\n# specified for repl-ping-replica-period otherwise a timeout will be detected\n#
    every time there is low traffic between the master and the replica.\n#\n# repl-timeout
    60\n\n# Disable TCP_NODELAY on the replica socket after SYNC?\n#\n# If you select
    \"yes\" Redis will use a smaller number of TCP packets and\n# less bandwidth to
    send data to replicas. But this can add a delay for\n# the data to appear on the
    replica side, up to 40 milliseconds with\n# Linux kernels using a default configuration.\n#\n#
    If you select \"no\" the delay for data to appear on the replica side will\n#
    be reduced but more bandwidth will be used for replication.\n#\n# By default we
    optimize for low latency, but in very high traffic conditions\n# or when the master
    and replicas are many hops away, turning this to \"yes\" may\n# be a good idea.\nrepl-disable-tcp-nodelay
    no\n\n# Set the replication backlog size. The backlog is a buffer that accumulates\n#
    replica data when replicas are disconnected for some time, so that when a\n# replica
    wants to reconnect again, often a full resync is not needed, but a\n# partial
    resync is enough, just passing the portion of data the replica\n# missed while
    disconnected.\n#\n# The bigger the replication backlog, the longer the time the
    replica can be\n# disconnected and later be able to perform a partial resynchronization.\n#\n#
    The backlog is only allocated once there is at least a replica connected.\n#\n#
    repl-backlog-size 1mb\n\n# After a master has no longer connected replicas for
    some time, the backlog\n# will be freed. The following option configures the amount
    of seconds that\n# need to elapse, starting from the time the last replica disconnected,
    for\n# the backlog buffer to be freed.\n#\n# Note that replicas never free the
    backlog for timeout, since they may be\n# promoted to masters later, and should
    be able to correctly \"partially\n# resynchronize\" with the replicas: hence they
    should always accumulate backlog.\n#\n# A value of 0 means to never release the
    backlog.\n#\n# repl-backlog-ttl 3600\n\n# The replica priority is an integer number
    published by Redis in the INFO\n# output. It is used by Redis Sentinel in order
    to select a replica to promote\n# into a master if the master is no longer working
    correctly.\n#\n# A replica with a low priority number is considered better for
    promotion, so\n# for instance if there are three replicas with priority 10, 100,
    25 Sentinel\n# will pick the one with priority 10, that is the lowest.\n#\n# However
    a special priority of 0 marks the replica as not able to perform the\n# role of
    master, so a replica with priority of 0 will never be selected by\n# Redis Sentinel
    for promotion.\n#\n# By default the priority is 100.\nreplica-priority 100\n\n#
    It is possible for a master to stop accepting writes if there are less than\n#
    N replicas connected, having a lag less or equal than M seconds.\n#\n# The N replicas
    need to be in \"online\" state.\n#\n# The lag in seconds, that must be <= the
    specified value, is calculated from\n# the last ping received from the replica,
    that is usually sent every second.\n#\n# This option does not GUARANTEE that N
    replicas will accept the write, but\n# will limit the window of exposure for lost
    writes in case not enough replicas\n# are available, to the specified number of
    seconds.\n#\n# For example to require at least 3 replicas with a lag <= 10 seconds
    use:\n#\n# min-replicas-to-write 3\n# min-replicas-max-lag 10\n#\n# Setting one
    or the other to 0 disables the feature.\n#\n# By default min-replicas-to-write
    is set to 0 (feature disabled) and\n# min-replicas-max-lag is set to 10.\n\n#
    A Redis master is able to list the address and port of the attached\n# replicas
    in different ways. For example the \"INFO replication\" section\n# offers this
    information, which is used, among other tools, by\n# Redis Sentinel in order to
    discover replica instances.\n# Another place where this info is available is in
    the output of the\n# \"ROLE\" command of a master.\n#\n# The listed IP and address
    normally reported by a replica is obtained\n# in the following way:\n#\n#   IP:
    The address is auto detected by checking the peer address\n#   of the socket used
    by the replica to connect with the master.\n#\n#   Port: The port is communicated
    by the replica during the replication\n#   handshake, and is normally the port
    that the replica is using to\n#   listen for connections.\n#\n# However when port
    forwarding or Network Address Translation (NAT) is\n# used, the replica may be
    actually reachable via different IP and port\n# pairs. The following two options
    can be used by a replica in order to\n# report to its master a specific set of
    IP and port, so that both INFO\n# and ROLE will report those values.\n#\n# There
    is no need to use both the options if you need to override just\n# the port or
    the IP address.\n#\n# replica-announce-ip 5.5.5.5\n# replica-announce-port 1234\n\n###############################
    KEYS TRACKING #################################\n\n# Redis implements server assisted
    support for client side caching of values.\n# This is implemented using an invalidation
    table that remembers, using\n# 16 millions of slots, what clients may have certain
    subsets of keys. In turn\n# this is used in order to send invalidation messages
    to clients. Please\n# to understand more about the feature check this page:\n#\n#
    \  https://redis.io/topics/client-side-caching\n#\n# When tracking is enabled
    for a client, all the read only queries are assumed\n# to be cached: this will
    force Redis to store information in the invalidation\n# table. When keys are modified,
    such information is flushed away, and\n# invalidation messages are sent to the
    clients. However if the workload is\n# heavily dominated by reads, Redis could
    use more and more memory in order\n# to track the keys fetched by many clients.\n#\n#
    For this reason it is possible to configure a maximum fill value for the\n# invalidation
    table. By default it is set to 1M of keys, and once this limit\n# is reached,
    Redis will start to evict keys in the invalidation table\n# even if they were
    not modified, just to reclaim memory: this will in turn\n# force the clients to
    invalidate the cached values. Basically the table\n# maximum size is a trade off
    between the memory you want to spend server\n# side to track information about
    who cached what, and the ability of clients\n# to retain cached objects in memory.\n#\n#
    If you set the value to 0, it means there are no limits, and Redis will\n# retain
    as many keys as needed in the invalidation table.\n# In the \"stats\" INFO section,
    you can find information about the number of\n# keys in the invalidation table
    at every given moment.\n#\n# Note: when key tracking is used in broadcasting mode,
    no memory is used\n# in the server side so this setting is useless.\n#\n# tracking-table-max-keys
    1000000\n\n################################## SECURITY ###################################\n\n#
    Warning: since Redis is pretty fast an outside user can try up to\n# 1 million
    passwords per second against a modern box. This means that you\n# should use very
    strong passwords, otherwise they will be very easy to break.\n# Note that because
    the password is really a shared secret between the client\n# and the server, and
    should not be memorized by any human, the password\n# can be easily a long string
    from /dev/urandom or whatever, so by using a\n# long and unguessable password
    no brute force attack will be possible.\n\n# Redis ACL users are defined in the
    following format:\n#\n#   user <username> ... acl rules ...\n#\n# For example:\n#\n#
    \  user worker +@list +@connection ~jobs:* on >ffa9203c493aa99\n#\n# The special
    username \"default\" is used for new connections. If this user\n# has the \"nopass\"
    rule, then new connections will be immediately authenticated\n# as the \"default\"
    user without the need of any password provided via the\n# AUTH command. Otherwise
    if the \"default\" user is not flagged with \"nopass\"\n# the connections will
    start in not authenticated state, and will require\n# AUTH (or the HELLO command
    AUTH option) in order to be authenticated and\n# start to work.\n#\n# The ACL
    rules that describe what an user can do are the following:\n#\n#  on           Enable
    the user: it is possible to authenticate as this user.\n#  off          Disable
    the user: it's no longer possible to authenticate\n#               with this user,
    however the already authenticated connections\n#               will still work.\n#
    \ +<command>   Allow the execution of that command\n#  -<command>   Disallow the
    execution of that command\n#  +@<category> Allow the execution of all the commands
    in such category\n#               with valid categories are like @admin, @set,
    @sortedset, ...\n#               and so forth, see the full list in the server.c
    file where\n#               the Redis command table is described and defined.\n#
    \              The special category @all means all the commands, but currently\n#
    \              present in the server, and that will be loaded in the future\n#
    \              via modules.\n#  +<command>|subcommand    Allow a specific subcommand
    of an otherwise\n#                           disabled command. Note that this
    form is not\n#                           allowed as negative like -DEBUG|SEGFAULT,
    but\n#                           only additive starting with \"+\".\n#  allcommands
    \ Alias for +@all. Note that it implies the ability to execute\n#               all
    the future commands loaded via the modules system.\n#  nocommands   Alias for
    -@all.\n#  ~<pattern>   Add a pattern of keys that can be mentioned as part of\n#
    \              commands. For instance ~* allows all the keys. The pattern\n#               is
    a glob-style pattern like the one of KEYS.\n#               It is possible to
    specify multiple patterns.\n#  allkeys      Alias for ~*\n#  resetkeys    Flush
    the list of allowed keys patterns.\n#  ><password>  Add this passowrd to the list
    of valid password for the user.\n#               For example >mypass will add
    \"mypass\" to the list.\n#               This directive clears the \"nopass\"
    flag (see later).\n#  <<password>  Remove this password from the list of valid
    passwords.\n#  nopass       All the set passwords of the user are removed, and
    the user\n#               is flagged as requiring no password: it means that every\n#
    \              password will work against this user. If this directive is\n#               used
    for the default user, every new connection will be\n#               immediately
    authenticated with the default user without\n#               any explicit AUTH
    command required. Note that the \"resetpass\"\n#               directive will
    clear this condition.\n#  resetpass    Flush the list of allowed passwords. Moreover
    removes the\n#               \"nopass\" status. After \"resetpass\" the user has
    no associated\n#               passwords and there is no way to authenticate without
    adding\n#               some password (or setting it as \"nopass\" later).\n#
    \ reset        Performs the following actions: resetpass, resetkeys, off,\n#               -@all.
    The user returns to the same state it has immediately\n#               after its
    creation.\n#\n# ACL rules can be specified in any order: for instance you can
    start with\n# passwords, then flags, or key patterns. However note that the additive\n#
    and subtractive rules will CHANGE MEANING depending on the ordering.\n# For instance
    see the following example:\n#\n#   user alice on +@all -DEBUG ~* >somepassword\n#\n#
    This will allow \"alice\" to use all the commands with the exception of the\n#
    DEBUG command, since +@all added all the commands to the set of the commands\n#
    alice can use, and later DEBUG was removed. However if we invert the order\n#
    of two ACL rules the result will be different:\n#\n#   user alice on -DEBUG +@all
    ~* >somepassword\n#\n# Now DEBUG was removed when alice had yet no commands in
    the set of allowed\n# commands, later all the commands are added, so the user
    will be able to\n# execute everything.\n#\n# Basically ACL rules are processed
    left-to-right.\n#\n# For more information about ACL configuration please refer
    to\n# the Redis web site at https://redis.io/topics/acl\n\n# ACL LOG\n#\n# The
    ACL Log tracks failed commands and authentication events associated\n# with ACLs.
    The ACL Log is useful to troubleshoot failed commands blocked \n# by ACLs. The
    ACL Log is stored in and consumes memory. There is no limit\n# to its length.You
    can reclaim memory with ACL LOG RESET or set a maximum\n# length below.\nacllog-max-len
    128\n\n# Using an external ACL file\n#\n# Instead of configuring users here in
    this file, it is possible to use\n# a stand-alone file just listing users. The
    two methods cannot be mixed:\n# if you configure users here and at the same time
    you activate the exteranl\n# ACL file, the server will refuse to start.\n#\n#
    The format of the external ACL user file is exactly the same as the\n# format
    that is used inside redis.conf to describe users.\n#\n# aclfile /etc/redis/users.acl\n#
    aclfile /usr/local/etc/redis/users.acl\n\n# IMPORTANT NOTE: starting with Redis
    6 \"requirepass\" is just a compatiblity\n# layer on top of the new ACL system.
    The option effect will be just setting\n# the password for the default user. Clients
    will still authenticate using\n# AUTH <password> as usually, or more explicitly
    with AUTH default <password>\n# if they follow the new protocol: both will work.\n#\n
    #requirepass TestDB@home2\n\n# Command renaming (DEPRECATED).\n#\n# ------------------------------------------------------------------------\n#
    WARNING: avoid using this option if possible. Instead use ACLs to remove\n# commands
    from the default user, and put them only in some admin user you\n# create for
    administrative purposes.\n# ------------------------------------------------------------------------\n#\n#
    It is possible to change the name of dangerous commands in a shared\n# environment.
    For instance the CONFIG command may be renamed into something\n# hard to guess
    so that it will still be available for internal-use tools\n# but not available
    for general clients.\n#\n# Example:\n#\n# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52\n#\n#
    It is also possible to completely kill a command by renaming it into\n# an empty
    string:\n#\n# rename-command CONFIG \"\"\n#\n# Please note that changing the name
    of commands that are logged into the\n# AOF file or transmitted to replicas may
    cause problems.\n\n################################### CLIENTS ####################################\n\n#
    Set the max number of connected clients at the same time. By default\n# this limit
    is set to 10000 clients, however if the Redis server is not\n# able to configure
    the process file limit to allow for the specified limit\n# the max number of allowed
    clients is set to the current file limit\n# minus 32 (as Redis reserves a few
    file descriptors for internal uses).\n#\n# Once the limit is reached Redis will
    close all the new connections sending\n# an error 'max number of clients reached'.\n#\n#
    maxclients 10000\n\n############################## MEMORY MANAGEMENT ################################\n\n#
    Set a memory usage limit to the specified amount of bytes.\n# When the memory
    limit is reached Redis will try to remove keys\n# according to the eviction policy
    selected (see maxmemory-policy).\n#\n# If Redis can't remove keys according to
    the policy, or if the policy is\n# set to 'noeviction', Redis will start to reply
    with errors to commands\n# that would use more memory, like SET, LPUSH, and so
    on, and will continue\n# to reply to read-only commands like GET.\n#\n# This option
    is usually useful when using Redis as an LRU or LFU cache, or to\n# set a hard
    memory limit for an instance (using the 'noeviction' policy).\n#\n# WARNING: If
    you have replicas attached to an instance with maxmemory on,\n# the size of the
    output buffers needed to feed the replicas are subtracted\n# from the used memory
    count, so that network problems / resyncs will\n# not trigger a loop where keys
    are evicted, and in turn the output\n# buffer of replicas is full with DELs of
    keys evicted triggering the deletion\n# of more keys, and so forth until the database
    is completely emptied.\n#\n# In short... if you have replicas attached it is suggested
    that you set a lower\n# limit for maxmemory so that there is some free RAM on
    the system for replica\n# output buffers (but this is not needed if the policy
    is 'noeviction').\n#\n# maxmemory <bytes>\n\n# MAXMEMORY POLICY: how Redis will
    select what to remove when maxmemory\n# is reached. You can select one from the
    following behaviors:\n#\n# volatile-lru -> Evict using approximated LRU, only
    keys with an expire set.\n# allkeys-lru -> Evict any key using approximated LRU.\n#
    volatile-lfu -> Evict using approximated LFU, only keys with an expire set.\n#
    allkeys-lfu -> Evict any key using approximated LFU.\n# volatile-random -> Remove
    a random key having an expire set.\n# allkeys-random -> Remove a random key, any
    key.\n# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)\n#
    noeviction -> Don't evict anything, just return an error on write operations.\n#\n#
    LRU means Least Recently Used\n# LFU means Least Frequently Used\n#\n# Both LRU,
    LFU and volatile-ttl are implemented using approximated\n# randomized algorithms.\n#\n#
    Note: with any of the above policies, Redis will return an error on write\n#       operations,
    when there are no suitable keys for eviction.\n#\n#       At the date of writing
    these commands are: set setnx setex append\n#       incr decr rpush lpush rpushx
    lpushx linsert lset rpoplpush sadd\n#       sinter sinterstore sunion sunionstore
    sdiff sdiffstore zadd zincrby\n#       zunionstore zinterstore hset hsetnx hmset
    hincrby incrby decrby\n#       getset mset msetnx exec sort\n#\n# The default
    is:\n#\n# maxmemory-policy noeviction\n\n# LRU, LFU and minimal TTL algorithms
    are not precise algorithms but approximated\n# algorithms (in order to save memory),
    so you can tune it for speed or\n# accuracy. For default Redis will check five
    keys and pick the one that was\n# used less recently, you can change the sample
    size using the following\n# configuration directive.\n#\n# The default of 5 produces
    good enough results. 10 Approximates very closely\n# true LRU but costs more CPU.
    3 is faster but not very accurate.\n#\n# maxmemory-samples 5\n\n# Starting from
    Redis 5, by default a replica will ignore its maxmemory setting\n# (unless it
    is promoted to master after a failover or manually). It means\n# that the eviction
    of keys will be just handled by the master, sending the\n# DEL commands to the
    replica as keys evict in the master side.\n#\n# This behavior ensures that masters
    and replicas stay consistent, and is usually\n# what you want, however if your
    replica is writable, or you want the replica\n# to have a different memory setting,
    and you are sure all the writes performed\n# to the replica are idempotent, then
    you may change this default (but be sure\n# to understand what you are doing).\n#\n#
    Note that since the replica by default does not evict, it may end using more\n#
    memory than the one set via maxmemory (there are certain buffers that may\n# be
    larger on the replica, or data structures may sometimes take more memory\n# and
    so forth). So make sure you monitor your replicas and make sure they\n# have enough
    memory to never hit a real out-of-memory condition before the\n# master hits the
    configured maxmemory setting.\n#\n# replica-ignore-maxmemory yes\n\n# Redis reclaims
    expired keys in two ways: upon access when those keys are\n# found to be expired,
    and also in background, in what is called the\n# \"active expire key\". The key
    space is slowly and interactively scanned\n# looking for expired keys to reclaim,
    so that it is possible to free memory\n# of keys that are expired and will never
    be accessed again in a short time.\n#\n# The default effort of the expire cycle
    will try to avoid having more than\n# ten percent of expired keys still in memory,
    and will try to avoid consuming\n# more than 25% of total memory and to add latency
    to the system. However\n# it is possible to increase the expire \"effort\" that
    is normally set to\n# \"1\", to a greater value, up to the value \"10\". At its
    maximum value the\n# system will use more CPU, longer cycles (and technically
    may introduce\n# more latency), and will tollerate less already expired keys still
    present\n# in the system. It's a tradeoff betweeen memory, CPU and latecy.\n#\n#
    active-expire-effort 1\n\n############################# LAZY FREEING ####################################\n\n#
    Redis has two primitives to delete keys. One is called DEL and is a blocking\n#
    deletion of the object. It means that the server stops processing new commands\n#
    in order to reclaim all the memory associated with an object in a synchronous\n#
    way. If the key deleted is associated with a small object, the time needed\n#
    in order to execute the DEL command is very small and comparable to most other\n#
    O(1) or O(log_N) commands in Redis. However if the key is associated with an\n#
    aggregated value containing millions of elements, the server can block for\n#
    a long time (even seconds) in order to complete the operation.\n#\n# For the above
    reasons Redis also offers non blocking deletion primitives\n# such as UNLINK (non
    blocking DEL) and the ASYNC option of FLUSHALL and\n# FLUSHDB commands, in order
    to reclaim memory in background. Those commands\n# are executed in constant time.
    Another thread will incrementally free the\n# object in the background as fast
    as possible.\n#\n# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.\n#
    It's up to the design of the application to understand when it is a good\n# idea
    to use one or the other. However the Redis server sometimes has to\n# delete keys
    or flush the whole database as a side effect of other operations.\n# Specifically
    Redis deletes objects independently of a user call in the\n# following scenarios:\n#\n#
    1) On eviction, because of the maxmemory and maxmemory policy configurations,\n#
    \   in order to make room for new data, without going over the specified\n#    memory
    limit.\n# 2) Because of expire: when a key with an associated time to live (see
    the\n#    EXPIRE command) must be deleted from memory.\n# 3) Because of a side
    effect of a command that stores data on a key that may\n#    already exist. For
    example the RENAME command may delete the old key\n#    content when it is replaced
    with another one. Similarly SUNIONSTORE\n#    or SORT with STORE option may delete
    existing keys. The SET command\n#    itself removes any old content of the specified
    key in order to replace\n#    it with the specified string.\n# 4) During replication,
    when a replica performs a full resynchronization with\n#    its master, the content
    of the whole database is removed in order to\n#    load the RDB file just transferred.\n#\n#
    In all the above cases the default is to delete objects in a blocking way,\n#
    like if DEL was called. However you can configure each case specifically\n# in
    order to instead release memory in a non-blocking way like if UNLINK\n# was called,
    using the following configuration directives.\n\nlazyfree-lazy-eviction no\nlazyfree-lazy-expire
    no\nlazyfree-lazy-server-del no\nreplica-lazy-flush no\n\n# It is also possible,
    for the case when to replace the user code DEL calls\n# with UNLINK calls is not
    easy, to modify the default behavior of the DEL\n# command to act exactly like
    UNLINK, using the following configuration\n# directive:\n\nlazyfree-lazy-user-del
    no\n\n################################ THREADED I/O #################################\n\n#
    Redis is mostly single threaded, however there are certain threaded\n# operations
    such as UNLINK, slow I/O accesses and other things that are\n# performed on side
    threads.\n#\n# Now it is also possible to handle Redis clients socket reads and
    writes\n# in different I/O threads. Since especially writing is so slow, normally\n#
    Redis users use pipelining in order to speedup the Redis performances per\n# core,
    and spawn multiple instances in order to scale more. Using I/O\n# threads it is
    possible to easily speedup two times Redis without resorting\n# to pipelining
    nor sharding of the instance.\n#\n# By default threading is disabled, we suggest
    enabling it only in machines\n# that have at least 4 or more cores, leaving at
    least one spare core.\n# Using more than 8 threads is unlikely to help much. We
    also recommend using\n# threaded I/O only if you actually have performance problems,
    with Redis\n# instances being able to use a quite big percentage of CPU time,
    otherwise\n# there is no point in using this feature.\n#\n# So for instance if
    you have a four cores boxes, try to use 2 or 3 I/O\n# threads, if you have a 8
    cores, try to use 6 threads. In order to\n# enable I/O threads use the following
    configuration directive:\n#\n# io-threads 4\n#\n# Setting io-threads to 1 will
    just use the main thread as usually.\n# When I/O threads are enabled, we only
    use threads for writes, that is\n# to thread the write(2) syscall and transfer
    the client buffers to the\n# socket. However it is also possible to enable threading
    of reads and\n# protocol parsing using the following configuration directive,
    by setting\n# it to yes:\n#\n# io-threads-do-reads no\n#\n# Usually threading
    reads doesn't help much.\n#\n# NOTE 1: This configuration directive cannot be
    changed at runtime via\n# CONFIG SET. Aso this feature currently does not work
    when SSL is\n# enabled.\n#\n# NOTE 2: If you want to test the Redis speedup using
    redis-benchmark, make\n# sure you also run the benchmark itself in threaded mode,
    using the\n# --threads option to match the number of Redis theads, otherwise you'll
    not\n# be able to notice the improvements.\n\n############################## APPEND
    ONLY MODE ###############################\n\n# By default Redis asynchronously
    dumps the dataset on disk. This mode is\n# good enough in many applications, but
    an issue with the Redis process or\n# a power outage may result into a few minutes
    of writes lost (depending on\n# the configured save points).\n#\n# The Append
    Only File is an alternative persistence mode that provides\n# much better durability.
    For instance using the default data fsync policy\n# (see later in the config file)
    Redis can lose just one second of writes in a\n# dramatic event like a server
    power outage, or a single write if something\n# wrong with the Redis process itself
    happens, but the operating system is\n# still running correctly.\n#\n# AOF and
    RDB persistence can be enabled at the same time without problems.\n# If the AOF
    is enabled on startup Redis will load the AOF, that is the file\n# with the better
    durability guarantees.\n#\n# Please check http://redis.io/topics/persistence for
    more information.\n\nappendonly no\n\n# The name of the append only file (default:
    \"appendonly.aof\")\n\nappendfilename \"appendonly.aof\"\n\n# The fsync() call
    tells the Operating System to actually write data on disk\n# instead of waiting
    for more data in the output buffer. Some OS will really flush\n# data on disk,
    some other OS will just try to do it ASAP.\n#\n# Redis supports three different
    modes:\n#\n# no: don't fsync, just let the OS flush the data when it wants. Faster.\n#
    always: fsync after every write to the append only log. Slow, Safest.\n# everysec:
    fsync only one time every second. Compromise.\n#\n# The default is \"everysec\",
    as that's usually the right compromise between\n# speed and data safety. It's
    up to you to understand if you can relax this to\n# \"no\" that will let the operating
    system flush the output buffer when\n# it wants, for better performances (but
    if you can live with the idea of\n# some data loss consider the default persistence
    mode that's snapshotting),\n# or on the contrary, use \"always\" that's very slow
    but a bit safer than\n# everysec.\n#\n# More details please check the following
    article:\n# http://antirez.com/post/redis-persistence-demystified.html\n#\n# If
    unsure, use \"everysec\".\n\n# appendfsync always\nappendfsync everysec\n# appendfsync
    no\n\n# When the AOF fsync policy is set to always or everysec, and a background\n#
    saving process (a background save or AOF log background rewriting) is\n# performing
    a lot of I/O against the disk, in some Linux configurations\n# Redis may block
    too long on the fsync() call. Note that there is no fix for\n# this currently,
    as even performing fsync in a different thread will block\n# our synchronous write(2)
    call.\n#\n# In order to mitigate this problem it's possible to use the following
    option\n# that will prevent fsync() from being called in the main process while
    a\n# BGSAVE or BGREWRITEAOF is in progress.\n#\n# This means that while another
    child is saving, the durability of Redis is\n# the same as \"appendfsync none\".
    In practical terms, this means that it is\n# possible to lose up to 30 seconds
    of log in the worst scenario (with the\n# default Linux settings).\n#\n# If you
    have latency problems turn this to \"yes\". Otherwise leave it as\n# \"no\" that
    is the safest pick from the point of view of durability.\n\nno-appendfsync-on-rewrite
    no\n\n# Automatic rewrite of the append only file.\n# Redis is able to automatically
    rewrite the log file implicitly calling\n# BGREWRITEAOF when the AOF log size
    grows by the specified percentage.\n#\n# This is how it works: Redis remembers
    the size of the AOF file after the\n# latest rewrite (if no rewrite has happened
    since the restart, the size of\n# the AOF at startup is used).\n#\n# This base
    size is compared to the current size. If the current size is\n# bigger than the
    specified percentage, the rewrite is triggered. Also\n# you need to specify a
    minimal size for the AOF file to be rewritten, this\n# is useful to avoid rewriting
    the AOF file even if the percentage increase\n# is reached but it is still pretty
    small.\n#\n# Specify a percentage of zero in order to disable the automatic AOF\n#
    rewrite feature.\n\nauto-aof-rewrite-percentage 100\nauto-aof-rewrite-min-size
    64mb\n\n# An AOF file may be found to be truncated at the end during the Redis\n#
    startup process, when the AOF data gets loaded back into memory.\n# This may happen
    when the system where Redis is running\n# crashes, especially when an ext4 filesystem
    is mounted without the\n# data=ordered option (however this can't happen when
    Redis itself\n# crashes or aborts but the operating system still works correctly).\n#\n#
    Redis can either exit with an error when this happens, or load as much\n# data
    as possible (the default now) and start if the AOF file is found\n# to be truncated
    at the end. The following option controls this behavior.\n#\n# If aof-load-truncated
    is set to yes, a truncated AOF file is loaded and\n# the Redis server starts emitting
    a log to inform the user of the event.\n# Otherwise if the option is set to no,
    the server aborts with an error\n# and refuses to start. When the option is set
    to no, the user requires\n# to fix the AOF file using the \"redis-check-aof\"
    utility before to restart\n# the server.\n#\n# Note that if the AOF file will
    be found to be corrupted in the middle\n# the server will still exit with an error.
    This option only applies when\n# Redis will try to read more data from the AOF
    file but not enough bytes\n# will be found.\naof-load-truncated yes\n\n# When
    rewriting the AOF file, Redis is able to use an RDB preamble in the\n# AOF file
    for faster rewrites and recoveries. When this option is turned\n# on the rewritten
    AOF file is composed of two different stanzas:\n#\n#   [RDB file][AOF tail]\n#\n#
    When loading Redis recognizes that the AOF file starts with the \"REDIS\"\n# string
    and loads the prefixed RDB file, and continues loading the AOF\n# tail.\naof-use-rdb-preamble
    yes\n\n################################ LUA SCRIPTING  ###############################\n\n#
    Max execution time of a Lua script in milliseconds.\n#\n# If the maximum execution
    time is reached Redis will log that a script is\n# still in execution after the
    maximum allowed time and will start to\n# reply to queries with an error.\n#\n#
    When a long running script exceeds the maximum execution time only the\n# SCRIPT
    KILL and SHUTDOWN NOSAVE commands are available. The first can be\n# used to stop
    a script that did not yet called write commands. The second\n# is the only way
    to shut down the server in the case a write command was\n# already issued by the
    script but the user doesn't want to wait for the natural\n# termination of the
    script.\n#\n# Set it to 0 or a negative value for unlimited execution without
    warnings.\nlua-time-limit 5000\n\n################################ REDIS CLUSTER
    \ ###############################\n\n# Normal Redis instances can't be part of
    a Redis Cluster; only nodes that are\n# started as cluster nodes can. In order
    to start a Redis instance as a\n# cluster node enable the cluster support uncommenting
    the following:\n#\n# cluster-enabled yes\n\n# Every cluster node has a cluster
    configuration file. This file is not\n# intended to be edited by hand. It is created
    and updated by Redis nodes.\n# Every Redis Cluster node requires a different cluster
    configuration file.\n# Make sure that instances running in the same system do
    not have\n# overlapping cluster configuration file names.\n#\n# cluster-config-file
    nodes-6379.conf\n\n# Cluster node timeout is the amount of milliseconds a node
    must be unreachable\n# for it to be considered in failure state.\n# Most other
    internal time limits are multiple of the node timeout.\n#\n# cluster-node-timeout
    15000\n\n# A replica of a failing master will avoid to start a failover if its
    data\n# looks too old.\n#\n# There is no simple way for a replica to actually
    have an exact measure of\n# its \"data age\", so the following two checks are
    performed:\n#\n# 1) If there are multiple replicas able to failover, they exchange
    messages\n#    in order to try to give an advantage to the replica with the best\n#
    \   replication offset (more data from the master processed).\n#    Replicas will
    try to get their rank by offset, and apply to the start\n#    of the failover
    a delay proportional to their rank.\n#\n# 2) Every single replica computes the
    time of the last interaction with\n#    its master. This can be the last ping
    or command received (if the master\n#    is still in the \"connected\" state),
    or the time that elapsed since the\n#    disconnection with the master (if the
    replication link is currently down).\n#    If the last interaction is too old,
    the replica will not try to failover\n#    at all.\n#\n# The point \"2\" can be
    tuned by user. Specifically a replica will not perform\n# the failover if, since
    the last interaction with the master, the time\n# elapsed is greater than:\n#\n#
    \  (node-timeout * replica-validity-factor) + repl-ping-replica-period\n#\n# So
    for example if node-timeout is 30 seconds, and the replica-validity-factor\n#
    is 10, and assuming a default repl-ping-replica-period of 10 seconds, the\n# replica
    will not try to failover if it was not able to talk with the master\n# for longer
    than 310 seconds.\n#\n# A large replica-validity-factor may allow replicas with
    too old data to failover\n# a master, while a too small value may prevent the
    cluster from being able to\n# elect a replica at all.\n#\n# For maximum availability,
    it is possible to set the replica-validity-factor\n# to a value of 0, which means,
    that replicas will always try to failover the\n# master regardless of the last
    time they interacted with the master.\n# (However they'll always try to apply
    a delay proportional to their\n# offset rank).\n#\n# Zero is the only value able
    to guarantee that when all the partitions heal\n# the cluster will always be able
    to continue.\n#\n# cluster-replica-validity-factor 10\n\n# Cluster replicas are
    able to migrate to orphaned masters, that are masters\n# that are left without
    working replicas. This improves the cluster ability\n# to resist to failures as
    otherwise an orphaned master can't be failed over\n# in case of failure if it
    has no working replicas.\n#\n# Replicas migrate to orphaned masters only if there
    are still at least a\n# given number of other working replicas for their old master.
    This number\n# is the \"migration barrier\". A migration barrier of 1 means that
    a replica\n# will migrate only if there is at least 1 other working replica for
    its master\n# and so forth. It usually reflects the number of replicas you want
    for every\n# master in your cluster.\n#\n# Default is 1 (replicas migrate only
    if their masters remain with at least\n# one replica). To disable migration just
    set it to a very large value.\n# A value of 0 can be set but is useful only for
    debugging and dangerous\n# in production.\n#\n# cluster-migration-barrier 1\n\n#
    By default Redis Cluster nodes stop accepting queries if they detect there\n#
    is at least an hash slot uncovered (no available node is serving it).\n# This
    way if the cluster is partially down (for example a range of hash slots\n# are
    no longer covered) all the cluster becomes, eventually, unavailable.\n# It automatically
    returns available as soon as all the slots are covered again.\n#\n# However sometimes
    you want the subset of the cluster which is working,\n# to continue to accept
    queries for the part of the key space that is still\n# covered. In order to do
    so, just set the cluster-require-full-coverage\n# option to no.\n#\n# cluster-require-full-coverage
    yes\n\n# This option, when set to yes, prevents replicas from trying to failover
    its\n# master during master failures. However the master can still perform a\n#
    manual failover, if forced to do so.\n#\n# This is useful in different scenarios,
    especially in the case of multiple\n# data center operations, where we want one
    side to never be promoted if not\n# in the case of a total DC failure.\n#\n# cluster-replica-no-failover
    no\n\n# This option, when set to yes, allows nodes to serve read traffic while
    the\n# the cluster is in a down state, as long as it believes it owns the slots.
    \n#\n# This is useful for two cases.  The first case is for when an application
    \n# doesn't require consistency of data during node failures or network partitions.\n#
    One example of this is a cache, where as long as the node has the data it\n# should
    be able to serve it. \n#\n# The second use case is for configurations that don't
    meet the recommended  \n# three shards but want to enable cluster mode and scale
    later. A \n# master outage in a 1 or 2 shard configuration causes a read/write
    outage to the\n# entire cluster without this option set, with it set there is
    only a write outage.\n# Without a quorum of masters, slot ownership will not change
    automatically. \n#\n# cluster-allow-reads-when-down no\n\n# In order to setup
    your cluster make sure to read the documentation\n# available at http://redis.io
    web site.\n\n########################## CLUSTER DOCKER/NAT support  ########################\n\n#
    In certain deployments, Redis Cluster nodes address discovery fails, because\n#
    addresses are NAT-ted or because ports are forwarded (the typical case is\n# Docker
    and other containers).\n#\n# In order to make Redis Cluster working in such environments,
    a static\n# configuration where each node knows its public address is needed.
    The\n# following two options are used for this scope, and are:\n#\n# * cluster-announce-ip\n#
    * cluster-announce-port\n# * cluster-announce-bus-port\n#\n# Each instruct the
    node about its address, client port, and cluster message\n# bus port. The information
    is then published in the header of the bus packets\n# so that other nodes will
    be able to correctly map the address of the node\n# publishing the information.\n#\n#
    If the above options are not used, the normal Redis Cluster auto-detection\n#
    will be used instead.\n#\n# Note that when remapped, the bus port may not be at
    the fixed offset of\n# clients port + 10000, so you can specify any port and bus-port
    depending\n# on how they get remapped. If the bus-port is not set, a fixed offset
    of\n# 10000 will be used as usually.\n#\n# Example:\n#\n# cluster-announce-ip
    10.1.1.5\n# cluster-announce-port 6379\n# cluster-announce-bus-port 6380\n\n##################################
    SLOW LOG ###################################\n\n# The Redis Slow Log is a system
    to log queries that exceeded a specified\n# execution time. The execution time
    does not include the I/O operations\n# like talking with the client, sending the
    reply and so forth,\n# but just the time needed to actually execute the command
    (this is the only\n# stage of command execution where the thread is blocked and
    can not serve\n# other requests in the meantime).\n#\n# You can configure the
    slow log with two parameters: one tells Redis\n# what is the execution time, in
    microseconds, to exceed in order for the\n# command to get logged, and the other
    parameter is the length of the\n# slow log. When a new command is logged the oldest
    one is removed from the\n# queue of logged commands.\n\n# The following time is
    expressed in microseconds, so 1000000 is equivalent\n# to one second. Note that
    a negative number disables the slow log, while\n# a value of zero forces the logging
    of every command.\nslowlog-log-slower-than 10000\n\n# There is no limit to this
    length. Just be aware that it will consume memory.\n# You can reclaim memory used
    by the slow log with SLOWLOG RESET.\nslowlog-max-len 128\n\n################################
    LATENCY MONITOR ##############################\n\n# The Redis latency monitoring
    subsystem samples different operations\n# at runtime in order to collect data
    related to possible sources of\n# latency of a Redis instance.\n#\n# Via the LATENCY
    command this information is available to the user that can\n# print graphs and
    obtain reports.\n#\n# The system only logs operations that were performed in a
    time equal or\n# greater than the amount of milliseconds specified via the\n#
    latency-monitor-threshold configuration directive. When its value is set\n# to
    zero, the latency monitor is turned off.\n#\n# By default latency monitoring is
    disabled since it is mostly not needed\n# if you don't have latency issues, and
    collecting data has a performance\n# impact, that while very small, can be measured
    under big load. Latency\n# monitoring can easily be enabled at runtime using the
    command\n# \"CONFIG SET latency-monitor-threshold <milliseconds>\" if needed.\nlatency-monitor-threshold
    0\n\n############################# EVENT NOTIFICATION ##############################\n\n#
    Redis can notify Pub/Sub clients about events happening in the key space.\n# This
    feature is documented at http://redis.io/topics/notifications\n#\n# For instance
    if keyspace events notification is enabled, and a client\n# performs a DEL operation
    on key \"foo\" stored in the Database 0, two\n# messages will be published via
    Pub/Sub:\n#\n# PUBLISH __keyspace@0__:foo del\n# PUBLISH __keyevent@0__:del foo\n#\n#
    It is possible to select the events that Redis will notify among a set\n# of classes.
    Every class is identified by a single character:\n#\n#  K     Keyspace events,
    published with __keyspace@<db>__ prefix.\n#  E     Keyevent events, published
    with __keyevent@<db>__ prefix.\n#  g     Generic commands (non-type specific)
    like DEL, EXPIRE, RENAME, ...\n#  $     String commands\n#  l     List commands\n#
    \ s     Set commands\n#  h     Hash commands\n#  z     Sorted set commands\n#
    \ x     Expired events (events generated every time a key expires)\n#  e     Evicted
    events (events generated when a key is evicted for maxmemory)\n#  t     Stream
    commands\n#  m     Key-miss events (Note: It is not included in the 'A' class)\n#
    \ A     Alias for g$lshzxet, so that the \"AKE\" string means all the events\n#
    \       (Except key-miss events which are excluded from 'A' due to their\n#         unique
    nature).\n#\n#  The \"notify-keyspace-events\" takes as argument a string that
    is composed\n#  of zero or multiple characters. The empty string means that notifications\n#
    \ are disabled.\n#\n#  Example: to enable list and generic events, from the point
    of view of the\n#           event name, use:\n#\n#  notify-keyspace-events Elg\n#\n#
    \ Example 2: to get the stream of the expired keys subscribing to channel\n#             name
    __keyevent@0__:expired use:\n#\n#  notify-keyspace-events Ex\n#\n#  By default
    all notifications are disabled because most users don't need\n#  this feature
    and the feature has some overhead. Note that if you don't\n#  specify at least
    one of K or E, no events will be delivered.\nnotify-keyspace-events \"\"\n\n###############################
    GOPHER SERVER #################################\n\n# Redis contains an implementation
    of the Gopher protocol, as specified in\n# the RFC 1436 (https://www.ietf.org/rfc/rfc1436.txt).\n#\n#
    The Gopher protocol was very popular in the late '90s. It is an alternative\n#
    to the web, and the implementation both server and client side is so simple\n#
    that the Redis server has just 100 lines of code in order to implement this\n#
    support.\n#\n# What do you do with Gopher nowadays? Well Gopher never *really*
    died, and\n# lately there is a movement in order for the Gopher more hierarchical
    content\n# composed of just plain text documents to be resurrected. Some want
    a simpler\n# internet, others believe that the mainstream internet became too
    much\n# controlled, and it's cool to create an alternative space for people that\n#
    want a bit of fresh air.\n#\n# Anyway for the 10nth birthday of the Redis, we
    gave it the Gopher protocol\n# as a gift.\n#\n# --- HOW IT WORKS? ---\n#\n# The
    Redis Gopher support uses the inline protocol of Redis, and specifically\n# two
    kind of inline requests that were anyway illegal: an empty request\n# or any request
    that starts with \"/\" (there are no Redis commands starting\n# with such a slash).
    Normal RESP2/RESP3 requests are completely out of the\n# path of the Gopher protocol
    implementation and are served as usually as well.\n#\n# If you open a connection
    to Redis when Gopher is enabled and send it\n# a string like \"/foo\", if there
    is a key named \"/foo\" it is served via the\n# Gopher protocol.\n#\n# In order
    to create a real Gopher \"hole\" (the name of a Gopher site in Gopher\n# talking),
    you likely need a script like the following:\n#\n#   https://github.com/antirez/gopher2redis\n#\n#
    --- SECURITY WARNING ---\n#\n# If you plan to put Redis on the internet in a publicly
    accessible address\n# to server Gopher pages MAKE SURE TO SET A PASSWORD to the
    instance.\n# Once a password is set:\n#\n#   1. The Gopher server (when enabled,
    not by default) will still serve\n#      content via Gopher.\n#   2. However other
    commands cannot be called before the client will\n#      authenticate.\n#\n# So
    use the 'requirepass' option to protect your instance.\n#\n# To enable Gopher
    support uncomment the following line and set\n# the option from no (the default)
    to yes.\n#\n# gopher-enabled no\n\n############################### ADVANCED CONFIG
    ###############################\n\n# Hashes are encoded using a memory efficient
    data structure when they have a\n# small number of entries, and the biggest entry
    does not exceed a given\n# threshold. These thresholds can be configured using
    the following directives.\nhash-max-ziplist-entries 512\nhash-max-ziplist-value
    64\n\n# Lists are also encoded in a special way to save a lot of space.\n# The
    number of entries allowed per internal list node can be specified\n# as a fixed
    maximum size or a maximum number of elements.\n# For a fixed maximum size, use
    -5 through -1, meaning:\n# -5: max size: 64 Kb  <-- not recommended for normal
    workloads\n# -4: max size: 32 Kb  <-- not recommended\n# -3: max size: 16 Kb  <--
    probably not recommended\n# -2: max size: 8 Kb   <-- good\n# -1: max size: 4 Kb
    \  <-- good\n# Positive numbers mean store up to _exactly_ that number of elements\n#
    per list node.\n# The highest performing option is usually -2 (8 Kb size) or -1
    (4 Kb size),\n# but if your use case is unique, adjust the settings as necessary.\nlist-max-ziplist-size
    -2\n\n# Lists may also be compressed.\n# Compress depth is the number of quicklist
    ziplist nodes from *each* side of\n# the list to *exclude* from compression.  The
    head and tail of the list\n# are always uncompressed for fast push/pop operations.
    \ Settings are:\n# 0: disable all list compression\n# 1: depth 1 means \"don't
    start compressing until after 1 node into the list,\n#    going from either the
    head or tail\"\n#    So: [head]->node->node->...->node->[tail]\n#    [head], [tail]
    will always be uncompressed; inner nodes will compress.\n# 2: [head]->[next]->node->node->...->node->[prev]->[tail]\n#
    \   2 here means: don't compress head or head->next or tail->prev or tail,\n#
    \   but compress all nodes between them.\n# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]\n#
    etc.\nlist-compress-depth 0\n\n# Sets have a special encoding in just one case:
    when a set is composed\n# of just strings that happen to be integers in radix
    10 in the range\n# of 64 bit signed integers.\n# The following configuration setting
    sets the limit in the size of the\n# set in order to use this special memory saving
    encoding.\nset-max-intset-entries 512\n\n# Similarly to hashes and lists, sorted
    sets are also specially encoded in\n# order to save a lot of space. This encoding
    is only used when the length and\n# elements of a sorted set are below the following
    limits:\nzset-max-ziplist-entries 128\nzset-max-ziplist-value 64\n\n# HyperLogLog
    sparse representation bytes limit. The limit includes the\n# 16 bytes header.
    When an HyperLogLog using the sparse representation crosses\n# this limit, it
    is converted into the dense representation.\n#\n# A value greater than 16000 is
    totally useless, since at that point the\n# dense representation is more memory
    efficient.\n#\n# The suggested value is ~ 3000 in order to have the benefits of\n#
    the space efficient encoding without slowing down too much PFADD,\n# which is
    O(N) with the sparse encoding. The value can be raised to\n# ~ 10000 when CPU
    is not a concern, but space is, and the data set is\n# composed of many HyperLogLogs
    with cardinality in the 0 - 15000 range.\nhll-sparse-max-bytes 3000\n\n# Streams
    macro node max size / items. The stream data structure is a radix\n# tree of big
    nodes that encode multiple items inside. Using this configuration\n# it is possible
    to configure how big a single node can be in bytes, and the\n# maximum number
    of items it may contain before switching to a new node when\n# appending new stream
    entries. If any of the following settings are set to\n# zero, the limit is ignored,
    so for instance it is possible to set just a\n# max entires limit by setting max-bytes
    to 0 and max-entries to the desired\n# value.\nstream-node-max-bytes 4096\nstream-node-max-entries
    100\n\n# Active rehashing uses 1 millisecond every 100 milliseconds of CPU time
    in\n# order to help rehashing the main Redis hash table (the one mapping top-level\n#
    keys to values). The hash table implementation Redis uses (see dict.c)\n# performs
    a lazy rehashing: the more operation you run into a hash table\n# that is rehashing,
    the more rehashing \"steps\" are performed, so if the\n# server is idle the rehashing
    is never complete and some more memory is used\n# by the hash table.\n#\n# The
    default is to use this millisecond 10 times every second in order to\n# actively
    rehash the main dictionaries, freeing memory when possible.\n#\n# If unsure:\n#
    use \"activerehashing no\" if you have hard latency requirements and it is\n#
    not a good thing in your environment that Redis can reply from time to time\n#
    to queries with 2 milliseconds delay.\n#\n# use \"activerehashing yes\" if you
    don't have such hard requirements but\n# want to free memory asap when possible.\nactiverehashing
    yes\n\n# The client output buffer limits can be used to force disconnection of
    clients\n# that are not reading data from the server fast enough for some reason
    (a\n# common reason is that a Pub/Sub client can't consume messages as fast as
    the\n# publisher can produce them).\n#\n# The limit can be set differently for
    the three different classes of clients:\n#\n# normal -> normal clients including
    MONITOR clients\n# replica  -> replica clients\n# pubsub -> clients subscribed
    to at least one pubsub channel or pattern\n#\n# The syntax of every client-output-buffer-limit
    directive is the following:\n#\n# client-output-buffer-limit <class> <hard limit>
    <soft limit> <soft seconds>\n#\n# A client is immediately disconnected once the
    hard limit is reached, or if\n# the soft limit is reached and remains reached
    for the specified number of\n# seconds (continuously).\n# So for instance if the
    hard limit is 32 megabytes and the soft limit is\n# 16 megabytes / 10 seconds,
    the client will get disconnected immediately\n# if the size of the output buffers
    reach 32 megabytes, but will also get\n# disconnected if the client reaches 16
    megabytes and continuously overcomes\n# the limit for 10 seconds.\n#\n# By default
    normal clients are not limited because they don't receive data\n# without asking
    (in a push way), but just after a request, so only\n# asynchronous clients may
    create a scenario where data is requested faster\n# than it can read.\n#\n# Instead
    there is a default limit for pubsub and replica clients, since\n# subscribers
    and replicas receive data in a push fashion.\n#\n# Both the hard or the soft limit
    can be disabled by setting them to zero.\nclient-output-buffer-limit normal 0
    0 0\nclient-output-buffer-limit replica 256mb 64mb 60\nclient-output-buffer-limit
    pubsub 32mb 8mb 60\n\n# Client query buffers accumulate new commands. They are
    limited to a fixed\n# amount by default in order to avoid that a protocol desynchronization
    (for\n# instance due to a bug in the client) will lead to unbound memory usage
    in\n# the query buffer. However you can configure it here if you have very special\n#
    needs, such us huge multi/exec requests or alike.\n#\n# client-query-buffer-limit
    1gb\n\n# In the Redis protocol, bulk requests, that are, elements representing
    single\n# strings, are normally limited ot 512 mb. However you can change this
    limit\n# here.\n#\n# proto-max-bulk-len 512mb\n\n# Redis calls an internal function
    to perform many background tasks, like\n# closing connections of clients in timeout,
    purging expired keys that are\n# never requested, and so forth.\n#\n# Not all
    tasks are performed with the same frequency, but Redis checks for\n# tasks to
    perform according to the specified \"hz\" value.\n#\n# By default \"hz\" is set
    to 10. Raising the value will use more CPU when\n# Redis is idle, but at the same
    time will make Redis more responsive when\n# there are many keys expiring at the
    same time, and timeouts may be\n# handled with more precision.\n#\n# The range
    is between 1 and 500, however a value over 100 is usually not\n# a good idea.
    Most users should use the default of 10 and raise this up to\n# 100 only in environments
    where very low latency is required.\nhz 10\n\n# Normally it is useful to have
    an HZ value which is proportional to the\n# number of clients connected. This
    is useful in order, for instance, to\n# avoid too many clients are processed for
    each background task invocation\n# in order to avoid latency spikes.\n#\n# Since
    the default HZ value by default is conservatively set to 10, Redis\n# offers,
    and enables by default, the ability to use an adaptive HZ value\n# which will
    temporary raise when there are many connected clients.\n#\n# When dynamic HZ is
    enabled, the actual configured HZ will be used\n# as a baseline, but multiples
    of the configured HZ value will be actually\n# used as needed once more clients
    are connected. In this way an idle\n# instance will use very little CPU time while
    a busy instance will be\n# more responsive.\ndynamic-hz yes\n\n# When a child
    rewrites the AOF file, if the following option is enabled\n# the file will be
    fsync-ed every 32 MB of data generated. This is useful\n# in order to commit the
    file to the disk more incrementally and avoid\n# big latency spikes.\naof-rewrite-incremental-fsync
    yes\n\n# When redis saves RDB file, if the following option is enabled\n# the
    file will be fsync-ed every 32 MB of data generated. This is useful\n# in order
    to commit the file to the disk more incrementally and avoid\n# big latency spikes.\nrdb-save-incremental-fsync
    yes\n\n# Redis LFU eviction (see maxmemory setting) can be tuned. However it is
    a good\n# idea to start with the default settings and only change them after investigating\n#
    how to improve the performances and how the keys LFU change over time, which\n#
    is possible to inspect via the OBJECT FREQ command.\n#\n# There are two tunable
    parameters in the Redis LFU implementation: the\n# counter logarithm factor and
    the counter decay time. It is important to\n# understand what the two parameters
    mean before changing them.\n#\n# The LFU counter is just 8 bits per key, it's
    maximum value is 255, so Redis\n# uses a probabilistic increment with logarithmic
    behavior. Given the value\n# of the old counter, when a key is accessed, the counter
    is incremented in\n# this way:\n#\n# 1. A random number R between 0 and 1 is extracted.\n#
    2. A probability P is calculated as 1/(old_value*lfu_log_factor+1).\n# 3. The
    counter is incremented only if R < P.\n#\n# The default lfu-log-factor is 10.
    This is a table of how the frequency\n# counter changes with a different number
    of accesses with different\n# logarithmic factors:\n#\n# +--------+------------+------------+------------+------------+------------+\n#
    | factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |\n#
    +--------+------------+------------+------------+------------+------------+\n#
    | 0      | 104        | 255        | 255        | 255        | 255        |\n#
    +--------+------------+------------+------------+------------+------------+\n#
    | 1      | 18         | 49         | 255        | 255        | 255        |\n#
    +--------+------------+------------+------------+------------+------------+\n#
    | 10     | 10         | 18         | 142        | 255        | 255        |\n#
    +--------+------------+------------+------------+------------+------------+\n#
    | 100    | 8          | 11         | 49         | 143        | 255        |\n#
    +--------+------------+------------+------------+------------+------------+\n#\n#
    NOTE: The above table was obtained by running the following commands:\n#\n#   redis-benchmark
    -n 1000000 incr foo\n#   redis-cli object freq foo\n#\n# NOTE 2: The counter initial
    value is 5 in order to give new objects a chance\n# to accumulate hits.\n#\n#
    The counter decay time is the time, in minutes, that must elapse in order\n# for
    the key counter to be divided by two (or decremented if it has a value\n# less
    <= 10).\n#\n# The default value for the lfu-decay-time is 1. A Special value of
    0 means to\n# decay the counter every time it happens to be scanned.\n#\n# lfu-log-factor
    10\n# lfu-decay-time 1\n\n########################### ACTIVE DEFRAGMENTATION #######################\n#\n#
    What is active defragmentation?\n# -------------------------------\n#\n# Active
    (online) defragmentation allows a Redis server to compact the\n# spaces left between
    small allocations and deallocations of data in memory,\n# thus allowing to reclaim
    back memory.\n#\n# Fragmentation is a natural process that happens with every
    allocator (but\n# less so with Jemalloc, fortunately) and certain workloads. Normally
    a server\n# restart is needed in order to lower the fragmentation, or at least
    to flush\n# away all the data and create it again. However thanks to this feature\n#
    implemented by Oran Agra for Redis 4.0 this process can happen at runtime\n# in
    an \"hot\" way, while the server is running.\n#\n# Basically when the fragmentation
    is over a certain level (see the\n# configuration options below) Redis will start
    to create new copies of the\n# values in contiguous memory regions by exploiting
    certain specific Jemalloc\n# features (in order to understand if an allocation
    is causing fragmentation\n# and to allocate it in a better place), and at the
    same time, will release the\n# old copies of the data. This process, repeated
    incrementally for all the keys\n# will cause the fragmentation to drop back to
    normal values.\n#\n# Important things to understand:\n#\n# 1. This feature is
    disabled by default, and only works if you compiled Redis\n#    to use the copy
    of Jemalloc we ship with the source code of Redis.\n#    This is the default with
    Linux builds.\n#\n# 2. You never need to enable this feature if you don't have
    fragmentation\n#    issues.\n#\n# 3. Once you experience fragmentation, you can
    enable this feature when\n#    needed with the command \"CONFIG SET activedefrag
    yes\".\n#\n# The configuration parameters are able to fine tune the behavior of
    the\n# defragmentation process. If you are not sure about what they mean it is\n#
    a good idea to leave the defaults untouched.\n\n# Enabled active defragmentation\n#
    activedefrag no\n\n# Minimum amount of fragmentation waste to start active defrag\n#
    active-defrag-ignore-bytes 100mb\n\n# Minimum percentage of fragmentation to start
    active defrag\n# active-defrag-threshold-lower 10\n\n# Maximum percentage of fragmentation
    at which we use maximum effort\n# active-defrag-threshold-upper 100\n\n# Minimal
    effort for defrag in CPU percentage, to be used when the lower\n# threshold is
    reached\n# active-defrag-cycle-min 1\n\n# Maximal effort for defrag in CPU percentage,
    to be used when the upper\n# threshold is reached\n# active-defrag-cycle-max 25\n\n#
    Maximum number of set/hash/zset/list fields that will be processed from\n# the
    main dictionary scan\n# active-defrag-max-scan-fields 1000\n\n# Jemalloc background
    thread for purging will be enabled by default\njemalloc-bg-thread yes\n\n# It
    is possible to pin different threads and processes of Redis to specific\n# CPUs
    in your system, in order to maximize the performances of the server.\n# This is
    useful both in order to pin different Redis threads in different\n# CPUs, but
    also in order to make sure that multiple Redis instances running\n# in the same
    host will be pinned to different CPUs.\n#\n# Normally you can do this using the
    \"taskset\" command, however it is also\n# possible to this via Redis configuration
    directly, both in Linux and FreeBSD.\n#\n# You can pin the server/IO threads,
    bio threads, aof rewrite child process, and\n# the bgsave child process. The syntax
    to specify the cpu list is the same as\n# the taskset command:\n#\n# Set redis
    server/io threads to cpu affinity 0,2,4,6:\n# server_cpulist 0-7:2\n#\n# Set bio
    threads to cpu affinity 1,3:\n# bio_cpulist 1,3\n#\n# Set aof rewrite child process
    to cpu affinity 8,9,10,11:\n# aof_rewrite_cpulist 8-11\n#\n# Set bgsave child
    process to cpu affinity 1,10,11\n# bgsave_cpulist 1,10-11\n"
  users.acl: |
    user redisUser on  +@all ~* >TestDB@home2
kind: ConfigMap
metadata:
  name: redis-config-configmap
