Hacker News Reader

Comment by djbusby | Hacker News Reader

Cool! We use this but never had too much problems with disk usage (I/o or size). But, were only using to deploy configs across multiple nodes. And we read the local copy directly!

View on HN

Presumably you'll need to either use the correct WAL file or accept some very slight data staleness during the 9.0 sync process (also the direct read trick sounds great to me where permissible - EDIT: question about how much of your warranty does that void removed because the answer's already written up here - https://rqlite.io/docs/faq/#can-i-read-the-sqlite-file-direc...).

I would -imagine- that 'slight staleness' won't matter for your use case (I'm pretty confident that for the sort of configs I'm considering rqlite for that'll be the case, at least) but it's probably worth triple checking when configs are involved.

Thanks for the question, but I don't follow it -- I don't see any data staleness if you query rqlite during snapshotting. Granted the blog post doesn't go into every single detail, so this might be hard to follow.

Can you expand a bit more on your concern? What scenario do you have in mind?

They're querying the sqlite database directly so I was thinking, possibly mistakenly, that when rqlite spawns a new WAL file to snapshot, the connection they have to said database outside of rqlite might not see the changes only in the snapshotting operation's WAL.

I could easily be imagining a problem that won't exist.

Ah yes. If you are accessing the SQLite files directly I cannot be sure what you will see during the snapshotting. I haven't tested that, since accessing the SQLite files underneath rqlite is not officially supported.

Reply on news.ycombinator.com