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