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

Re: Resync DEL



Marc Patermann wrote:
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.

In the complete absence of any config information from you, it's impossible to determine. If you have a syncprov sessionlog, then if you didn't restart the provider, it may not cause a full presence check when a consumer connects.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/