4 ms·
Hmmmm, that's a different issue. :-) Today the rqlite code deletes the SQLite database (if present) and then rebuilds it from the Raft log. It makes things so
by otoolep 6y ago
Hmmmm, that's a different issue. :-)
Today the rqlite code deletes the SQLite database (if present) and then rebuilds it from the Raft log. It makes things so simple, and ensures the node can always recover, regardless of the prior state of the SQLite database -- basically the Raft log is the only thing that matters and that is guaranteed to be the same under each node.
The fundamental issue here is that Raft can only guarantee that the Raft log is in consensus, so rqlite can rely on that. It's always possible the one of the copies of SQLite under a single node gets a different state that all other nodes. This is because the change to the Raft log, and corresponding change to SQLite, are not atomic. Blowing away the SQLite database means a restart would fix this.
If this is important -- and what you ask sounds reasonable for the read-only case that rqlite can support -- I guess the code could rebuild the SQLite database in a temporary place, wait until that's done, and then quickly swap any existing SQLite file with the rebuilt copy. That would minimize the time the file is not present. But the file has to go away at some point.
Alternatively rqlite could open any existing SQLite file and DROP all data first. At least that way the file wouldn't disappear, but the data in the database would wink out of existence and then come back. WDYT?
- mrkurt 6y agoRebuilding and then moving it in place sounds pretty nice to me.
- e12e 6y agoThis may be hopelessly naive - but is the rebuilt sqlite db expected to be identical? Could a sha256 hash of the file be written into the raft log at intervals, and be used as a "valid" starting point? Ie: log1: empty db log2..N: changes log3: snapshot at N log4..M: changes You start with empty db, and replay up to N; or if you have a db that matches log3 - start with that and only replay log4+?
- otoolep 6y agoThat's not a bad idea, might have promise. Hashing large databases files after every few log entries might be a performance hit....not sure. Something to think about -- thanks.
- ignoramous 6y agoSnapshotting at intervals is how most point-in-time restores scale up. The db is snapshotted at a preset time (easy way: lock db for writes whilst snap is in progress, preferably on read replicas) and then restored again (preferably, elsewhere) to see if restore did indeed work as expected (and isn't corrupt). The latest log sequence number could also be stored in the same db (in a separate table) so that it is captured along with the db-snapshot, atomically.
- m_sahaf 6y ago> Today the rqlite code deletes the SQLite database (if present) and then rebuilds it from the Raft log. Neat! This is reminiscent of the replay of event log in Smalltalk.