Conversation
| bottomless::replicator::RestoreAction::SnapshotMainDbFile => { | ||
| replicator.new_generation().await; | ||
| if let Some(_handle) = replicator.snapshot_main_db_file().await? { | ||
| if let Some(_handle) = replicator.snapshot_main_db_file(true).await? { |
There was a problem hiding this comment.
If we don't want to force snapshot generation after db restore, this should be changed to false.
There was a problem hiding this comment.
What is the benefit in creating a snapshot right after we restored from backup?
There was a problem hiding this comment.
I'd say it's mostly related to forking, as I haven't tested if we don't get data loss if we won't snapshot after forking.
There was a problem hiding this comment.
We should probably snapshot explicitly after forking though, and not after other kind of restores
| if self.get_dependency(&generation).await?.is_some() { | ||
| // empty generation and empty local state, but we have a dependency | ||
| // to previous generation: restore required | ||
| return Ok(None); |
There was a problem hiding this comment.
This is fairly important and could be counted as a bug fix on its own. It doesn't happen atm. (probably), but in general it could potentially cause DB to restore to empty state if we didn't manage to snapshot DB and WAL log was not present in current generation.
f3947f3 to
c9a218a
Compare
c9a218a to
dbc1dd5
Compare
Build on top of #1237
This PR enables setting up (through
export LIBSQL_BOTTOMLESS_SKIP_SNAPSHOT=true) ability to skip snapshot generation when a checkpoint is being made. It still may happen if machine ie. recovered from backup after process restart (however it's just a matter of callingsnapshot_main_db_file(force)).This feature could work together with #1229 - backup WAL without snapshots on sqld server and periodically call snapshot creation from bottomless-cli on separate process.