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.
This commit is contained in:
1 parent
43ea43e88b
commit
7e3cc26d4b
1 file changed
+9
-3
@@ -30,6 +30,12 @@
|
|||||||
# A new drop-in changes the generated unit, so Valkey has to be recreated to join
|
# 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 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
|
# The cost is lighter than Postgres's in one way and heavier in another. Lighter:
|
||||||
# sees a cold cache rather than a period without its database. Correctness is
|
# no app is left without its data. RDB persistence is on by default, the recreate
|
||||||
# unaffected; the first requests after the restart are simply slower.
|
# 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".
|
||||||
Reference in new issue
Block a user