[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slow replication

To: Meike Stone <meike.stone@googlemail.com>, openldap-technical openldap org <openldap-technical@openldap.org>
Subject: Re: slow replication
From: Marc Patermann <hans.moser@ofd-z.niedersachsen.de>
Date: Fri, 26 Apr 2013 15:20:21 +0200
In-reply-to: <CAFNHiA8J9K9dZxu+V8eHS3XFzcZdbwmB9zF6_4eXEAi9v43ihw@mail.gmail.com>
References: <CAFNHiA_KcME3dPG7jq4=FQ7vOwhwU2_EOfO=PdupsAFccttkHA@mail.gmail.com> <alpine.SOC.2.02.1304241152580.17927@toolbox.rutgers.edu> <CAFNHiA8J9K9dZxu+V8eHS3XFzcZdbwmB9zF6_4eXEAi9v43ihw@mail.gmail.com>
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

Meike Stone schrieb (26.04.2013 14:34 Uhr):

Is it possible to simulate the present phase with ldapsearch, to look
if the provider needs so long and if, what part (entries updated or
unchanged entry ) needs so long?

look at
# man ldapsearch
for "-E" and sync=rp[/<cookie>][/<slimit>] "(LDAP Sync refreshAndPersist)"
cookie is something like "rid=${RID},csn=${CSN}

But I'm not sure, it does what you want.


Marc

Follow-Ups:
- Re: slow replication
  - From: Meike Stone <meike.stone@googlemail.com>

References:
- slow replication
  - From: Meike Stone <meike.stone@googlemail.com>
- Re: slow replication
  - From: Aaron Richton <richton@nbcs.rutgers.edu>
- Re: slow replication
  - From: Meike Stone <meike.stone@googlemail.com>

Prev by Date: Re: slow replication
Next by Date: Re: slow replication
Index(es):
- Chronological
- Thread