tanshu
7e3cc26d4b
The comment claimed every attached app "sees a cold cache". That is not what happens. RDB persistence is on by default, the recreate is a graceful stop, and valkey-server writes a final dump.rdb on SIGTERM that the new container loads back off the bind mount -- so keys survive, which is the part the readme already gets right and this comment did not. What does not survive is availability for the seconds the container is down: Nextcloud keeps its PHP sessions and memcache.locking there, and Yamtrack uses it as its Celery broker, so those seconds are seconds in which logins and queued tasks are unreachable. Only a hard kill or a power loss costs changes since the last save point. That is the warning a future reader needs, and it is what the nextcloud playbook's own handler comment now points at.
42 lines
1.7 KiB
YAML
42 lines
1.7 KiB
YAML
---
|
|
# All handlers run as the connection user ({{ podman_user }}), so systemctl
|
|
# --user works without setting XDG_RUNTIME_DIR.
|
|
|
|
- name: Reload systemd user units
|
|
ansible.builtin.command: systemctl --user daemon-reload
|
|
changed_when: true
|
|
listen: Reload systemd user units
|
|
|
|
- name: Restart Valkey
|
|
ansible.builtin.systemd_service:
|
|
name: "{{ unit_name }}"
|
|
scope: user
|
|
state: restarted
|
|
daemon_reload: true
|
|
listen: Restart Valkey
|
|
|
|
# Reference implementation for service playbooks. A service that attaches its
|
|
# network with valkey/roles/attach must notify "Restart Valkey", and defines its
|
|
# own copy of this handler, e.g.:
|
|
#
|
|
# - name: Restart Valkey
|
|
# ansible.builtin.systemd_service:
|
|
# name: valkey.service
|
|
# scope: user
|
|
# state: restarted
|
|
# daemon_reload: true
|
|
# listen: Restart Valkey
|
|
#
|
|
# A new drop-in changes the generated unit, so Valkey has to be recreated to join
|
|
# the network — Quadlet has no live equivalent of `podman network connect`.
|
|
#
|
|
# The cost is lighter than Postgres's in one way and heavier in another. Lighter:
|
|
# no app is left without its data. RDB persistence is on by default, the recreate
|
|
# is a graceful stop, and valkey-server writes a final `dump.rdb` on the way down
|
|
# that the new container loads back from the bind mount, so keys survive. Heavier
|
|
# to reason about: two clients do not treat this as a pure cache — Nextcloud keeps
|
|
# its PHP sessions and `memcache.locking` here, and Yamtrack uses it as its Celery
|
|
# broker — so the seconds the container is down are seconds in which logins and
|
|
# queued tasks are unavailable. Only a hard kill or a power loss costs changes
|
|
# since the last save point. See readme.md, "The trade-off".
|