4 ms·

https://dqlite.io/ https://dqlite.io/ High-availability SQLite

by based2 5y ago

benbjohnson 5y ago
dqlite and rqlite are both great projects but target different use cases. Those run Raft consensus which requires at least 3 nodes for HA whereas Litestream is meant to run on a single node and trades off with lower durability guarantees.
- atat7024 5y ago
  Could you elaborate on the durability? Would a multi tenant SaaS with databases on the much smaller size compared to what you all talk about do well to use this, with proper backups?
  - benbjohnson 5y ago
    Litestream flushes out changes to S3 on an interval. By default, it’s every 10 seconds although you could reasonably drop that down to 1 second. You could go lower if you’re replicating to NFS. That interval determines your window for data loss in the event of a catastrophic failure (e.g. disk failure). I’ve run multiple DigitalOcean machines for years and have never had a catastrophic failure so they are rare events but they can happen. Dqlite and rqlite run every write through a distributed consensus algorithm which guarantees that your writes are persisted across at least a majority of nodes in your cluster before returning a success. In that situation, you’d need a catastrophic failure on a majority of nodes to lose data, however, there is generally a large performance trade off when running distributed consensus.
- beagle3 5y ago
  Is it possible to use dqlite/rqlite for high availability in the same datacenter, while shipping logs using litestream to a different data center for diaster recovery? Or are they incompatible? p.s. Thanks for litestream!
  - otoolep 5y ago
    rqlite author here. https://github.com/rqlite/rqlite/ https://github.com/rqlite/rqlite/ Yes, there is no reason why that wouldn't work. rqlite supports on-disk mode so you could run litestream alongside an rqlite node and backup the underlying SQLite database to your favourite cloud provider using litestream. The only downside is that rqlite performance is very sensitive to the number of writes to disk, and that's why rqlite uses an in-memory SQLite database by default, and lets the Raft log persist to disk. In exchange you can be sure that your writes are persisted to disk when the API acks your request. Perhaps if rqlite used a RAM-based filesystem for everything, and you combined it with litestream you could get much higher-performance from rqlite, with backup (with only a tiny window for data loss) if you use litestream. It's not entirely trivial, however, due the difference in data consistency models. For example, which SQLite database should be updated if the Leader in the cluster changes? It gets complicated. Ben has written a great program here. I wish I had his ideas! It's got me thinking. :-)

https://dqlite.io/ https://dqlite.io/ High-availability SQLite

by based2 5y ago

https://dqlite.io/ https://dqlite.io/ High-availability SQLite

dqlite and rqlite are both great projects but target different use cases. Those run Raft consensus which requires at least 3 nodes for HA whereas Litestream is meant to run on a single node and trades off with lower durability guarantees.

atat7024 5y ago
Could you elaborate on the durability? Would a multi tenant SaaS with databases on the much smaller size compared to what you all talk about do well to use this, with proper backups?
- benbjohnson 5y ago
  Litestream flushes out changes to S3 on an interval. By default, it’s every 10 seconds although you could reasonably drop that down to 1 second. You could go lower if you’re replicating to NFS. That interval determines your window for data loss in the event of a catastrophic failure (e.g. disk failure). I’ve run multiple DigitalOcean machines for years and have never had a catastrophic failure so they are rare events but they can happen. Dqlite and rqlite run every write through a distributed consensus algorithm which guarantees that your writes are persisted across at least a majority of nodes in your cluster before returning a success. In that situation, you’d need a catastrophic failure on a majority of nodes to lose data, however, there is generally a large performance trade off when running distributed consensus.
beagle3 5y ago
Is it possible to use dqlite/rqlite for high availability in the same datacenter, while shipping logs using litestream to a different data center for diaster recovery? Or are they incompatible? p.s. Thanks for litestream!
- otoolep 5y ago
  rqlite author here. https://github.com/rqlite/rqlite/ https://github.com/rqlite/rqlite/ Yes, there is no reason why that wouldn't work. rqlite supports on-disk mode so you could run litestream alongside an rqlite node and backup the underlying SQLite database to your favourite cloud provider using litestream. The only downside is that rqlite performance is very sensitive to the number of writes to disk, and that's why rqlite uses an in-memory SQLite database by default, and lets the Raft log persist to disk. In exchange you can be sure that your writes are persisted to disk when the API acks your request. Perhaps if rqlite used a RAM-based filesystem for everything, and you combined it with litestream you could get much higher-performance from rqlite, with backup (with only a tiny window for data loss) if you use litestream. It's not entirely trivial, however, due the difference in data consistency models. For example, which SQLite database should be updated if the Leader in the cluster changes? It gets complicated. Ben has written a great program here. I wish I had his ideas! It's got me thinking. :-)