Replication task recover automatically last long from backup file

[guanfeix]

local-node: couchdb restore
peer-node: couchdb another master node
replication: master-to-master/push replication
i just want to trying restore my database from periodly backup of database file.The database doc seems normal,but some replication of this couchdb which from peer-node to this couchdb seems in state of retrying for long time about two hours.
And also because of this a master-master replication. some replication from this couchdb to another is also in such occasion.

Anyone knows this is normal or not, how can i decrease the wait time of retrying

Context

Your Environment

• Version used: 2.3.1
• Browser Name and version: chrome
• Operating System and version (desktop or mobile): centos7
• Link to your project:

[nickva]

The error log is showing EHOSTUNREACH [1] error. That means your routing or other network setup isn't working quite right.

[1] https://man7.org/linux/man-pages/man3/errno.3.html

Make sure you can connect from your node which runs the replication to each of the endpoints, source and target with those same connection parameters as specified in the replication job.

[guanfeix]

But some other db's replication tasks is ok,only several will show retrying state. ,it maybe the past failure.i also notice in replication documentation

Replication jobs which keep failing will be penalized and forced to wait. The wait time increases exponentially with each consecutive failure.

if the wait time is two long, but i know replication is already ok.how can it trigger the retrying immediately or decrease the wait time punishment for successive failure.like restart couchdb instance?

[nickva]

Replication jobs will back-off exponentially on repeated failures. Restarting the server is one way to reset that, the other way is to lower the max_history parameter to something like 5 or 6. That should shorten the maximum back-off period. The downside then is that lots of crashing replication will be continuously retrying, possibly taking up scheduling slots from the working ones.

[guanfeix]

@nickva today i just lookup the version of couchdb in git tags which will be my choice the latest 2.x，it seems like they didn't make release version

[nickva]

Primary release artifacts for CouchDB are at https://dlcdn.apache.org/couchdb/source/

If you want to clone it from Github can try this branch https://github.com/apache/couchdb/commits/2.3.x

[guanfeix]

thanks you i get it from offical website

[guanfeix]

@nickva i just run into some error log,when i dig some apllication question, i don't know if there will be any risk.

1.when i don't create these system db _users,_replicator, what will happens, can i use the couchdb normally.i notice the couchdb instance seems have a crush.

2. some exception occur when replicate
   

3. couchdb unknown_error normal,likes Sporadic unknown_error : normal errors #1600, i see you just fix it on 3.2.1.Any influence if we not to upgrade.
   

4. CRASH REPORT this issue was closed because of too old. ddoc_cache_remove_test ets assertion fail on Jenkins #1349 is there any explict reason or answer for this.
   

5. unknown metric tem view 410 i see some related doc incouchdb https://docs.couchdb.org/en/1.6.1/api/database/temp-views.html. is there some change for this,i didn't see any _temp_view in my application code
   

[nickva]

1. Create a _replicator db. It's not auto-created. Perhaps, if you have created it and it still shows up as missing there is an issue with your disk and sometimes it cannot be read from.

2. Same as with _users db. Make sure it's created along with _replicator. There is also a chance that your nodes (if you use multiple nodes in a cluster) where not connected properly. Check GET /_membership to make sure all nodes matches with cluster nodes

3. That should fine, it's just log noise.

4. This issue is tracked here Handle not_found lookups removing ddoc cache key #3890. You can follow that for the answer

5. Something is calling the temp view and it's returning a 410 since it's supported in 3.x any longer. Could it be from Fauxton. Can try setting up wireshark or other package capture to see what is calling that path

[guanfeix]

There is a lot of vie_function error,is there any relationship with the 5th question.