|
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 |