LiteFS GET request containing writes + LiteFS with multiple processes

, ,
7

Ok, so I’m back into this topic again after a couple of days of no time.

I’m going to try out the fly-replay approach, to learn and also to avoid the extra roundtrip to the client. I’ll tackle the read-your-writes consistency whenever that comes up.

The first issue I’m encountering (haven’t tried yet, just by looking at docs and the code I’ve written thus far) is that the contents of the /litefs/.primary file doesn’t seem to correspond with the instance=<id> of the Fly-Replay header that you mentioned. It gives you the hostname instead, as documented here. How can I use that?

In addition, I’m struggling to understand the processes and mounts sections of the Fly configuration. With a configuration like the following (combining mounts with what you’ve laid out for me):

[mounts]
  source = 'litefs'
  destination = '/var/lib/litefs'
  processes = ["backend", "worker"]

[processes]
  backend = ""  # use litefs.yml's exec.
  worker  = "-- npm run worker:start"

How can I actually refer to the "backend" process here inside of the [mounts] section? Since it’s now run by the litefs exec? And in addition, will these actually mount the same volume? Related discussion over at Mounts per process group for Apps v2 - #8 by natejonesrisekit

I’m also realising that if I replicate my application this way, then the read replica worker can’t write either, which it needs to do. So maybe I’d be better off running the worker process together with the primary backend node, and when replicating, that’ll only be the backend/api, since that’s what’s needed to be closer to the users. Then again, LiteFS will promote/demote a machine as primary depending on various factors, so how would I handle that situation? Fly-Replay wouldn’t work as the worker logic is not based off of an incoming request.

Maybe I can use hivemind or some other supervisor as described here, which will run everything inside of one single process. That way I can mount one volume and have it accessible from both the backend and worker processes. I still wouldn’t be able to put another node somewhere else in the world, as the worker would still try to write on the non-primary nodes…

I feel like I’m digging my own grave trying to figure this out. Postgres was easier :smiley:

Any ideas?