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