Snarf/homelab-gitops
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
9525cdbe95075e942f59224d46b80e183d6e389f
homelab-gitops/manifests/spaceport/gitea/gitea.yaml

2232 lines
140 KiB
YAML
Raw Blame History

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 <dbid> 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 <seconds> <changes> [<seconds> <changes> ...]\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\
\ <primaryip> <primaryport>\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\
\ <primary-password>\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 <username>\n\
#\n# When primaryuser is specified, the replica will authenticate against its\n\
# primary using the new AUTH form: AUTH <username> <password>.\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 <primary>' 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 <username> ... acl rules ...\n#\n# For example:\n#\n# user worker\
\ +@list +@connection ~jobs:* on >ffa9203c493aa99\n#\n# The special username \"\
default\" is used for new connections. If this user\n# has the \"nopass\" rule,\
\ then new connections will be immediately authenticated\n# as the \"default\"\
\ user without the need of any password provided via the\n# AUTH command. Otherwise\
\ if the \"default\" user is not flagged with \"nopass\"\n# the connections will\
\ start in not authenticated state, and will require\n# AUTH (or the HELLO command\
\ AUTH option) in order to be authenticated and\n# start to work.\n#\n# The ACL\
\ rules that describe what 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\
# +<command> Allow the execution of that command.\n# May be used\
\ with `|` for allowing subcommands (e.g \"+config|get\")\n# -<command> Disallow\
\ the execution of that command.\n# May be used with `|` for blocking\
\ subcommands (e.g \"-config|set\")\n# +@<category> Allow the execution of all\
\ the commands in such category\n# with valid categories are like\
\ @admin, @set, @sortedset, ...\n# and so forth, see the full list\
\ in the server.c file where\n# the 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# +<command>|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# ~<pattern> Add a pattern of keys that can be mentioned as part\
\ of\n# commands. For instance ~* allows all the keys. The pattern\n\
# is a glob-style pattern like the one of KEYS.\n# \
\ It is possible to specify multiple patterns.\n# %R~<pattern> Add key read\
\ pattern that specifies which keys can be read\n# from.\n# %W~<pattern>\
\ 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# &<pattern> 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# ><password>\
\ 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# <<password> Remove this\
\ password from the list of valid passwords.\n# nopass All the set passwords\
\ of the user are removed, and the user\n# is flagged as requiring\
\ no password: it means that every\n# password will work against\
\ this user. If this directive is\n# used for the default user,\
\ every new connection will be\n# immediately authenticated with\
\ the default user without\n# any explicit AUTH command required.\
\ Note that the \"resetpass\"\n# directive will clear this condition.\n\
# resetpass Flush the list of allowed passwords. Moreover removes the\n# \
\ \"nopass\" status. After \"resetpass\" the user has no associated\n\
# passwords and there is no way to authenticate without adding\n\
# some password (or setting it as \"nopass\" later).\n# reset \
\ Performs the following actions: resetpass, resetkeys, off,\n# \
\ -@all. The user returns to the same state it has immediately\n# \
\ after its creation.\n# (<options>) 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 <password>\
\ as usually, or more \n# explicitly with AUTH default <password> 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 <bytes>\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 <milliseconds>\"\
\ 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@<db>__ prefix.\n# E Keyevent\
\ events, published with __keyevent@<db>__ prefix.\n# g Generic commands\
\ (non-type specific) like DEL, EXPIRE, RENAME, ...\n# $ String commands\n\
# l List commands\n# s Set commands\n# h Hash commands\n# z \
\ Sorted set commands\n# x Expired events (events generated every time\
\ a key expires)\n# e Evicted events (events generated when a key is evicted\
\ for maxmemory)\n# 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 <class> <hard limit> <soft limit> <soft seconds>\n\
#\n# A client is immediately disconnected once the hard limit is reached, or if\n\
# the soft limit is reached and remains reached for the specified number of\n\
# seconds (continuously).\n# So for instance if the hard limit is 32 megabytes\
\ and the soft limit is\n# 16 megabytes / 10 seconds, the client will get disconnected\
\ immediately\n# if the size of the output buffers reach 32 megabytes, but will\
\ also get\n# disconnected if the client reaches 16 megabytes and continuously\
\ overcomes\n# the limit for 10 seconds.\n#\n# By default normal clients are not\
\ limited because they don't receive data\n# without asking (in a push way), but\
\ just after a request, so only\n# asynchronous clients may create a scenario\
\ where data is requested faster\n# than it can read.\n#\n# Instead there is a\
\ default limit for pubsub and replica clients, since\n# subscribers and replicas\
\ receive data in a push fashion.\n#\n# 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
Reference in New Issue View Git Blame Copy Permalink