Ancestors

Docker doesn’t change the relationship between a running process and its data. At the end of the day you have a process running in memory that opens, reads, writes and closes files that reside on some filesystem. What happens with the files when the process is killed instantly and what happens when it’s started afterwards and it re-reads the files doesn’t change based on where the files reside or where the process runs. You could run it in docker, in a VM, on Linux, on Unix, or Windows. You could store the files in a docker volume, you could mount them in, have them on NFS, in the end they’re available to the process via filesystem calls. In the end the effects are limited to the interactions between the process and its data.

=> More informations about this toot | More toots from avidamoeba@lemmy.ca

Written by null@slrpnk.net on 2024-08-02 at 07:16

docker stop container

Make your snapshot

docker start container

What am I missing?

=> More informations about this toot | More toots from null@slrpnk.net

Written by Avid Amoeba on 2024-08-02 at 13:58

That’s the trivial scenario that we know won’t fail - stopping the service during snapshot. The scenario that I was asking people’s opinions on is not stopping the service during snapshot and what restoring from such backup would mean.

Let me contrast the two by completing your example:

Now here’s the interesting scenario:

Notice that in the second scenario we are not stopping the container. The snapshot is taken while it’s live. This means databases and other files are open, likely actively being written to. Some files are likely only partially written. There are also likely various temporary lock files present. All of that is stored in the snapshot. When we restore from this snapshot and start the service it will see all of that. Contrast this with the trivial scenario when the service is stopped. Upon stopping it, all data is synced to disk, inflight database operations are completed or canceled, partial writes are completed or discarded, lock files are cleaned up. When we restore from such a snapshot and start the service, it will “think” it just starts from a clean stop, nothing extra to do. In the live snapshot scenario the service will have to do cleanup. For example it will have to decide what to do with existing lock files. Are they there because there’s another instance of the service is running and writing to the database or did someone kill its process before it has the chance to go through its shutdown cleanup. In one case it might have to log an error and quit. In the other it would have to remove the lock files. And so on and so forth.

=> More informations about this toot | More toots from avidamoeba@lemmy.ca

Toot

Written by null@slrpnk.net on 2024-08-02 at 15:40

Oh I see – you’re asking a hypothetical.

The simple answer is that it’s a bad idea to take snapshots of running databases because at best they could be missing info and at worst they can corrupt.

The short answer: Don’t.

=> More informations about this toot | More toots from null@slrpnk.net

Descendants

Proxy Information

Original URL: gemini://mastogem.picasoft.net/thread/112893181976731828
Status Code: Success (20)
Meta: text/gemini
Capsule Response Time: 352.427256 milliseconds
Gemini-to-HTML Time: 1.638569 milliseconds

This content has been proxied by September (ba2dc).