Re: Resync DEL

[Marc Patermann <hans.moser@ofd-z.niedersachsen.de>]

Howard Chu schrieb (24.02.2012 11:09 Uhr):
> Marc Patermann wrote:
> > Aaron Richton schrieb (23.02.2012 15:10 Uhr):
> > > On Thu, 23 Feb 2012, Marc Patermann wrote:
> > >
> > > > The data set differs in a few entries which DEL were not replicated.
> > > >
> > > > I tried (with various combinations of 2.4.26, 2.4.28 and current pre
> > > > 2.4.30) to start the consumer with "-c rid=xxx,csn=" which starts a
> > > > full sync, but the (on the master not existing) objects don't get
> > > > deleted (on the slave).
> > >
> > > Yeah, it's an impossible condition so it's not handled the best...
> > There is - however - a state where the consumer checks every entry for
> > existence:
> >
> > "slapd[23595]: nonpresent_callback: rid=402 present UUID
> > a79a831e-f18b-1030-9aca-21c3336314b4, dn ..."
> >
> > After this the consumer is exactly like the provider and all previous
> > changes and DEL and synced.
> >
> > But I'm not sure to always ensure how to achieve this state.
> >
> > I deleted the database and put current master data in the provider and
> > two day old slave data in the consumer. I started the provider and the
> > consumer.
> > This worked two times today, but later I was not able to reproduce it in
> > all cases. This is a bit frustrating. :(
> >
> > Is there any rock solid practice to get the consumer in the "check
> > present" state?
>
> Read RFC4533, there's no reason to take stabs in the dark.
I'm sure slapd respects all this. :)

In parts of my test I made a mistake by providing a cookie
(damn /etc/sysconfig/openldap).
With this sorted out, this is what I get (both pre 2.4.30 code):

- slapadd the provider with current data
- slapadd the consumer with older data
-> present check, exact sync
- ldap changes on provider
- reset and slapadd the consumer with older data
-> no present check, servers not in sync
	only changes made after the last provider start are synced
- reset and slapadd the consumer with older data and
  restart provider
-> present check, exact sync

I then checked against 2.4.26 on the provider and the behavior changed:

- slapadd the provider with current data
- slapadd the consumer with older data
-> present check, exact sync
- ldap changes on provider
- reset and slapadd the consumer with older data
-> present check, exact sync

Is this the way it is supposed to happen?
I think this is a bug in current code.


Marc