Live data from Hacker News

LiteFS a FUSE-based file system for replicating SQLite

github.com

11–20 of 66 posts

Re: LiteFS a FUSE-based file system for replicating SQLite

#11
Db sharding and replication is a fascinating subject and a matter of deep interest to me.

Ben and Matt - appreciate your contributions in this area. I'm interested in making contributions along with you. Please let me know if you are looking for help. Much Thanks.

Re: LiteFS a FUSE-based file system for replicating SQLite

#12
post #9

Earlier quoted context omitted.

Very cool. I've been working on CRDTs for SQLite to allow for conflict-free replication. Its still super early but I have a prototype that works and, if you're up to it, I would love to pick your brain on the details of sqlite WALs and journaling. https://www.loom.com/share/0934f93364d340e0ba658146a974edb4

Right on, I always thought a CRDT SQLite database would be awesome. I thought about looking at the session extension[1] to handle the merges but I didn't get very far into it. Feel free to ping me at benbjohnson@yahoo.com if you want to chat WAL & journaling. I think it'd be difficult to implement CRDT at the journal level since it's all physical pages. Merging data in pages is going to sometimes cause splits and tha…

that was my assumption but it's been suggested a few times to implement it there. Nice to hear some validation that that isn't a great spot.

Re: LiteFS a FUSE-based file system for replicating SQLite

#13
I have an adjacent problem, and I haven't been able to find anyone who has a fix for me.

One perfectly reasonable use case for a read replica of a database is a bastion server. Database + web server on a machine that is firewalled both from the internet and from the business network. With read only access there is a much smaller blast radius if someone manages to compromise the machine.

The problem is that every single replication implementation I've seen expects the replicas to phone home to the master copy, not for the master copy to know of the replicas and stream updates to them. This means that your bastion machine needs to be able to reach into your LAN, which defeats half the point.

The most important question is, "what options exist to support this?" but I think the bigger question is why do we treat replicas as if they are full peers of the system of record when so often not only are they not - mechanically or philosophically - and in some cases couldn't be even if we wanted to? (eg, a database without multi-master support).

Re: LiteFS a FUSE-based file system for replicating SQLite

#14
post #13

I have an adjacent problem, and I haven't been able to find anyone who has a fix for me. One perfectly reasonable use case for a read replica of a database is a bastion server. Database + web server on a machine that is firewalled both from the internet and from the business network. With read only access there is a much smaller blast radius if someone manages to compromise the machine. The problem is that every sing…

> a database without multi-master support

I believe Cassandra does not have a Master\follower architecture; it's following a ring based structure.

Re: LiteFS a FUSE-based file system for replicating SQLite

#15
post #13

I have an adjacent problem, and I haven't been able to find anyone who has a fix for me. One perfectly reasonable use case for a read replica of a database is a bastion server. Database + web server on a machine that is firewalled both from the internet and from the business network. With read only access there is a much smaller blast radius if someone manages to compromise the machine. The problem is that every sing…

> The problem is that every single replication implementation I've seen expects the replicas to phone home to the master copy, not for the master copy to know of the replicas and stream updates to them. This means that your bastion machine needs to be able to reach into your LAN, which defeats half the point.

You can set up a PostgreSQL replica to be driven purely off of archive logs. It does not need direct access to the source database as it can pull the archive files via read only to a third location (e.g. file server or S3) that gets pushed by the source database server. The catch is that it will only be updated when an WAL file is pushed which can be driven either by size (automatically on an "active" database) or time (every N seconds or minutes). If you're fine with potentially being a minute behind the source, you can easily set this up.

Re: LiteFS a FUSE-based file system for replicating SQLite

#16

LiteFS author here (also Litestream author). I'm happy to answer any questions folks have about how it works or what's on the roadmap.

Why a fuse filesystem instead of just using sqlite's vfs features? FUSE adds an extra user-kernel-user context switch which is expensive compared to a quick user-user call for the vfs drivers.

Re: LiteFS a FUSE-based file system for replicating SQLite

#17

LiteFS author here (also Litestream author). I'm happy to answer any questions folks have about how it works or what's on the roadmap.

Does LiteFS needs to do "pattern matching" to know what SQLite writes (a txn or not e.g.)? With Litestream, it seems simply use SQLite API. Just curious how do you think through this.

Re: LiteFS a FUSE-based file system for replicating SQLite

#18
post #13

I have an adjacent problem, and I haven't been able to find anyone who has a fix for me. One perfectly reasonable use case for a read replica of a database is a bastion server. Database + web server on a machine that is firewalled both from the internet and from the business network. With read only access there is a much smaller blast radius if someone manages to compromise the machine. The problem is that every sing…

Try litestream I think it’s a push system.

Re: LiteFS a FUSE-based file system for replicating SQLite

#19
post #13

I have an adjacent problem, and I haven't been able to find anyone who has a fix for me. One perfectly reasonable use case for a read replica of a database is a bastion server. Database + web server on a machine that is firewalled both from the internet and from the business network. With read only access there is a much smaller blast radius if someone manages to compromise the machine. The problem is that every sing…

That's an interesting idea. I had plans to introduce "candidates" [1] (e.g. nodes that could become the primary) but I like the idea of reversing the communication and connecting from primary to replica. I added an issue to the LiteFS project to track it. Thanks!

[1] https://github.com/superfly/litefs/issues/16

[2] https://github.com/superfly/litefs/issues/24

Re: LiteFS a FUSE-based file system for replicating SQLite

#20

Db sharding and replication is a fascinating subject and a matter of deep interest to me. Ben and Matt - appreciate your contributions in this area. I'm interested in making contributions along with you. Please let me know if you are looking for help. Much Thanks.

Thanks! I think sharding is really interesting -- especially with a lightweight database like SQLite. I'm not looking for contributions right now but I would love to hear any feedback on the approach taken with LiteFS. I want to make it as easy to run as possible.
Post reply on HN