Hi, my problem is this:

Whenever I restart a Consumer in our single-provider, multi-consumer syncrepl 
setup, type=refreshAndPersist (OpenLdap 2.4.45), It spends about half an hour 
running through the whole DIT (about 5.5 million entries), doing this for each:

2018-09-12T16:25:41.526574+02:00 nonpresent_callback: rid=001 present UUID 
9b99ec5a-4cfe-1029-9a2e-80309636f032, dn ou=Authentication,o=UNI-C,c=DK

I'm guessing that that the Consumer is looking up every entry to decide if it 
has changed.  This has the unfortunate effect that the Consumer is deemed 
out-of-sync in the timespan (referring to the contextCSN in the root entry), 
even if only one entry has actually changed in the master. And it cannot be let 
back into the serverfarm before it is synchronized, thus making every restart 
of a Consumer require at least 30 mins downtime for that Consumer.

If I read the docs correctly 
(https://www.openldap.org/doc/admin24/replication.html), there should be a 
synchronization cookie set after the  refresh stage (and during the 
persist-stage). It looks to me like at least in my case, that cookie is not 
persistent - it seems that when the Consumer is restarted, this cookie is 
either lost or reset, causing the whole DIT to be read, and not just those 
entries, younger than the cookie.

But why is it not persistent? Am a missing some obvious explanation as to why 
this is not possible, or have I just misconfigured something? Any hints where I 
should look?
Is there a better way to set up replication to avoid this?

Thanks - Ole N Thomsen

Reply via email to