From 7e3cc26d4b5ac7d49b889b8db6a4f19a02c30afe Mon Sep 17 00:00:00 2001 From: Amritanshu Date: Fri, 16 Oct 2026 08:44:20 +0530 Subject: [PATCH] Say what a Valkey recreate actually costs, in the handler comment 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. --- valkey/roles/valkey/handlers/main.yaml | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/valkey/roles/valkey/handlers/main.yaml b/valkey/roles/valkey/handlers/main.yaml index 3324657..0b32f7d 100644 --- a/valkey/roles/valkey/handlers/main.yaml +++ b/valkey/roles/valkey/handlers/main.yaml @@ -30,6 +30,12 @@ # 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 different from Postgres's: Valkey is a cache, so every attached app -# sees a cold cache rather than a period without its database. Correctness is -# unaffected; the first requests after the restart are simply slower. +# 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".