Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] Write bbolt databases to two disk locations synchronously #6614

Closed
callebtc opened this issue Jun 2, 2022 · 6 comments
Closed

Comments

@callebtc
Copy link

callebtc commented Jun 2, 2022

Background

Probably the easiest way to enable much a safer backup solution for most users is to allow them to use two databases on two different physical drives that are synchronously written to (i.e. second one is a copy of the first, reading is done from the first).

@callebtc callebtc changed the title [feature request] Write bbolt databases to two disk locations simultaneously [feature request] Write bbolt databases to two disk locations synchronously Jun 2, 2022
@yyforyongyu
Copy link
Member

This is essentially building a distributed data storage, won't say it's easy. How about using etcd?

@kristapsk
Copy link

This is essentially building a distributed data storage

CLN just allows to configure two SQLite databases. Or use replication with PostgreSQL.

@guggero
Copy link
Collaborator

guggero commented Jun 2, 2022

I think SQLite offers this as a feature natively, while bbolt doesn't. So this should be built into #6570 instead and not be retro-fitted onto the Bolt database (given that etcd and PostgreSQL exists as an option too).

@Roasbeef
Copy link
Member

Roasbeef commented Jun 2, 2022

Yep, the main options today are etcd or postgres given they're already distributed databases themselves. It's possible to create a system where one mirrors the channel.db on the fly, but that can be error prone. sqlite has a native WAL mode that effectively gives this feature, as you can replicate that, though you'd need to deal w/ a data loss window, slower writes, and also a larger database as tradeoffs.

@Roasbeef
Copy link
Member

Roasbeef commented Jun 2, 2022

In terms of just a local database, your main options are various RAID options, and filesystems like zfs and btrfs that natively handle things like this a and are extremely reliable.

Closing this for now since we offer two replicated DB types, and once sqlite is added (scheduled for 0.16) users can experiment with various WAL modes (with all their tradeoffs) locally which give users various options, but ofc you'd need a proper distributed database and effectively synchronous replication to be 100% safe.

@Roasbeef Roasbeef closed this as completed Jun 2, 2022
@Roasbeef
Copy link
Member

Roasbeef commented Jun 2, 2022

Also re sqlite something like this (https://litestream.io/) could be used, but users need to be aware that there's a short period of time (I think it's 5 seconds or so, but maybe configurable), where if their node goes down, they can lose data as everything isn't fully replicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants