Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <F48304EF-A9BF-44E5-A3EA-AC05FCDA94C4@gmail.com>
References: <F48304EF-A9BF-44E5-A3EA-AC05FCDA94C4@gmail.com>
From: Nick Vatamaniuc <vatamane@gmail.com>
Date: Tue, 20 Jun 2017 11:20:45 -0400
Message-ID: <CAJd=5HY3jKEU2wyXDYunVD6AJT4Bime2mhPyBM8QqAQxBJVuTw@mail.gmail.com>
Subject: Re: CouchDB config: Difference between max_replication_retry_count
 and retries_per_request
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary="001a11424436ab8ded055265cb4f"
archived-at: Tue, 20 Jun 2017 15:24:02 -0000

--001a11424436ab8ded055265cb4f
Content-Type: text/plain; charset="UTF-8"

Hi Vovan,

The answer is slightly different depending if you're using 1.x/2.0 releases
or current master.

If you're using 1.x or 2.0 release: Set "max_replication_retry_count =
infinity" so it will always retry failed replications.  That setting
controls how the whole replication job restarts if there is any error. Then
"retries_per_request" can be used to handle errors for individual
replicator HTTP requests. Basically the case where a quick immediate retry
succeeds. The default value for "retries_per_request" is 10. After the
first failure, there is a 0.25 second wait. Then on next failure it doubles
to 0.5 and so on. Max wait interval is 5 minutes. But If you expect to be
offline routinely, maybe it's not worth retrying individual requests for
too long so reduce the "retries_per_request" to  6 or 7. So individual
requests would retry a few times for about 10 - 20 seconds then the whole
replication job will crash and retry.

If you're using current master, which has the new scheduling replicator: No
need to set "max_replication_retry_count", that setting is gone and all
replication jobs will always retry for as long as replication document
exists. But "retries_per_request" works the same as above. Replication
scheduler also does exponential backoffs when replication jobs fail
consecutively. First backoff is 30 seconds. Then it doubles to 1 minute, 2
minutes, and so on. Max backoff wait is about 8 hours. But if you don't
want to wait 4 hours on average for the replication to restart when network
connectivity is restored, and want to it be about 5 minutes or so, set
"max_history = 8" in the "replicator" config section. max_history controls
how much history of past events are retained for each replication job. If
there is less history of consecutive crashes, that backoff wait interval
will also be shorter.

So to summarize, for 1.x/2.0 releases:

[replicator]
max_replication_retry_count = infinity
retries_per_request = 6

For current master:

[replicator]
max_history = 8
retries_per_request = 6

Cheers,
-Nick


On Mon, Jun 19, 2017 at 11:33 PM, Vladimir Kuznetsov <vovanec@gmail.com>
wrote:

> Hi,
>
> I'm currently exploring CouchDB replication and trying to figure out the
> difference between *max_replication_retry_count* and *retries_per_request*
> configuration options in *[replicator]* section of configuration file.
>
> Basically I want to configure continuous replication of local couchdb to
> the remote instance that would never stop replication attempts, considering
> potentially continuous periods of being offline(days or even weeks). So,
> I'd like to have infinite replication attempts with maximum retry interval
> of 5 minutes or so. Can I do this? Do I need to change default
> configuration to achieve this?
>
> thanks,
> --Vovan

--001a11424436ab8ded055265cb4f--