Understanding litefs for "rarely up" architecture

This approach works fine for the secondaries although you’ll probably want to keep your two primary nodes up at all times. If your primaries shut down for a while then one could lag far behind the other and then be promoted to primary. Another option is that you could use LiteFS Cloud to stream data into so that your primary always has the latest data to pull from when it comes up.

LiteFS nodes retain transaction change sets for a certain period of time (10m by default) so that nodes that disconnect can catch up without requiring a full snapshot download. If you’re going to have nodes that are offline for much longer, then you’ll want to increase the data.retention field in the litefs.yml config. You can find more info here in the docs.

As for lag, LiteFS generally starts up very quickly. It simply needs to make a call to Consul to find the current primary and then connect to it and stream changes down. Latency is largely determined by how many writes you get to your database and how long it takes for the replica to download the changes. How large is your database and how many writes per second (or per minute or per hour) does it receive?

1 Like