apiVersion: apps/v1 kind: Deployment metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app: gitea app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: gitea app.kubernetes.io/version: 1.25.5 helm.sh/chart: gitea-12.5.3 version: 1.25.5 name: gitea namespace: infrastructure spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: app.kubernetes.io/instance: gitea app.kubernetes.io/name: gitea strategy: rollingUpdate: maxSurge: 100% maxUnavailable: 0 type: RollingUpdate template: metadata: annotations: checksum/config: 2a57e6a1fd8bad6c1a2e2bcb199d18655e12c8ec50b9d07879d540b59ff539be labels: app: gitea app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: gitea app.kubernetes.io/version: 1.25.5 helm.sh/chart: gitea-12.5.3 version: 1.25.5 spec: containers: - env: - name: SSH_LISTEN_PORT value: '2222' - name: SSH_PORT value: '22' - name: GITEA_APP_INI value: /data/gitea/conf/app.ini - name: GITEA_CUSTOM value: /data/gitea - name: GITEA_WORK_DIR value: /data - name: GITEA_TEMP value: /tmp/gitea - name: TMPDIR value: /tmp/gitea - name: HOME value: /data/gitea/git image: docker.gitea.com/gitea:1.25.5-rootless imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 10 initialDelaySeconds: 200 periodSeconds: 10 successThreshold: 1 tcpSocket: port: http timeoutSeconds: 1 name: gitea ports: - containerPort: 2222 name: ssh protocol: TCP - containerPort: 3000 name: http protocol: TCP readinessProbe: failureThreshold: 3 initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 tcpSocket: port: http timeoutSeconds: 1 resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /tmp name: temp - mountPath: /data name: data dnsPolicy: ClusterFirst initContainers: - command: - /usr/sbinx/init_directory_structure.sh env: - name: GITEA_APP_INI value: /data/gitea/conf/app.ini - name: GITEA_CUSTOM value: /data/gitea - name: GITEA_WORK_DIR value: /data - name: GITEA_TEMP value: /tmp/gitea image: docker.gitea.com/gitea:1.25.5-rootless imagePullPolicy: IfNotPresent name: init-directories resources: requests: cpu: 100m memory: 128Mi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /usr/sbinx name: init - mountPath: /tmp name: temp - mountPath: /data name: data - command: - /usr/sbinx/config_environment.sh env: - name: GITEA_APP_INI value: /data/gitea/conf/app.ini - name: GITEA_CUSTOM value: /data/gitea - name: GITEA_WORK_DIR value: /data - name: GITEA_TEMP value: /tmp/gitea - name: TMP_EXISTING_ENVS_FILE value: /tmp/existing-envs - name: ENV_TO_INI_MOUNT_POINT value: /env-to-ini-mounts image: docker.gitea.com/gitea:1.25.5-rootless imagePullPolicy: IfNotPresent name: init-app-ini resources: requests: cpu: 100m memory: 128Mi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /usr/sbinx name: config - mountPath: /tmp name: temp - mountPath: /data name: data - mountPath: /env-to-ini-mounts/inlines/ name: inline-config-sources - command: - /usr/sbinx/configure_gitea.sh env: - name: GITEA_APP_INI value: /data/gitea/conf/app.ini - name: GITEA_CUSTOM value: /data/gitea - name: GITEA_WORK_DIR value: /data - name: GITEA_TEMP value: /tmp/gitea - name: HOME value: /data/gitea/git - name: GITEA_ADMIN_USERNAME value: Snarf - name: GITEA_ADMIN_PASSWORD value: Katzir476! - name: GITEA_ADMIN_PASSWORD_MODE value: keepUpdated image: docker.gitea.com/gitea:1.25.5-rootless imagePullPolicy: IfNotPresent name: configure-gitea resources: requests: cpu: 100m memory: 128Mi securityContext: runAsUser: 1000 terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /usr/sbinx name: init - mountPath: /tmp name: temp - mountPath: /data name: data restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 1000 terminationGracePeriodSeconds: 60 volumes: - name: init secret: defaultMode: 110 secretName: gitea-init - name: config secret: defaultMode: 110 secretName: gitea - name: inline-config-sources secret: defaultMode: 420 secretName: gitea-inline-config - emptyDir: {} name: temp - name: data persistentVolumeClaim: claimName: gitea-shared-storage --- apiVersion: apps/v1 kind: StatefulSet metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: postgresql app.kubernetes.io/version: 17.6.0 helm.sh/chart: postgresql-16.7.27 name: gitea-postgresql namespace: infrastructure spec: persistentVolumeClaimRetentionPolicy: whenDeleted: Retain whenScaled: Retain podManagementPolicy: OrderedReady replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/name: postgresql serviceName: gitea-postgresql-hl template: metadata: labels: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: postgresql app.kubernetes.io/version: 17.6.0 helm.sh/chart: postgresql-16.7.27 name: gitea-postgresql spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/name: postgresql topologyKey: kubernetes.io/hostname weight: 1 automountServiceAccountToken: false containers: - env: - name: BITNAMI_DEBUG value: 'false' - name: POSTGRESQL_PORT_NUMBER value: '5432' - name: POSTGRESQL_VOLUME_DIR value: /bitnami/postgresql - name: PGDATA value: /bitnami/postgresql/data - name: POSTGRES_USER value: ugandanese - name: POSTGRES_PASSWORD_FILE value: /opt/bitnami/postgresql/secrets/password - name: POSTGRES_POSTGRES_PASSWORD_FILE value: /opt/bitnami/postgresql/secrets/postgres-password - name: POSTGRES_DATABASE value: baptiste - name: POSTGRESQL_ENABLE_LDAP value: 'no' - name: POSTGRESQL_ENABLE_TLS value: 'no' - name: POSTGRESQL_LOG_HOSTNAME value: 'false' - name: POSTGRESQL_LOG_CONNECTIONS value: 'false' - name: POSTGRESQL_LOG_DISCONNECTIONS value: 'false' - name: POSTGRESQL_PGAUDIT_LOG_CATALOG value: 'off' - name: POSTGRESQL_CLIENT_MIN_MESSAGES value: error - name: POSTGRESQL_SHARED_PRELOAD_LIBRARIES value: pgaudit image: docker.io/bitnamilegacy/postgresql:17.6.0-debian-12-r4 imagePullPolicy: IfNotPresent livenessProbe: exec: command: - /bin/sh - -c - exec pg_isready -U "ugandanese" -d "dbname=baptiste" -h 127.0.0.1 -p 5432 failureThreshold: 6 initialDelaySeconds: 30 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 name: postgresql ports: - containerPort: 5432 name: tcp-postgresql protocol: TCP readinessProbe: exec: command: - /bin/sh - -c - -e - 'exec pg_isready -U "ugandanese" -d "dbname=baptiste" -h 127.0.0.1 -p 5432 [ -f /opt/bitnami/postgresql/tmp/.initialized ] || [ -f /bitnami/postgresql/.initialized ] ' failureThreshold: 6 initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 resources: limits: cpu: 150m ephemeral-storage: 2Gi memory: 192Mi requests: cpu: 100m ephemeral-storage: 50Mi memory: 128Mi securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL privileged: false readOnlyRootFilesystem: true runAsGroup: 1001 runAsNonRoot: true runAsUser: 1001 seLinuxOptions: {} seccompProfile: type: RuntimeDefault terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /tmp name: empty-dir subPath: tmp-dir - mountPath: /opt/bitnami/postgresql/conf name: empty-dir subPath: app-conf-dir - mountPath: /opt/bitnami/postgresql/tmp name: empty-dir subPath: app-tmp-dir - mountPath: /opt/bitnami/postgresql/secrets/ name: postgresql-password - mountPath: /dev/shm name: dshm - mountPath: /bitnami/postgresql name: data dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 1001 fsGroupChangePolicy: Always serviceAccount: gitea-postgresql serviceAccountName: gitea-postgresql terminationGracePeriodSeconds: 30 volumes: - emptyDir: {} name: empty-dir - name: postgresql-password secret: defaultMode: 420 secretName: gitea-postgresql - emptyDir: medium: Memory name: dshm updateStrategy: rollingUpdate: partition: 0 type: RollingUpdate volumeClaimTemplates: - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi volumeMode: Filesystem status: phase: Pending --- apiVersion: apps/v1 kind: StatefulSet metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: valkey-cluster app.kubernetes.io/version: 8.1.3 helm.sh/chart: valkey-cluster-3.0.24 name: gitea-valkey-cluster namespace: infrastructure spec: persistentVolumeClaimRetentionPolicy: whenDeleted: Retain whenScaled: Retain podManagementPolicy: Parallel replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: app.kubernetes.io/instance: gitea app.kubernetes.io/name: valkey-cluster serviceName: gitea-valkey-cluster-headless template: metadata: annotations: checksum/config: 47dd59e42551617af06bea78ade075756f1de9d3c9efb4d4ee2a8dbcf4b7399b checksum/scripts: a01509d0b1d067cb6c60442ef6d318dfbacebadfb0105a676f4693dbe999e5c5 checksum/secret: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 labels: app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: valkey-cluster app.kubernetes.io/version: 8.1.3 helm.sh/chart: valkey-cluster-3.0.24 spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/instance: gitea app.kubernetes.io/name: valkey-cluster topologyKey: kubernetes.io/hostname weight: 1 automountServiceAccountToken: false containers: - args: - "# Backwards compatibility change\nif ! [[ -f /opt/bitnami/valkey/etc/valkey.conf\ \ ]]; then\n echo COPYING FILE\n cp /opt/bitnami/valkey/etc/valkey-default.conf\ \ /opt/bitnami/valkey/etc/valkey.conf\nfi\npod_index=($(echo \"$POD_NAME\"\ \ | tr \"-\" \"\\n\"))\npod_index=\"${pod_index[-1]}\"\nif [[ \"$pod_index\"\ \ == \"0\" ]]; then\n export VALKEY_CLUSTER_CREATOR=\"yes\"\n export VALKEY_CLUSTER_REPLICAS=\"\ 0\"\nfi\n/opt/bitnami/scripts/valkey-cluster/entrypoint.sh /opt/bitnami/scripts/valkey-cluster/run.sh\n" command: - /bin/bash - -c env: - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: VALKEY_NODES value: 'gitea-valkey-cluster-0.gitea-valkey-cluster-headless gitea-valkey-cluster-1.gitea-valkey-cluster-headless gitea-valkey-cluster-2.gitea-valkey-cluster-headless ' - name: ALLOW_EMPTY_PASSWORD value: 'yes' - name: VALKEY_AOF_ENABLED value: 'yes' - name: VALKEY_TLS_ENABLED value: 'no' - name: VALKEY_PORT_NUMBER value: '6379' image: docker.io/bitnamilegacy/valkey-cluster:8.1.3-debian-12-r3 imagePullPolicy: IfNotPresent livenessProbe: exec: command: - sh - -c - /scripts/ping_liveness_local.sh 5 failureThreshold: 5 initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 6 name: gitea-valkey-cluster ports: - containerPort: 6379 name: tcp-redis protocol: TCP - containerPort: 16379 name: tcp-redis-bus protocol: TCP readinessProbe: exec: command: - sh - -c - /scripts/ping_readiness_local.sh 1 failureThreshold: 5 initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 2 resources: limits: cpu: 150m ephemeral-storage: 2Gi memory: 192Mi requests: cpu: 100m ephemeral-storage: 50Mi memory: 128Mi securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL privileged: false readOnlyRootFilesystem: true runAsGroup: 1001 runAsNonRoot: true runAsUser: 1001 seLinuxOptions: {} seccompProfile: type: RuntimeDefault terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /scripts name: scripts - mountPath: /bitnami/valkey/data name: valkey-data - mountPath: /opt/bitnami/valkey/etc/valkey-default.conf name: default-config subPath: valkey-default.conf - mountPath: /opt/bitnami/valkey/etc/ name: empty-dir subPath: app-conf-dir - mountPath: /opt/bitnami/valkey/tmp name: empty-dir subPath: app-tmp-dir - mountPath: /opt/bitnami/valkey/logs name: empty-dir subPath: app-logs-dir - mountPath: /tmp name: empty-dir subPath: tmp-dir dnsPolicy: ClusterFirst enableServiceLinks: false restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 1001 fsGroupChangePolicy: Always serviceAccount: gitea-valkey-cluster serviceAccountName: gitea-valkey-cluster terminationGracePeriodSeconds: 30 volumes: - configMap: defaultMode: 493 name: gitea-valkey-cluster-scripts name: scripts - configMap: defaultMode: 420 name: gitea-valkey-cluster-default name: default-config - emptyDir: {} name: empty-dir updateStrategy: rollingUpdate: partition: 0 type: RollingUpdate volumeClaimTemplates: - apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app.kubernetes.io/instance: gitea app.kubernetes.io/name: valkey-cluster name: valkey-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 8Gi volumeMode: Filesystem status: phase: Pending --- apiVersion: v1 kind: Service metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app: gitea app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: gitea app.kubernetes.io/version: 1.25.5 helm.sh/chart: gitea-12.5.3 version: 1.25.5 name: gitea-http namespace: infrastructure spec: clusterIP: None clusterIPs: - None internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: http port: 3000 protocol: TCP targetPort: 3000 selector: app.kubernetes.io/instance: gitea app.kubernetes.io/name: gitea sessionAffinity: None type: ClusterIP --- apiVersion: v1 kind: Service metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: postgresql app.kubernetes.io/version: 17.6.0 helm.sh/chart: postgresql-16.7.27 name: gitea-postgresql namespace: infrastructure spec: clusterIP: 10.43.51.46 clusterIPs: - 10.43.51.46 internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: tcp-postgresql port: 5432 protocol: TCP targetPort: tcp-postgresql selector: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/name: postgresql sessionAffinity: None type: ClusterIP --- apiVersion: v1 kind: Service metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: postgresql app.kubernetes.io/version: 17.6.0 helm.sh/chart: postgresql-16.7.27 name: gitea-postgresql-hl namespace: infrastructure spec: clusterIP: None clusterIPs: - None internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: tcp-postgresql port: 5432 protocol: TCP targetPort: tcp-postgresql publishNotReadyAddresses: true selector: app.kubernetes.io/component: primary app.kubernetes.io/instance: gitea app.kubernetes.io/name: postgresql sessionAffinity: None type: ClusterIP --- apiVersion: v1 kind: Service metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app: gitea app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: gitea app.kubernetes.io/version: 1.25.5 helm.sh/chart: gitea-12.5.3 version: 1.25.5 name: gitea-ssh namespace: infrastructure spec: clusterIP: None clusterIPs: - None internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: ssh port: 22 protocol: TCP targetPort: 2222 selector: app.kubernetes.io/instance: gitea app.kubernetes.io/name: gitea sessionAffinity: None type: ClusterIP --- apiVersion: v1 kind: Service metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: valkey-cluster app.kubernetes.io/version: 8.1.3 helm.sh/chart: valkey-cluster-3.0.24 name: gitea-valkey-cluster namespace: infrastructure spec: clusterIP: 10.43.225.39 clusterIPs: - 10.43.225.39 internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: tcp-redis port: 6379 protocol: TCP targetPort: tcp-redis selector: app.kubernetes.io/instance: gitea app.kubernetes.io/name: valkey-cluster sessionAffinity: None type: ClusterIP --- apiVersion: v1 kind: Service metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: valkey-cluster app.kubernetes.io/version: 8.1.3 helm.sh/chart: valkey-cluster-3.0.24 name: gitea-valkey-cluster-headless namespace: infrastructure spec: clusterIP: None clusterIPs: - None internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: tcp-redis port: 6379 protocol: TCP targetPort: tcp-redis - name: tcp-redis-bus port: 16379 protocol: TCP targetPort: tcp-redis-bus publishNotReadyAddresses: true selector: app.kubernetes.io/instance: gitea app.kubernetes.io/name: valkey-cluster sessionAffinity: None type: ClusterIP --- apiVersion: v1 data: valkey-default.conf: "# Valkey configuration file example.\n#\n# Note that in order\ \ to read the configuration file, Valkey must be\n# started with the file path\ \ as first argument:\n#\n# ./valkey-server /path/to/valkey.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 Valkey 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# Note that option \"include\" won't be rewritten by command\ \ \"CONFIG REWRITE\"\n# from admin or Valkey Sentinel. Since Valkey 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\ # Included paths may contain wildcards. All files matching the wildcards will\n\ # be included in alphabetical order.\n# Note that if an include path contains\ \ a wildcards but no files match it when\n# the server is started, the include\ \ statement will be ignored and no error will\n# be emitted. It is safe, therefore,\ \ to include wildcard files from empty\n# directories.\n#\n# include /path/to/local.conf\n\ # include /path/to/other.conf\n# include /path/to/fragments/*.conf\n#\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, Valkey listens\n# for connections from all available\ \ network interfaces on the host machine.\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# Each address can be prefixed by \"\ -\", which means that valkey will not fail to\n# start if the address is not available.\ \ Being not available only refers to\n# addresses that does not correspond to\ \ any network interface. Addresses that\n# are already in use will always fail,\ \ and unsupported protocols will always BE\n# silently skipped.\n#\n# Examples:\n\ #\n# bind 192.168.1.100 10.0.0.1 # listens on two specific IPv4 addresses\n\ # bind 127.0.0.1 ::1 # listens on loopback IPv4 and IPv6\n# bind\ \ * -::* # like the default, all available interfaces\n#\n\ # ~~~ WARNING ~~~ If the computer running Valkey 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 Valkey to listen only on the\n# IPv4 and IPv6\ \ (if available) loopback interface addresses (this means Valkey\n# will only\ \ be able to accept client connections from the same host that it is\n# running\ \ on).\n#\n# IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES\n\ # COMMENT OUT THE FOLLOWING LINE.\n#\n# You will also need to set a password unless\ \ you explicitly disable protected\n# mode.\n# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\ bind 127.0.0.1 -::1\n\n# By default, outgoing connections (from replica to primary,\ \ from Sentinel to\n# instances, cluster bus, etc.) are not bound to a specific\ \ local address. In\n# most cases, this means the operating system will handle\ \ that based on routing\n# and the interface through which the connection goes\ \ out.\n#\n# Using bind-source-addr it is possible to configure a specific address\ \ to bind\n# to, which may also affect how the connection gets routed.\n#\n# Example:\n\ #\n# bind-source-addr 10.0.0.1\n\n# Protected mode is a layer of security protection,\ \ in order to avoid that\n# Valkey instances left open on the internet are accessed\ \ and exploited.\n#\n# When protected mode is on and the default user has no password,\ \ the server\n# only accepts local connections from the IPv4 address (127.0.0.1),\ \ IPv6 address\n# (::1) or Unix domain 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 Valkey\n# even if no authentication is configured.\n\ protected-mode yes\n\n# Valkey uses default hardened security configuration directives\ \ to reduce the\n# attack surface on innocent users. Therefore, several sensitive\ \ configuration\n# directives are immutable, and some potentially-dangerous commands\ \ are blocked.\n#\n# Configuration directives that control files that Valkey writes\ \ to (e.g., 'dir'\n# and 'dbfilename') and that aren't usually modified during\ \ runtime\n# are protected by making them immutable.\n#\n# Commands that can increase\ \ the attack surface of Valkey and that aren't usually\n# called by users are\ \ blocked by default.\n#\n# These can be exposed to either all connections or\ \ just local ones by setting\n# each of the configs listed below to either of\ \ these values:\n#\n# no - Block for any connection (remain immutable)\n# yes\ \ - Allow for any connection (no protection)\n# local - Allow only for local\ \ connections. Ones originating from the\n# IPv4 address (127.0.0.1),\ \ IPv6 address (::1) or Unix domain sockets.\n#\n# enable-protected-configs no\n\ # enable-debug-command no\n# enable-module-command no\n\n# Accept connections\ \ on the specified port, default is 6379 (IANA #815344).\n# If port 0 is specified\ \ Valkey will not listen on a TCP socket.\nport 6379\n\n# TCP listen() backlog.\n\ #\n# In high requests-per-second environments you need a high backlog in order\n\ # to avoid slow clients connection 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 Valkey will not listen\n# on a unix socket when not\ \ specified.\n#\n# unixsocket /run/valkey.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) Force network equipment in the middle to consider\ \ the connection to be\n# alive.\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\ntcp-keepalive\ \ 300\n\n# Apply OS-specific mechanism to mark the listening socket with the specified\n\ # ID, to support advanced routing and filtering capabilities.\n#\n# On Linux,\ \ the ID represents a connection mark.\n# On FreeBSD, the ID represents a socket\ \ cookie ID.\n# On OpenBSD, the ID represents a route table ID.\n#\n# The default\ \ value is 0, which implies no marking is required.\n# socket-mark-id 0\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, primarys or cluster peers.\ \ These files should be\n# PEM formatted.\n#\n# tls-cert-file valkey.crt\n# tls-key-file\ \ valkey.key\n#\n# If the key file is encrypted using a passphrase, it can be\ \ included here\n# as well.\n#\n# tls-key-file-pass secret\n\n# Normally Valkey\ \ uses the same certificate for both server functions (accepting\n# connections)\ \ and client functions (replicating from a primary, establishing\n# cluster bus\ \ connections, etc.).\n#\n# Sometimes certificates are issued with attributes\ \ that designate them as\n# client-only or server-only certificates. In that case\ \ it may be desired to use\n# different certificates for incoming (server) and\ \ outgoing (client)\n# connections. To do that, use the following directives:\n\ #\n# tls-client-cert-file client.crt\n# tls-client-key-file client.key\n#\n# If\ \ the key file is encrypted using a passphrase, it can be included here\n# as\ \ well.\n#\n# tls-client-key-file-pass secret\n\n# Configure a DH parameters file\ \ to enable Diffie-Hellman (DH) key exchange,\n# required by older versions of\ \ OpenSSL (<3.0). Newer versions do not require\n# this configuration and recommend\ \ against it.\n#\n# tls-dh-params-file valkey.dh\n\n# Configure a CA certificate(s)\ \ bundle or directory to authenticate TLS/SSL\n# clients and peers. Valkey 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# If \"no\" is specified, client certificates are not required and not accepted.\n\ # If \"optional\" is specified, client certificates are accepted and must be\n\ # valid if provided, but are not required.\n#\n# tls-auth-clients no\n# tls-auth-clients\ \ optional\n\n# By default, a Valkey replica does not attempt to establish a TLS\ \ connection\n# with its primary.\n#\n# Use the following directive to enable\ \ TLS on replication links.\n#\n# tls-replication yes\n\n# By default, the Valkey\ \ 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# By default, only TLSv1.2\ \ and TLSv1.3 are enabled and it is highly recommended\n# that older formally\ \ deprecated versions are kept disabled to reduce the attack surface.\n# You can\ \ explicitly specify TLS versions to support.\n# Allowed values are case insensitive\ \ and include \"TLSv1\", \"TLSv1.1\", \"TLSv1.2\",\n# \"TLSv1.3\" (OpenSSL >=\ \ 1.1.1) or any combination.\n# 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# By default, TLS session caching is enabled to allow faster and less\ \ expensive\n# reconnections by clients that support it. Use the following directive\ \ to disable\n# caching.\n#\n# tls-session-caching no\n\n# Change the default\ \ number of TLS sessions cached. A zero value sets the cache\n# to unlimited size.\ \ The default size is 20480.\n#\n# tls-session-cache-size 5000\n\n# Change the\ \ default timeout of cached TLS sessions. The default timeout is 300\n# seconds.\n\ #\n# tls-session-cache-timeout 60\n\n################################# GENERAL\ \ #####################################\n\n# By default Valkey does not run as\ \ a daemon. Use 'yes' if you need it.\n# Note that Valkey will write a pid file\ \ in /var/run/valkey.pid when daemonized.\n# When Valkey is supervised by upstart\ \ or systemd, this parameter has no impact.\ndaemonize no\n\n# If you run Valkey\ \ from upstart or systemd, Valkey can interact with your\n# supervision tree.\ \ Options:\n# supervised no - no supervision interaction\n# supervised\ \ upstart - signal upstart by putting Valkey into SIGSTOP mode\n# \ \ requires \"expect stop\" in your upstart job config\n# supervised\ \ systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET\n# \ \ on startup, and updating Valkey status on a regular\n# \ \ basis.\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 pings back to your supervisor.\n#\n# The\ \ default is \"no\". To run under upstart/systemd, you can simply uncomment\n\ # the line below:\n#\n# supervised auto\n\n# If a pid file is specified, Valkey\ \ 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/valkey.pid\".\n#\n# Creating a pid\ \ file is best effort: if Valkey is not able to create it\n# nothing bad happens,\ \ the server will start and run normally.\n#\n# Note that on modern Linux systems\ \ \"/run/valkey.pid\" is more conforming\n# and should be used instead.\npidfile\ \ /opt/bitnami/valkey/tmp/valkey_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# Valkey 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 valkey\n\n# Specify the syslog facility.\ \ Must be USER or between LOCAL0-LOCAL7.\n# syslog-facility local0\n\n# To disable\ \ the built in crash log, which will possibly produce cleaner core\n# dumps when\ \ they are needed, uncomment the following:\n#\n# crash-log-enabled no\n\n# To\ \ disable the fast memory check that's run as part of the crash log, which\n#\ \ will possibly let valkey terminate sooner, uncomment the following:\n#\n# crash-memcheck-enabled\ \ no\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 where\n# dbid\ \ is a number between 0 and 'databases'-1\ndatabases 16\n\n# By default Valkey\ \ shows an ASCII art logo only when started to log to the\n# standard output and\ \ if the standard output is a TTY and syslog logging is\n# disabled. Basically\ \ this means that normally a logo is displayed only in\n# 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# By default, Valkey modifies the process title (as seen in 'top' and\ \ 'ps') to\n# provide some runtime information. It is possible to disable this\ \ and leave\n# the process name as executed by setting the following to no.\n\ set-proc-title yes\n\n# When changing the process title, Valkey uses the following\ \ template to construct\n# the modified title.\n#\n# Template variables are specified\ \ in curly brackets. The following variables are\n# supported:\n#\n# {title} \ \ Name of process as executed if parent, or type of child process.\n\ # {listen-addr} Bind address or '*' followed by TCP or TLS port listening\ \ on, or\n# Unix socket if only that's available.\n# {server-mode}\ \ Special mode, i.e. \"[sentinel]\" or \"[cluster]\".\n# {port} \ \ TCP port listening on, or 0.\n# {tls-port} TLS port listening on, or\ \ 0.\n# {unixsocket} Unix domain socket listening on, or \"\".\n# {config-file}\ \ Name of configuration file used.\n#\nproc-title-template \"{title} {listen-addr}\ \ {server-mode}\"\n\n################################ SNAPSHOTTING ################################\n\ \n# Save the DB to disk.\n#\n# save [ ...]\n\ #\n# Valkey will save the DB if the given number of seconds elapsed and it\n#\ \ surpassed the given number of write operations against the DB.\n#\n# Snapshotting\ \ can be completely disabled with a single empty string argument\n# as in following\ \ example:\n#\n# save \"\"\n#\n# Unless specified otherwise, by default Valkey\ \ will save the DB:\n# * After 3600 seconds (an hour) if at least 1 change was\ \ performed\n# * After 300 seconds (5 minutes) if at least 100 changes were\ \ performed\n# * After 60 seconds if at least 10000 changes were performed\n\ #\n# You can set these explicitly by uncommenting the following line.\n#\n# save\ \ 3600 1 300 100 60 10000\nsave 900 1 300 10 60 10000\n# By default Valkey 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 Valkey will\n# automatically allow writes\ \ again.\n#\n# However if you have setup your proper monitoring of the Valkey\ \ server\n# and persistence, you may want to disable this feature so that Valkey\ \ 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# By default compression is enabled 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# Enables or disables\ \ full sanitization checks for ziplist and listpack etc when\n# loading an RDB\ \ or RESTORE payload. This reduces the chances of a assertion or\n# crash later\ \ on while processing commands.\n# Options:\n# no - Never perform full\ \ sanitization\n# yes - Always perform full sanitization\n# clients\ \ - Perform full sanitization only for user connections.\n# \ \ Excludes: RDB files, RESTORE commands received from the primary\n# \ \ connection, and client connections which have the\n# skip-sanitize-payload\ \ ACL flag.\n# The default should be 'clients' but since it currently affects\ \ cluster\n# resharding via MIGRATE, it is temporarily set to 'no' by default.\n\ #\n# sanitize-dump-payload no\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 primarys 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 primary 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 /bitnami/valkey/data\n\n#################################\ \ REPLICATION #################################\n\n# Primary-Replica replication.\ \ Use replicaof to make a Valkey instance a copy of\n# another Valkey server.\ \ A few things to understand ASAP about Valkey replication.\n#\n# +------------------+\ \ +---------------+\n# | Primary | ---> | Replica |\n#\ \ | (receive writes) | | (exact copy) |\n# +------------------+ \ \ +---------------+\n#\n# 1) Valkey replication is asynchronous, but you can\ \ configure a primary to\n# stop accepting writes if it appears to be not connected\ \ with at least\n# a given number of replicas.\n# 2) Valkey replicas are able\ \ to perform a partial resynchronization with the\n# primary 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 primarys\n# and resynchronize with them.\n#\n# replicaof\ \ \n\n# If the primary 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 primary will\n# refuse the replica request.\n#\n# primaryauth\ \ \n#\n# However this is not enough if you are using Valkey\ \ ACLs (for Valkey 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# primaryuser configuration as such:\n#\n# primaryuser \n\ #\n# When primaryuser is specified, the replica will authenticate against its\n\ # primary using the new AUTH form: AUTH .\n\n# When a replica\ \ loses its connection with the primary, 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 error\n# \"MASTERDOWN Link with MASTER is\ \ down and replica-serve-stale-data is set to 'no'\"\n# to all data access\ \ commands, excluding commands such as:\n# INFO, REPLICAOF, AUTH, SHUTDOWN,\ \ REPLCONF, ROLE, CONFIG, SUBSCRIBE,\n# UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE,\ \ PUBLISH, PUBSUB, COMMAND, POST,\n# 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 primary)\ \ but\n# may also cause problems if clients are writing to it because of a\n#\ \ misconfiguration.\n#\n# In Vakey 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 primary to the\n# replicas.\n#\n# The transmission can happen in two different\ \ ways:\n#\n# 1) Disk-backed: The Valkey primary 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 Valkey primary 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 primary 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# When diskless replication is enabled\ \ with a delay, it is possible to let\n# the replication start before the maximum\ \ delay is reached if the maximum\n# number of replicas expected have connected.\ \ Default of 0 means that the\n# maximum is not defined and Valkey will wait the\ \ full delay.\nrepl-diskless-sync-max-replicas 0\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 + Valkey modules not handling I/O reads may also\n\ # cause Valkey to abort in case of I/O errors during the initial synchronization\n\ # stage with the primary. Use only if you know 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\ # received from the primary.\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 primary's\n# Copy on Write memory and replica 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 current\ \ db contents in RAM while parsing the data directly\n# from the\ \ socket. Replicas in this mode can keep serving current\n# data\ \ set while replication is in progress, except for cases where\n# \ \ they can't recognize primary as having a data set from same\n# \ \ replication history.\n# Note that this requires sufficient\ \ memory, if you don't have it,\n# you risk an OOM kill.\nrepl-diskless-load\ \ disabled\n\n# Primary send PINGs to its replicas 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) Primary timeout from the\ \ point of view of replicas (data, pings).\n# 3) Replica timeout from the point\ \ of view of primary nodes (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 primary and the replica. The default\n# value is 60 seconds.\n#\n# repl-timeout\ \ 60\n\n# Disable TCP_NODELAY on the replica socket after SYNC?\n#\n# If you select\ \ \"yes\" Valkey 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 primary 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 replica can endure the\n\ # disconnect and later be able to perform a partial resynchronization.\n#\n# The\ \ backlog is only allocated if there is at least one replica connected.\n#\n#\ \ repl-backlog-size 1mb\n\n# After a primary has no connected replicas for some\ \ time, the backlog will be\n# freed. The following option configures the amount\ \ of seconds that need to\n# elapse, starting from the time the last replica disconnected,\ \ for the backlog\n# buffer to be freed.\n#\n# Note that replicas never free the\ \ backlog for timeout, since they may be\n# promoted to primarys later, and should\ \ be able to correctly \"partially\n# resynchronize\" with other 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 Valkey in the INFO\n# output. It is used by Valkey Sentinel\ \ in order to select a replica to promote\n# into a primary if the primary 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 primary, so a replica with priority of 0 will never be selected\ \ by\n# Valkey Sentinel for promotion.\n#\n# By default the priority is 100.\n\ replica-priority 100\n\n# The propagation error behavior controls how Valkey will\ \ behave when it is\n# unable to handle a command being processed in the replication\ \ stream from a primary\n# or processed while reading from an AOF file. Errors\ \ that occur during propagation\n# are unexpected, and can cause data inconsistency.\ \ However, there are edge cases\n# in earlier versions of Valkey where it was\ \ possible for the server to replicate or persist\n# commands that would fail\ \ on future versions. For this reason the default behavior\n# is to ignore such\ \ errors and continue processing commands.\n#\n# If an application wants to ensure\ \ there is no data divergence, this configuration\n# should be set to 'panic'\ \ instead. The value can also be set to 'panic-on-replicas'\n# to only panic when\ \ a replica encounters an error on the replication stream. One of\n# these two\ \ panic values will become the default value in the future once there are\n# sufficient\ \ safety mechanisms in place to prevent false positive crashes.\n#\n# propagation-error-behavior\ \ ignore\n\n# Replica ignore disk write errors controls the behavior of a replica\ \ when it is\n# unable to persist a write command received from its primary to\ \ disk. By default,\n# this configuration is set to 'no' and will crash the replica\ \ in this condition.\n# It is not recommended to change this default, however\ \ in order to be compatible\n# with older versions of Valkey this config can be\ \ toggled to 'yes' which will just\n# log a warning and execute the write command\ \ it got from the primary.\n#\n# replica-ignore-disk-write-errors no\n\n# -----------------------------------------------------------------------------\n\ # By default, Valkey Sentinel includes all replicas in its reports. A replica\n\ # can be excluded from Valkey Sentinel's announcements. An unannounced replica\n\ # will be ignored by the 'sentinel replicas ' command and won't be\n\ # exposed to Valkey Sentinel's clients.\n#\n# This option does not change the\ \ behavior of replica-priority. Even with\n# replica-announced set to 'no', the\ \ replica can be promoted to primary. To\n# prevent this behavior, set replica-priority\ \ to 0.\n#\n# replica-announced yes\n\n# It is possible for a primary 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 Valkey\ \ primary 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# Valkey 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 primary.\n#\n# The listed IP\ \ address and port normally reported by a replica is\n# obtained 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 primary.\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 actually be 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\ \ primary 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# Valkey implements server assisted support\ \ for client side caching of values.\n# This is implemented using an invalidation\ \ table that remembers, using\n# a radix key indexed by key name, what clients\ \ have which keys. In turn\n# this is used in order to send invalidation messages\ \ to clients. \n#\n# When tracking is enabled for a client, all the read only\ \ queries are assumed\n# to be cached: this will force Valkey 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, Valkey 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, Valkey 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 Valkey 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 Valkey 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# Valkey ACL users are defined in the following format:\n\ #\n# user ... 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 a 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# skip-sanitize-payload RESTORE dump-payload sanitization\ \ is skipped.\n# sanitize-payload RESTORE dump-payload is sanitized (default).\n\ # + Allow the execution of that command.\n# May be used\ \ with `|` for allowing subcommands (e.g \"+config|get\")\n# - Disallow\ \ the execution of that command.\n# May be used with `|` for blocking\ \ subcommands (e.g \"-config|set\")\n# +@ 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 Valkey 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# +|first-arg Allow\ \ a specific first argument of an otherwise\n# disabled\ \ command. It is only supported on commands with\n# no\ \ sub-commands, and is not allowed as negative form\n# \ \ like -SELECT|1, only additive starting with \"+\". This\n# \ \ feature is deprecated and may be removed in the future.\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# ~ 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# %R~ Add key read\ \ pattern that specifies which keys can be read\n# from.\n# %W~\ \ Add key write pattern that specifies which keys can be\n# written\ \ to.\n# allkeys Alias for ~*\n# resetkeys Flush the list of allowed\ \ keys patterns.\n# & Add a glob-style pattern of Pub/Sub channels\ \ that can be\n# accessed by the user. It is possible to specify\ \ multiple channel\n# patterns.\n# allchannels Alias for &*\n\ # resetchannels Flush the list of allowed channel patterns.\n# >\ \ Add this password 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# < 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# () Create a new selector with the\ \ options specified within the\n# parentheses and attach it to the\ \ user. Each option should be\n# space separated. The first character\ \ must be ( and the last\n# character must be ).\n# clearselectors\ \ Remove all of the currently attached selectors.\n# \ \ Note this does not change the \"root\" user permissions,\n# \ \ which are the permissions directly applied onto the\n\ # user (outside the parentheses).\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# The\ \ following is a list of command categories and their meanings:\n# * keyspace\ \ - Writing or reading from keys, databases, or their metadata\n# in a type\ \ agnostic way. Includes DEL, RESTORE, DUMP, RENAME, EXISTS, DBSIZE,\n# KEYS,\ \ EXPIRE, TTL, FLUSHALL, etc. Commands that may modify the keyspace,\n# key\ \ or metadata will also have `write` category. Commands that only read\n# \ \ the keyspace, key or metadata will have the `read` category.\n# * read - Reading\ \ from keys (values or metadata). Note that commands that don't\n# interact\ \ with keys, will not have either `read` or `write`.\n# * write - Writing to keys\ \ (values or metadata)\n# * admin - Administrative commands. Normal applications\ \ will never need to use\n# these. Includes REPLICAOF, CONFIG, DEBUG, SAVE,\ \ MONITOR, ACL, SHUTDOWN, etc.\n# * dangerous - Potentially dangerous (each should\ \ be considered with care for\n# various reasons). This includes FLUSHALL,\ \ MIGRATE, RESTORE, SORT, KEYS,\n# CLIENT, DEBUG, INFO, CONFIG, SAVE, REPLICAOF,\ \ etc.\n# * connection - Commands affecting the connection or other connections.\n\ # This includes AUTH, SELECT, COMMAND, CLIENT, ECHO, PING, etc.\n# * blocking\ \ - Potentially blocking the connection until released by another\n# command.\n\ # * fast - Fast O(1) commands. May loop on the number of arguments, but not the\n\ # number of elements in the key.\n# * slow - All commands that are not Fast.\n\ # * pubsub - PUBLISH / SUBSCRIBE related\n# * transaction - WATCH / MULTI / EXEC\ \ related commands.\n# * scripting - Scripting related.\n# * set - Data type:\ \ sets related.\n# * sortedset - Data type: zsets related.\n# * list - Data type:\ \ lists related.\n# * hash - Data type: hashes related.\n# * string - Data type:\ \ strings related.\n# * bitmap - Data type: bitmaps related.\n# * hyperloglog\ \ - Data type: hyperloglog related.\n# * geo - Data type: geo related.\n# * stream\ \ - Data type: streams related.\n#\n# For more information about ACL configuration\ \ please refer to\n# the Valkey web site at https://valkey.io/docs/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 memory. You can reclaim memory\ \ with\n# ACL LOG RESET. Define the maximum entry length of the ACL Log below.\n\ acllog-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 external\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 valkey.conf to describe users.\n#\n# aclfile\ \ /etc/valkey/users.acl\n\n# The option effect will be just setting the password\ \ for the default user. \n# Clients will still authenticate using AUTH \ \ as usually, or more \n# explicitly with AUTH default if they follow\ \ the new protocol: \n# both will work.\n#\n# The requirepass is not compatible\ \ with aclfile option and the ACL LOAD\n# command, these will cause requirepass\ \ to be ignored.\n#\n# requirepass foobared\n\n# New users are initialized with\ \ restrictive permissions by default, via the\n# equivalent of this ACL rule 'off\ \ resetkeys -@all'. It\n# is possible to manage access to Pub/Sub channels with\ \ ACL rules as well. The\n# default Pub/Sub channels permission if new users is\ \ controlled by the\n# acl-pubsub-default configuration directive, which accepts\ \ one of these values:\n#\n# allchannels: grants access to all Pub/Sub channels\n\ # resetchannels: revokes access to all Pub/Sub channels\n#\n# acl-pubsub-default\ \ resetchannels\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 Valkey 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 Valkey reserves a few file descriptors for internal\ \ uses).\n#\n# Once the limit is reached Valkey will close all the new connections\ \ sending\n# an error 'max number of clients reached'.\n#\n# IMPORTANT: When Valkey\ \ Cluster is used, the max number of connections is also\n# shared with the cluster\ \ bus: every node in the cluster will use two\n# connections, one incoming and\ \ another outgoing. It is important to size the\n# limit accordingly in case of\ \ very large clusters.\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 Valkey\ \ will try to remove keys\n# according to the eviction policy selected (see maxmemory-policy).\n\ #\n# If Valkey can't remove keys according to the policy, or if the policy is\n\ # set to 'noeviction', Valkey 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\ \ Valkey 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 \n\n# MAXMEMORY POLICY: how Valkey 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, when there\ \ are no suitable keys for\n# eviction, Valkey will return an error on write operations\ \ that require\n# more memory. These are usually commands that create new keys,\ \ add data or\n# modify existing keys. A few examples are: SET, INCR, HSET, LPUSH,\ \ SUNIONSTORE,\n# SORT (due to the STORE argument), and EXEC (if the transaction\ \ includes any\n# command that requires memory).\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. By default Valkey will check five keys and pick the\ \ one that was\n# used least 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# Eviction processing is\ \ designed to function well with the default setting.\n# If there is an unusually\ \ large amount of write traffic, this value may need to\n# be increased. Decreasing\ \ this value may reduce latency at the risk of\n# eviction processing effectiveness\n\ # 0 = minimum latency, 10 = default, 100 = process without regard to latency\n\ #\n# maxmemory-eviction-tenacity 10\n\n# By default a replica will ignore its\ \ maxmemory setting\n# (unless it is promoted to primary after a failover or manually).\ \ It means\n# that the eviction of keys will be just handled by the primary, sending\ \ the\n# DEL commands to the replica as keys evict in the primary side.\n#\n#\ \ This behavior ensures that primarys 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# primary hits the configured maxmemory setting.\n#\n\ # replica-ignore-maxmemory yes\n\n# Valkey 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 tolerate less already expired keys\ \ still present\n# in the system. It's a tradeoff between memory, CPU and latency.\n\ #\n# active-expire-effort 1\n\n############################# LAZY FREEING ####################################\n\ \n# Valkey 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 Valkey. 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 Valkey 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 Valkey server\ \ sometimes has to\n# delete keys or flush the whole database as a side effect\ \ of other operations.\n# Specifically Valkey 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 primary, 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# FLUSHDB, FLUSHALL,\ \ SCRIPT FLUSH and FUNCTION FLUSH support both asynchronous and synchronous\n\ # deletion, which can be controlled by passing the [SYNC|ASYNC] flags into the\n\ # commands. When neither flag is passed, this directive will be used to determine\n\ # if the data should be deleted asynchronously.\n\nlazyfree-lazy-user-flush no\n\ \n################################ THREADED I/O #################################\n\ \n# Valkey 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 Valkey clients socket\ \ reads and writes\n# in different I/O threads. Since especially writing is so\ \ slow, normally\n# Valkey users use pipelining in order to speed up the Valkey\ \ 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 Valkey 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 Valkey\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 usual.\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. Also, this feature\ \ currently does not work when SSL is\n# enabled.\n#\n# NOTE 2: If you want to\ \ test the Valkey speedup using valkey-benchmark, make\n# sure you also run the\ \ benchmark itself in threaded mode, using the\n# --threads option to match the\ \ number of Valkey threads, otherwise you'll not\n# be able to notice the improvements.\n\ \n############################ KERNEL OOM CONTROL ##############################\n\ \n# On Linux, it is possible to hint the kernel OOM killer on what processes\n\ # should be killed first when out of memory.\n#\n# Enabling this feature makes\ \ Valkey actively control the oom_score_adj value\n# for all its processes, depending\ \ on their role. The default scores will\n# attempt to have background child processes\ \ killed before all others, and\n# replicas killed before primarys.\n#\n# Valkey\ \ supports these options:\n#\n# no: Don't make changes to oom-score-adj\ \ (default).\n# yes: Alias to \"relative\" see below.\n# absolute: Values\ \ in oom-score-adj-values are written as is to the kernel.\n# relative: Values\ \ are used relative to the initial value of oom_score_adj when\n# the\ \ server starts and are then clamped to a range of -1000 to 1000.\n# \ \ Because typically the initial value is 0, they will often match the\n# \ \ absolute values.\noom-score-adj no\n\n# When oom-score-adj is used, this\ \ directive controls the specific values used\n# for primary, replica and background\ \ child processes. Values range -2000 to\n# 2000 (higher means more likely to\ \ be killed).\n#\n# Unprivileged processes (not root, and without CAP_SYS_RESOURCE\ \ capabilities)\n# can freely increase their value, but not decrease it below\ \ its initial\n# settings. This means that setting oom-score-adj to \"relative\"\ \ and setting the\n# oom-score-adj-values to positive values will always succeed.\n\ oom-score-adj-values 0 200 800\n\n\n#################### KERNEL transparent hugepage\ \ CONTROL ######################\n\n# Usually the kernel Transparent Huge Pages\ \ control is set to \"madvise\" or\n# or \"never\" by default (/sys/kernel/mm/transparent_hugepage/enabled),\ \ in which\n# case this config has no effect. On systems in which it is set to\ \ \"always\",\n# valkey will attempt to disable it specifically for the valkey\ \ process in order\n# to avoid latency problems specifically with fork(2) and\ \ CoW.\n# If for some reason you prefer to keep it enabled, you can set this config\ \ to\n# \"no\" and the kernel global to \"always\".\n\ndisable-thp yes\n\n##############################\ \ APPEND ONLY MODE ###############################\n\n# By default Valkey asynchronously\ \ dumps the dataset on disk. This mode is\n# good enough in many applications,\ \ but an issue with the Valkey 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) Valkey 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 Valkey 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 Valkey will\ \ load the AOF, that is the file\n# with the better durability guarantees.\n#\n\ # Please check https://valkey.io/docs/topics/persistence/ for more information.\n\ \nappendonly no\n\n# The base name of the append only file.\n#\n# Valkey 7 and\ \ newer use a set of append-only files to persist the dataset\n# and changes applied\ \ to it. There are two basic types of files in use:\n#\n# - Base files, which\ \ are a snapshot representing the complete state of the\n# dataset at the time\ \ the file was created. Base files can be either in\n# the form of RDB (binary\ \ serialized) or AOF (textual commands).\n# - Incremental files, which contain\ \ additional commands that were applied\n# to the dataset following the previous\ \ file.\n#\n# In addition, manifest files are used to track the files and the\ \ order in\n# which they were created and should be applied.\n#\n# Append-only\ \ file names are created by Valkey following a specific pattern.\n# The file name's\ \ prefix is based on the 'appendfilename' configuration\n# parameter, followed\ \ by additional information about the sequence and type.\n#\n# For example, if\ \ appendfilename is set to appendonly.aof, the following file\n# names could be\ \ derived:\n#\n# - appendonly.aof.1.base.rdb as a base file.\n# - appendonly.aof.1.incr.aof,\ \ appendonly.aof.2.incr.aof as incremental files.\n# - appendonly.aof.manifest\ \ as a manifest file.\n\nappendfilename \"appendonly.aof\"\n\n# For convenience,\ \ Valkey stores all persistent append-only files in a dedicated\n# directory.\ \ The name of the directory is determined by the appenddirname\n# configuration\ \ parameter.\n\nappenddirname \"appendonlydir\"\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# Valkey 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# 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# Valkey 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 Valkey is\n# the same as \"appendfsync no\"\ . 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# Valkey 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: Valkey 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 Valkey\n\ # startup process, when the AOF data gets loaded back into memory.\n# This may\ \ happen when the system where Valkey is running\n# crashes, especially when an\ \ ext4 filesystem is mounted without the\n# data=ordered option (however this\ \ can't happen when Valkey itself\n# crashes or aborts but the operating system\ \ still works correctly).\n#\n# Valkey 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 Valkey 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 \"valkey-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# Valkey will try to read more data from the AOF file but not enough bytes\n\ # will be found.\naof-load-truncated yes\n\n# Valkey can create append-only base\ \ files in either RDB or AOF formats. Using\n# the RDB format is always faster\ \ and more efficient, and disabling it is only\n# supported for backward compatibility\ \ purposes.\naof-use-rdb-preamble yes\n\n# Valkey supports recording timestamp\ \ annotations in the AOF to support restoring\n# the data from a specific point-in-time.\ \ However, using this capability changes\n# the AOF format in a way that may not\ \ be compatible with existing AOF parsers.\naof-timestamp-enabled no\n\n################################\ \ SHUTDOWN #####################################\n\n# Maximum time to wait for\ \ replicas when shutting down, in seconds.\n#\n# During shut down, a grace period\ \ allows any lagging replicas to catch up with\n# the latest replication offset\ \ before the primary exists. This period can\n# prevent data loss, especially\ \ for deployments without configured disk backups.\n#\n# The 'shutdown-timeout'\ \ value is the grace period's duration in seconds. It is\n# only applicable when\ \ the instance has replicas. To disable the feature, set\n# the value to 0.\n\ #\n# shutdown-timeout 10\n\n# When Valkey receives a SIGINT or SIGTERM, shutdown\ \ is initiated and by default\n# an RDB snapshot is written to disk in a blocking\ \ operation if save points are configured.\n# The options used on signaled shutdown\ \ can include the following values:\n# default: Saves RDB snapshot only if save\ \ points are configured.\n# Waits for lagging replicas to catch up.\n\ # save: Forces a DB saving operation even if no save points are configured.\n\ # nosave: Prevents DB saving operation even if one or more save points are configured.\n\ # now: Skips waiting for lagging replicas.\n# force: Ignores any errors\ \ that would normally prevent the server from exiting.\n#\n# Any combination of\ \ values is allowed as long as \"save\" and \"nosave\" are not set simultaneously.\n\ # Example: \"nosave force now\"\n#\n# shutdown-on-sigint default\n# shutdown-on-sigterm\ \ default\n\n################ NON-DETERMINISTIC LONG BLOCKING COMMANDS #####################\n\ \n# Maximum time in milliseconds for EVAL scripts, functions and in some cases\n\ # modules' commands before Valkey can start processing or rejecting other clients.\n\ #\n# If the maximum execution time is reached Valkey will start to reply to most\n\ # commands with a BUSY error.\n#\n# In this state Valkey will only allow a handful\ \ of commands to be executed.\n# For instance, SCRIPT KILL, FUNCTION KILL, SHUTDOWN\ \ NOSAVE and possibly some\n# module specific 'allow-busy' commands.\n#\n# SCRIPT\ \ KILL and FUNCTION KILL will only be able to stop a script that did not\n# yet\ \ call any write commands, so SHUTDOWN NOSAVE may be the only way to stop\n# the\ \ server in the case a write command was already issued by the script when\n#\ \ the user doesn't want to wait for the natural termination of the script.\n#\n\ # The default is 5 seconds. It is possible to set it to 0 or a negative value\n\ # to disable this mechanism (uninterrupted execution). Note that in the past\n\ # this config had a different name, which is now an alias, so both of these do\n\ # the same:\nlua-time-limit 5000\n# busy-reply-threshold 5000\n\n################################\ \ VALKEY CLUSTER ###############################\n\n# Normal Valkey instances\ \ can't be part of a Valkey Cluster; only nodes that are\n# started as cluster\ \ nodes can. In order to start a Valkey instance as a\n# cluster node enable the\ \ cluster support uncommenting the following:\n#\ncluster-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 Valkey nodes.\n# Every Valkey\ \ 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#\ncluster-config-file /bitnami/valkey/data/nodes.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\ \ a multiple of the node timeout.\n#\n# cluster-node-timeout 15000\n\n# The cluster\ \ port is the port that the cluster bus will listen for inbound connections on.\ \ When set\n# to the default value, 0, it will be bound to the command port +\ \ 10000. Setting this value requires\n# you to specify the cluster bus port when\ \ executing cluster meet.\n# cluster-port 0\n\n# A replica of a failing primary\ \ 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 primary 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 primary. This can be the last ping or command received (if the primary\n\ # is still in the \"connected\" state), or the time that elapsed since the\n\ # disconnection with the primary (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 primary,\ \ the time\n# elapsed is greater than:\n#\n# (node-timeout * cluster-replica-validity-factor)\ \ + repl-ping-replica-period\n#\n# So for example if node-timeout is 30 seconds,\ \ and the cluster-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 primary\n# for longer than 310 seconds.\n#\n# A large cluster-replica-validity-factor\ \ may allow replicas with too old data to failover\n# a primary, 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 cluster-replica-validity-factor\n\ # to a value of 0, which means, that replicas will always try to failover the\n\ # primary regardless of the last time they interacted with the primary.\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 primarys, that are\ \ primarys\n# that are left without working replicas. This improves the cluster\ \ ability\n# to resist to failures as otherwise an orphaned primary can't be failed\ \ over\n# in case of failure if it has no working replicas.\n#\n# Replicas migrate\ \ to orphaned primarys only if there are still at least a\n# given number of other\ \ working replicas for their old primary. 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 primary\n# and so forth. It usually\ \ reflects the number of replicas you want for every\n# primary in your cluster.\n\ #\n# Default is 1 (replicas migrate only if their primarys remain with at least\n\ # one replica). To disable migration just set it to a very large value or\n# set\ \ cluster-allow-replica-migration to 'no'.\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# Turning off this option allows to use less automatic cluster configuration.\n\ # It both disables migration to orphaned primarys and migration from primarys\n\ # that became empty.\n#\n# Default is 'yes' (allow automatic migrations).\n#\n\ # cluster-allow-replica-migration yes\n\n# By default Valkey Cluster nodes stop\ \ accepting queries if they detect there\n# is at least a 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# primary during\ \ primary failures. However the replica 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# 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# primary 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 primarys, slot ownership\ \ will not change automatically.\n#\n# cluster-allow-reads-when-down no\n\n# This\ \ option, when set to yes, allows nodes to serve pubsub shard traffic while\n\ # the cluster is in a down state, as long as it believes it owns the slots.\n\ #\n# This is useful if the application would like to use the pubsub feature even\ \ when\n# the cluster global stable state is not OK. If the application wants\ \ to make sure only\n# one shard is serving a given channel, this feature should\ \ be kept as yes.\n#\n# cluster-allow-pubsubshard-when-down yes\n\n# Cluster link\ \ send buffer limit is the limit on the memory usage of an individual\n# cluster\ \ bus link's send buffer in bytes. Cluster links would be freed if they exceed\n\ # this limit. This is to primarily prevent send buffers from growing unbounded\ \ on links\n# toward slow peers (E.g. PubSub messages being piled up).\n# This\ \ limit is disabled by default. Enable this limit when 'mem_cluster_links' INFO\ \ field\n# and/or 'send-buffer-allocated' entries in the 'CLUSTER LINKS` command\ \ output continuously increase.\n# Minimum limit of 1gb is recommended so that\ \ cluster link buffer can fit in at least a single\n# PubSub message by default.\ \ (client-query-buffer-limit default value is 1gb)\n#\n# cluster-link-sendbuf-limit\ \ 0\n\n# Clusters can configure their announced hostname using this config. This\ \ is a common use case for\n# applications that need to use TLS Server Name Indication\ \ (SNI) or dealing with DNS based\n# routing. By default this value is only shown\ \ as additional metadata in the CLUSTER SLOTS\n# command, but can be changed using\ \ 'cluster-preferred-endpoint-type' config. This value is\n# communicated along\ \ the clusterbus to all nodes, setting it to an empty string will remove\n# the\ \ hostname and also propagate the removal.\n#\n# cluster-announce-hostname \"\"\ \n\n# Clusters can advertise how clients should connect to them using either their\ \ IP address,\n# a user defined hostname, or by declaring they have no endpoint.\ \ Which endpoint is\n# shown as the preferred endpoint is set by using the cluster-preferred-endpoint-type\n\ # config with values 'ip', 'hostname', or 'unknown-endpoint'. This value controls\ \ how\n# the endpoint returned for MOVED/ASKING requests as well as the first\ \ field of CLUSTER SLOTS.\n# If the preferred endpoint type is set to hostname,\ \ but no announced hostname is set, a '?'\n# will be returned instead.\n#\n# When\ \ a cluster advertises itself as having an unknown endpoint, it's indicating that\n\ # the server doesn't know how clients can reach the cluster. This can happen in\ \ certain\n# networking situations where there are multiple possible routes to\ \ the node, and the\n# server doesn't know which one the client took. In this\ \ case, the server is expecting\n# the client to reach out on the same endpoint\ \ it used for making the last request, but use\n# the port provided in the response.\n\ #\n# cluster-preferred-endpoint-type ip\n\n########################## CLUSTER\ \ DOCKER/NAT support ########################\n\n# In certain deployments, Valkey\ \ 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 Valkey Cluster working in such environments, a static\n\ # configuration where each node knows its public address is needed. The\n# following\ \ four options are used for this scope, and are:\n#\n# * cluster-announce-ip\n\ # * cluster-announce-port\n# * cluster-announce-tls-port\n# * cluster-announce-bus-port\n\ #\n# Each instructs the node about its address, client ports (for connections\n\ # without and with TLS) and cluster message bus port. The information is then\n\ # published in the header of the bus packets so that other nodes will be able\ \ to\n# correctly map the address of the node publishing the information.\n#\n\ # If cluster-tls is set to yes and cluster-announce-tls-port is omitted or set\n\ # to zero, then cluster-announce-port refers to the TLS port. Note also that\n\ # cluster-announce-tls-port has no effect if cluster-tls is set to no.\n#\n# If\ \ the above options are not used, the normal Valkey 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 usual.\n#\n# Example:\n#\n# cluster-announce-ip\ \ 10.1.1.5\n# cluster-announce-tls-port 6379\n# cluster-announce-port 0\n# cluster-announce-bus-port\ \ 6380\n\n################################## SLOW LOG ###################################\n\ \n# The Valkey 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 Valkey\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.\n\ slowlog-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 Valkey latency monitoring\ \ subsystem samples different operations\n# at runtime in order to collect data\ \ related to possible sources of\n# latency of a Valkey 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 \"\ \ if needed.\nlatency-monitor-threshold 0\n\n################################\ \ LATENCY TRACKING ##############################\n\n# The Valkey extended latency\ \ monitoring tracks the per command latencies and enables\n# exporting the percentile\ \ distribution via the INFO latencystats command,\n# and cumulative latency distributions\ \ (histograms) via the LATENCY command.\n#\n# By default, the extended latency\ \ monitoring is enabled since the overhead\n# of keeping track of the command\ \ latency is very small.\n# latency-tracking yes\n\n# By default the exported\ \ latency percentiles via the INFO latencystats command\n# are the p50, p99, and\ \ p999.\n# latency-tracking-info-percentiles 50 99 99.9\n\n#############################\ \ EVENT NOTIFICATION ##############################\n\n# Valkey can notify Pub/Sub\ \ clients about events happening in the key space.\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 Valkey will notify among\ \ a set\n# of classes. Every class is identified by a single character:\n#\n#\ \ K Keyspace events, published with __keyspace@__ prefix.\n# E Keyevent\ \ events, published with __keyevent@__ 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# n New key events (Note: not included in the 'A' class)\n\ # t Stream commands\n# d Module key type events\n# m Key-miss events\ \ (Note: It is not included in the 'A' class)\n# A Alias for g$lshzxetd,\ \ 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############################### 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.\n\ hash-max-listpack-entries 512\nhash-max-listpack-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-listpack-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-listpack-entries 128\nzset-max-listpack-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 entries 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 Valkey hash table (the one mapping top-level\n# keys\ \ to values). The hash table implementation Valkey 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 Valkey 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 \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# Note that it doesn't make sense to set\ \ the replica clients output buffer\n# limit lower than the repl-backlog-size\ \ config (partial sync will succeed\n# and then replica will get disconnected).\n\ # Such a configuration is ignored (the size of repl-backlog-size will be used).\n\ # This doesn't have memory consumption implications since the replica client\n\ # will share the backlog buffers memory.\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 some scenarios client connections can hog up memory leading to OOM\n\ # errors or data eviction. To avoid this we can cap the accumulated memory\n#\ \ used by all client connections (all pubsub and normal clients). Once we\n# reach\ \ that limit connections will be dropped by the server freeing up\n# memory. The\ \ server will attempt to drop the connections using the most\n# memory first.\ \ We call this mechanism \"client eviction\".\n#\n# Client eviction is configured\ \ using the maxmemory-clients setting as follows:\n# 0 - client eviction is disabled\ \ (default)\n#\n# A memory value can be used for the client eviction threshold,\n\ # for example:\n# maxmemory-clients 1g\n#\n# A percentage value (between 1% and\ \ 100%) means the client eviction threshold\n# is based on a percentage of the\ \ maxmemory setting. For example to set client\n# eviction at 5% of maxmemory:\n\ # maxmemory-clients 5%\n\n# In the Valkey protocol, bulk requests, that are, elements\ \ representing single\n# strings, are normally limited to 512 mb. However you\ \ can change this limit\n# here, but must be 1mb or greater\n#\n# proto-max-bulk-len\ \ 512mb\n\n# Valkey 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 Valkey 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# Valkey is idle, but at the same time will make Valkey\ \ 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, Valkey\n# offers,\ \ and enables by default, the ability to use an adaptive HZ value\n# which will\ \ temporarily 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 4 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.\n\ aof-rewrite-incremental-fsync yes\n\n# When valkey saves RDB file, if the following\ \ option is enabled\n# the file will be fsync-ed every 4 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# Valkey\ \ 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 Valkey 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 Valkey\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\ # valkey-benchmark -n 1000000 incr foo\n# valkey-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 Valkey 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.\n#\n# Basically when the fragmentation\ \ is over a certain level (see the\n# configuration options below) Valkey 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 Valkey\n# to use the\ \ copy of Jemalloc we ship with the source code of Valkey.\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# Active\ \ defragmentation is disabled by default\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\n\ jemalloc-bg-thread yes\n\n# It is possible to pin different threads and processes\ \ of Valkey 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 Valkey threads\ \ in different\n# CPUs, but also in order to make sure that multiple Valkey 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 Valkey 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 valkey 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\n# In some cases valkey will emit warnings and even refuse to start\ \ if it detects\n# that the system is in bad state, it is possible to suppress\ \ these warnings\n# by setting the following config which takes a space delimited\ \ list of warnings\n# to suppress\n#\n# ignore-warnings ARM64-COW-BUG" kind: ConfigMap metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: valkey-cluster app.kubernetes.io/version: 8.1.3 helm.sh/chart: valkey-cluster-3.0.24 name: gitea-valkey-cluster-default namespace: infrastructure --- apiVersion: v1 data: ping_liveness_local.sh: "#!/bin/sh\nset -e\nif [ ! -z \"$VALKEY_PASSWORD\" ]; then\ \ export REDISCLI_AUTH=$VALKEY_PASSWORD; fi;\nresponse=$(\n timeout -s 15 $1\ \ \\\n valkey-cli \\\n -h localhost \\\n -p $VALKEY_PORT_NUMBER \\\n \ \ ping\n)\nif [ \"$?\" -eq \"124\" ]; then\n echo \"Timed out\"\n exit 1\n\ fi\nresponseFirstWord=$(echo $response | head -n1 | awk '{print $1;}')\nif [ \"\ $response\" != \"PONG\" ] && [ \"$responseFirstWord\" != \"LOADING\" ] && [ \"\ $responseFirstWord\" != \"MASTERDOWN\" ]; then\n echo \"$response\"\n exit 1\n\ fi" ping_readiness_local.sh: "#!/bin/sh\nset -e\n\nVALKEY_STATUS_FILE=/tmp/.valkey_cluster_check\n\ if [ ! -z \"$VALKEY_PASSWORD\" ]; then export REDISCLI_AUTH=$VALKEY_PASSWORD;\ \ fi;\nresponse=$(\n timeout -s 15 $1 \\\n valkey-cli \\\n -h localhost \\\ \n -p $VALKEY_PORT_NUMBER \\\n ping\n)\nif [ \"$?\" -eq \"124\" ]; then\n\ \ echo \"Timed out\"\n exit 1\nfi\nif [ \"$response\" != \"PONG\" ]; then\n\ \ echo \"$response\"\n exit 1\nfi\nif [ ! -f \"$VALKEY_STATUS_FILE\" ]; then\n\ \ response=$(\n timeout -s 15 $1 \\\n valkey-cli \\\n -h localhost\ \ \\\n -p $VALKEY_PORT_NUMBER \\\n CLUSTER INFO | grep cluster_state\ \ | tr -d '[:space:]'\n )\n if [ \"$?\" -eq \"124\" ]; then\n echo \"Timed\ \ out\"\n exit 1\n fi\n if [ \"$response\" != \"cluster_state:ok\" ]; then\n\ \ echo \"$response\"\n exit 1\n else\n touch \"$VALKEY_STATUS_FILE\"\ \n fi\nfi" kind: ConfigMap metadata: annotations: meta.helm.sh/release-name: gitea meta.helm.sh/release-namespace: infrastructure labels: app.kubernetes.io/instance: gitea app.kubernetes.io/managed-by: Helm app.kubernetes.io/name: valkey-cluster app.kubernetes.io/version: 8.1.3 helm.sh/chart: valkey-cluster-3.0.24 name: gitea-valkey-cluster-scripts namespace: infrastructure