Compaction for the FileBackend involves restoring the DB from the
backup, up to the penultimate state, then taking a snapshot of the
restored DB, and then appending the last change to the backup. The new
backup is then atomically swapped with the old backup.
The special treatment for the last change is necessary as usual due to
the rewind functionality, otherwise we'd be in an un-rewindable state,
which can cause trouble if c-lightning died without committing the
last change.
Caching writes was causing us some issues if the startup of
`lightningd` didn't complete, i.e., the writes would happen on the
live DB, but we'd forget about them. Since we have the backup.lock
file in same directory as the plugin is running in, we no longer have
to defer the writes. This hugely simplifies our logic.
Fixes#155
Changelog-Fixed: backup: The plugin doesn't lose sync anymore if the startup is interrupted
We'll start relying solely on the `backup.lock` file generated by the
`backup-cli`. But we keep the option so we don't automatically break
all configs that simply updated.
Looking up the process parents and searching for `lightnignd` allows us to
kill directly. It also means we no longer have to wait for the RPC to be
enabled to abort.
We were writing logs directly before killing `lightningd` which resulted in
the logs being lost. The subsequent check for the log-lines then would fail
obviously.
Before this change, backup backend was initialized twice - in on_init()
and get_backend() functions. This change leaves only one call in
get_backend() and adds a kwarg determining whether init failure should
be fatal.
Signed-off-by: Michal Rostecki <mrostecki@mailfence.com>
We heavily rely on foreign key constraints to keep the DB consistent and drop
dependent objects such as UTXO set entries when we roll back a block. We also
need to enable the foreign key constraints when restoring otherwise these
dependents are not removed and we run into constraint violations.
