Repository navigation
If replication is down for a while, we might have to resend everything #68
Description
If replication is down for interval * keep_bookmarks, then incremental replication will be broken, and we'll have to send everything from scratch again.
There are a few ways we could address this. Minimally, we need to keep one bookmark per replication target. The bookmark would represent the last snapshot that the target has. The target would have to make sure not to delete the most recent snapshot.
It wouldn't hurt to also have a "recovery" mechanism that would figure out the most recent snapshot that the source and target have in common, and be able to continue replication from there.
Activity
problame commentedon Jun 18, 2018
That's basically what the incremental replication code is doing every time it runs.
... or rather the bookmark of the most recent snapshot. The problem that comes with that idea is basically storing state of the replication on the
source, which is something I tried to avoid because once it's there, we need to migrate it when things change.Prerequisites
I think at first, we should have multiple clients per
sourcebecause we'll need to name the client somehow, and it is imaginable that multiple clients may become desirable at some point (and it should be cheap, so why not do it. (created #76 for that)Options to store the other side's state
Per client, we'll need to store a bookmark to its newest snapshots (let's call it HEAD)/
If that's all there is, let's just use a special bookmark.
(Special bookmark requires a name though, must not be usable by users
snapshot_prefix, see #69 (comment) to get some idea of the future of prefix)Handling client renames
Clients may be renamed by editing the config and restarting the daemon ( #76 ), but we'll need a way to find the client's HEAD bookmark.
Have the user also re-name the bookmark manually?
This is where a managed database rather than a config file would make more sense...