Dqlite – High-Availability SQLite

Post by otoolep » Fri, Aug 30, 2019, 4:13 PM UTC

duiker101 wrote: post #12

hamandcheese wrote: post #7

What is the difference between this and rqlite? https://github.com/rqlite/rqlite

From the FAQ[1] The main differences from rqlite are: - Embeddable in any language that can interoperate with C - Full support for transactions - No need for statements to be deterministic (e.g. you can use time()) - Frame-based replication instead of statement-based replication [1] https://github.com/canonical/dqlite/blob/master/doc/faq.md

Post by stefan_ » Fri, Aug 30, 2019, 4:34 PM UTC

SomeOldThrow wrote: post #64

bb88 wrote: post #59

Interesting nugget about golang from their FAQ: https://github.com/canonical/dqlite/blob/master/doc/faq.md Why C? The first prototype implementation of dqlite was in Go, leveraging the hashicorp/raft implementation of the Raft algorithm. The project was later rewritten entirely in C because of performance problems due to the way Go interoperates with C: Go considers a function call into C that lasts more than ~20 mic…

I don't want to flame, but I did find it curious they went with C rather than Rust. In my experience the transition is straightforward and the string handling (particularly with unicode encodings) is way better (in addition to the normal ownership benefits), and the result (an easily linkable library exposing a C ABI) is roughly the same.

Post by ken » Fri, Aug 30, 2019, 4:38 PM UTC

crusader1099 wrote: post #4

I really like the design of this website. It's simple, information-rich, fast, and doesn't contain a ridiculous number of images or dynamic components. It's a shame that I can only say this for a select few websites these days.

Post by otoolep » Fri, Aug 30, 2019, 4:45 PM UTC

linsomniac wrote: post #74

heavenlyblue wrote: post #65

Earlier quoted context omitted.

But the main point made by the parent is entirely correct: the biggest issue isn’t that of implementing a consensus protocol: the biggest issue is the reconfiguration of the cluster, management of the dead/live nodes, addition of extra nodes for replacement, copying of the data before reconfiguration. All of that needs tooling.

Indeed. I was reading the dqlite page thinking "where is the monitoring endpoint to tell if the cluster is healthy or degraded?" Too often that seems like an afterthought if it's thought of at all. I have a teeny, tiny cluster using MySQL+galera as a multi-master cluster, but it took a while to iterate to monitoring that tells me when one node is unhealthy and getting the correct repair and restart procedures.

Post by gigatexal » Fri, Aug 30, 2019, 4:52 PM UTC

heavenlyblue wrote: post #65

linsomniac wrote: post #51

Earlier quoted context omitted.

I wouldn't paint Canonical with that generalization. It's not unheard of that they have dropped projects, but I wouldn't say it's common. But looks like their primary use is LXD, which doesn't seem to be going anywhere...

But the main point made by the parent is entirely correct: the biggest issue isn’t that of implementing a consensus protocol: the biggest issue is the reconfiguration of the cluster, management of the dead/live nodes, addition of extra nodes for replacement, copying of the data before reconfiguration. All of that needs tooling.