couchdb
couchdb copied to clipboard
Replicator giving issue , with jobs getting into crashed type
Hi team,
i have a 3 node couch cluster deployed on kubernetes, replication is set in a way like A-B, B-A, B-C, C-B, A-C, C-A using replicator, with continuous replication enabled.
From UI, i can see no issues with replication and everything is replicated properly but when i see the logs, i am seeing following logs,
Replicator GET ****** failed due to error sel_conn_closed
![image](https://user-images.githubusercontent.com/22679369/174272070-2ecca770-396f-4dd2-8dbe-213104ae6fb9.png)
Can someone please help, with this issue? can this logs be ignored?
Also, one more thing would like to share is with scheduler/docs api, i do not see anything in the error count, its 0
It means the _changes
feed connection is closed unexpectedly. If the error count is 0, it happens rarely enough that the error count is reset. So it's probably more rare than once a minute or so.
A few things to try:
- Check if you're using a restrictive replication filter.
- Increase the replicator connection timeout configuration to say 90000(msec).
- Check if your load balancer (if you have one), has an idle connection timer then bump that too and then, check that it's not set to buffer connection data.
In general replicator will retry the replications on failure and continue where it left off. It's pretty resilient like that. So, if you don't want to track down the connection issues, and it seems your data replicates as intended you probably don't have to worry about it.
Hi @nickva
Thank you for the quick reply, i would need a further help as i am pretty new to couch
-
Where do i check this? restrictive replication filter.
-
Also can i put this connection timeout under local.d directory in any ini file?
Thanks Pallavi C
If your replication document doesn't have a filter specified then it's not a concern.
You can put the timeout in any local..d or local.ini file
https://docs.couchdb.org/en/stable/config/replicator.html#replicator/connection_timeout
Closing as there has been no activity in a while. Hopefully the suggested reply helped.