Consequences of sharing the same replication destination? #471
-
I am planning to use litestream in a project that will have multiple replias of the same down-stream database backing up SQLite with litestream. I plan on adding in leader election so that only a single replica will perform backups, but in the meantime I am curious what the consequence is of having multiple replications with the same path? I see in the docs:
But I am curious, why in particular is it not recommended? Is it just a performance factor? Or are there other considerations? Again this is just temporary, wondering if I can delay the leader election requirement until after backup is implemented, or it has to be in the same commit. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
@danthegoodman1 As long as you can guarantee that none of your databases are backing up at the same time then you're ok. But that's tricky with distributed systems—even with leases. Clocks can skew and messages can get delayed so relying on a time-based lease has its downfalls. If you need leader election & live read replicas, you can try looking at my other project called LiteFS which does all of that already. I'm working on streaming backups for that right now but you can also just perform a periodic backup using |
Beta Was this translation helpful? Give feedback.
@danthegoodman1 As long as you can guarantee that none of your databases are backing up at the same time then you're ok. But that's tricky with distributed systems—even with leases. Clocks can skew and messages can get delayed so relying on a time-based lease has its downfalls.
If you need leader election & live read replicas, you can try looking at my other project called LiteFS which does all of that already. I'm working on streaming backups for that right now but you can also just perform a periodic backup using
litefs export
.