Hi
I have tried deleting the single validate_doc function we had but it seems
it still happens the same.
This is our replication filter in case it helps:
"replication": "function(doc, request) {
if (doc[\".type\"] == \"update_log\" && doc._deleted) {
return false;
}
if (doc._id.indexOf(\"_design\") === 0) {
return false;
}
return true;
}
"
},
I have changed to info logging one of the servers.
Can you tell what to look for in the logs to find what documents fail?
My problem is not exactly to know what documents are failing but this error
which appears after some documents were copied properly and then it keeps
appearing:
*Retrying POST request to https://destination
<https://destination/>*****/_bulk_docs in XX seconds due to error
req_timedout*
Any comment will be appreciated.
On Wed, Feb 25, 2015 at 10:30 PM, max <[email protected]> wrote:
> Hi, have you tried to turn off all your validate_doc_update ? I faced the
> same probleme than you and it was just the validation function preventing
> replicated documents to be written.
> Le 25 févr. 2015 10:01, "Roger Sindreu" <[email protected]> a écrit :
>
> > Hi Riyad, all
> >
> > Thanks for the response. I am still having this issue... your explanation
> > could be reasonable, because the replication breaks in one direction but
> > not in the other one. Is this something fixed in newer versions?
> >
> > Any way to know what document is stopping? Actually the replication is
> > missing something like 40 documents, but right now I don't know which
> > documents are among the 400K documents our database has.
> >
> > On Fri, Feb 6, 2015 at 6:54 PM, Riyad Kalla <[email protected]> wrote:
> >
> > > I am polling my spotty long-term memory, but this sounds similar to an
> > > issue someone had from last year where one of his attachments had
> become
> > > corrupt and it was doing the same thing, stopping replication at the
> > exact
> > > same spot. Once the attachment was removed from the doc, replication
> was
> > > fine again.
> > >
> > > Any way to check where the replication is stopping?
> > >
> > > On Fri, Feb 6, 2015 at 1:45 AM, Roger Sindreu <[email protected]>
> > wrote:
> > >
> > > > How big they would have to be to be problematic? They are very small
> > > (like
> > > > 30mb) maximum...
> > > >
> > > > Could this be a bug?
> > > >
> > > > On Thu, Feb 5, 2015 at 10:46 PM, Giovanni P <[email protected]>
> wrote:
> > > >
> > > > > I don't know. Can it be attachments?
> > > > >
> > > > > On Thu, Feb 5, 2015 at 5:19 PM, Roger Sindreu <[email protected]
> >
> > > > wrote:
> > > > >
> > > > > > Any suggestions/ideas on that?
> > > > > >
> > > > > > Any help will be appreciated.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > On Mon, Feb 2, 2015 at 11:57 AM, Roger Sindreu <
> > [email protected]>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi everyone,
> > > > > >>
> > > > > >> Nice to be here and thanks everyone for their support to
> couchdb.
> > > > > >>
> > > > > >> We have a installation with couchdb 1.2.2 (a few gigabytes and
> > > > hundreds
> > > > > >> of thousands of documents), with 3 machines being replicated.
> > > > > >>
> > > > > >> Our issue is that the replication from one machine to the other
> > two
> > > > will
> > > > > >> never get to 100% completion, and it will stop somewhere 10-30
> > > > documents
> > > > > >> below 100% and not change from there for quite a long time.
> > > > > >>
> > > > > >> On the log of the source machine most of what I see is something
> > > like
> > > > > >> this:
> > > > > >> *Retrying POST request to https://destination
> > > > > >> <https://destination>*****/_bulk_docs in XX seconds due to
> error
> > > > > >> req_timedout*
> > > > > >>
> > > > > >> On the destination machine, we don't see anything special,
> except
> > a
> > > > very
> > > > > >> high CPU consumption.
> > > > > >>
> > > > > >> Is this a known issue or something upgrade can solve? We have
> > tried
> > > to
> > > > > >> replicate from source instead of from destination without much
> > luck.
> > > > > >>
> > > > > >> Any help will be appreciated
> > > > > >>
> > > > > >> Thank you
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > [image:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://logoworks.com/uploads/projects/166660202602/finalartwork/166660_logo_final.jpg
> > > > > ]
> > > > > >
> > > > > > [image:
> > > > > >
> > > http://www.logoworks.com/app/client/LogoworksEmailTemplate/vr_2x58.gif
> > > > ]
> > > > > >
> > > > > > Roger Sindreu
> > > > > >
> > > > > > CTO
> > > > > >
> > > > > > [email protected]
> > > > > >
> > > > > > www.getfinancing.com
> > > > > >
> > > > > > http://www.linkedin.com/in/rsindreu
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ************************************************************************************
> > > > > >
> > > > > > This e-mail is covered by the Electronic Communications Privacy
> > Act,
> > > 18
> > > > > > U.S.C. Sections 2510-2521. The information contained in this
> e-mail
> > > is
> > > > > > confidential and intended only for use of the individual or
> entity
> > > > named
> > > > > > above. If the reader of this message is not the intended
> recipient,
> > > or
> > > > > the
> > > > > > employee or agent responsible to deliver it to the intended
> > > recipient,
> > > > > you
> > > > > > are hereby notified that any dissemination, distribution or
> copying
> > > of
> > > > > this
> > > > > > communication is strictly prohibited. If you have received this
> > > message
> > > > > in
> > > > > > error or there are any problems please notify the originator
> > > > immediately.
> > > > > >
> > > > > >
> > > > > >
> > > > > > The unauthorized use, disclosure, copying or alteration of this
> > > message
> > > > > is
> > > > > > strictly forbidden. This mail and any attachments have been
> scanned
> > > for
> > > > > > viruses prior to leaving sender's company network. Neither the
> > sender
> > > > nor
> > > > > > the sender's company will be liable for direct, special, indirect
> > or
> > > > > > consequential damages arising from alteration of the contents of
> > this
> > > > > > message by a third party or as a result of any virus being passed
> > on.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > >
> >
>
