How do we manage HA with litestream? #52
-
Hello there! Thank you for your time |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
There's not currently a failover mechanism but there's an issue for hot replicas (#1) that would maintain a live copy of the database. Between that and live read replicas (#8) you could have a standby although you'd need to manage the traffic redirection. Those features will probably be in the v0.4.0 release. I would like to put together a guide for setting this up at some point. It depends on your exact infrastructure but I think it'd be useful to give folks a basic idea of how to do it generally. |
Beta Was this translation helpful? Give feedback.
-
[I'm not sure what GH Discussions etiquette is for follow-up on Q&A's; feel free to move this to a new topic, @benbjohnson] I've been thinking about this a bit in the context of k8s and litestream's current features. A non-HA web setup could look something like:
Things get more complicated if you allow the pod to migrate if its host goes down, since you could end up with multiple active dbs**. What do folks think about something like this:
Did I miss anything big? Or - probably more likely - am I overthinking things? * is there a way to detect whether the local db is even/ahead/behind the latest replicated db without restoring it first? |
Beta Was this translation helpful? Give feedback.
There's not currently a failover mechanism but there's an issue for hot replicas (#1) that would maintain a live copy of the database. Between that and live read replicas (#8) you could have a standby although you'd need to manage the traffic redirection. Those features will probably be in the v0.4.0 release.
I would like to put together a guide for setting this up at some point. It depends on your exact infrastructure but I think it'd be useful to give folks a basic idea of how to do it generally.