Expected behavior with two sources and one replica?

[simon-weber]

I run a variety of small webapps that use sqlite. I've been thinking about moving them to k8s and litestream looks like a good fit for backups and restoring the db across hosts (eg if a pod moves to a new node).

One thing I'm curious about is what would happen if two different copies of the same db are replicated to the same destination (maybe due to a network partition or me screwing up some config). I think this is what's discussed here:

This approach also has the benefit that two servers that accidentally share the same replica destination will not overwrite each other’s data. However, note that it is not recommended to replicate two databases to the same exact replica path.

My read of this is that there shouldn't be data loss, but you'd end up with diverging generations, right? And once I shut down the extra copy of the app, I should be able to restore normally after another litestream checkpoint (or if I manually pick the right generation)?

[benbjohnson]

That's basically correct. If you had Litestream running on two servers and both were replicating to s3://mybkt/my.db then each server would generate a random generation name on initialization. They're 16-character hex values so you might have 58fb2264a74af21f on one server and 1425566ccde1b8d8 on the other. They would get replicated to mybkt under paths like:

my.db/
	generations/
		58fb2264a74af21f/
			snapshots/
			wal/
		1425566ccde1b8d8/
			snapshots/
			wal/

Retention will remove snapshots & WAL files that exceed the retention time (24h by default). There could be some weird interaction currently because there's only one snapshot per generation at a time right now but snapshot interval (#3) should fix that.

That all being said, I wouldn't suggest running two servers that replicate against the same replication URL. :)