Hi Matthieu, Thanks for reaching out.
You can always delete and re-create the replication documents. If you want it to happen automatically quicker you can: 1. Reduce the max history of the replicator jobs https://docs.couchdb.org/en/stable/config/replicator.html#replicator/max_history. You can dial it down to 5 - 8 or so. That will limit the maximum backoff time. 2. Try changing the scheduler interval: https://docs.couchdb.org/en/stable/config/replicator.html#replicator/interval to say 10000 (10 seconds). 3. If the network interruptions are short (a few seconds) could try increasing https://docs.couchdb.org/en/stable/config/replicator.html#replicator/retries_per_request a bit. That would avoid the whole replication job failing and as we'd be retrying individual requests for a bit longer. 4. If it's not just tests and these kinds of interruptions happen in production, you could try decreasing the checkpoint interval, so when jobs restart, they would re-do a bit less work. https://docs.couchdb.org/en/stable/config/replicator.html#replicator/checkpoint_interval But we have received requests like these in the past so it might work implementing a specific _scheduler API for resetting all failing jobs. (A post to _scheduler/rescan?) Cheers, -Nick On Thu, Jun 20, 2024 at 12:40 PM Matthieu Rakotojaona < matthieu.rakotojaona-rainimangav...@imt-atlantique.fr> wrote: > Hey there, > > I'm using couchdb's replication protocol for replicating data between > nodes, and I'd love to have some details about it. > > I'm doing a bi-directional push replication from A to B and B to A. > Sometimes the link comes down in both directions and comes back up: > > - when the link comes down the replicator seems to be retrying > continuously but with an exponential back-off, so it's kinda sleeping > until the next tick. Is that correct ? > > - when the link comes back up again and A can send to B, can B use that > information to try to send to A now instead of waiting for the next tick ? > > - is there a way, as an admin, to tell A or B "try to sync now" instead > of waiting for the next tick ? > > > My idea is that for my tests I actually control whether links are up or > down, so I'd like to nudge couchdb into syncing when I know it can > instead of waiting > > --- > > Matthieu Rakotojaona > >
