Christian Kratzer wrote: > On Sat, 10 Aug 2013, Michael StrÃder wrote: >> Are contextCSN values on all replicas really in sync if changes were correctly >> replicated? >> >> I've implemented a monitoring check used with normal MMR setup (OpenLDAP >> 2.4.35, own build on Debian Squeeze) which also checks the contextCSN values >> on all replicas compared by server-id. >> >> Sometimes we observe, even in isolated tests, that contextCSN values for a >> certain server-id differ for quite a while (up to hours) even though the >> changes coming from that server were definitely replicated to all other >> replicas. After a while the contextCSN values get suddenly updated. >> Unfortunately this does not always happen. >> >> Any hint is highly appreciated. > > I have always suspected that this is due to the specific setting of: > > syncprov-checkpoint <ops> <minutes> > After a write operation has succeeded, write the contextCSN to > the underlying database if <ops> write > operations or more than <minutes> time have passed since the > last checkpoint. Checkpointing is disabled > by default. Thanks for following-up. AFAICS the above directive specifys when to write the contextCSN to the DB on disk similar to checkpoint directives for DB backends. So in case of a server crashing you have a quite recent contextCSN with the server-id of this particular server. But since all replicas are up and running and I query the contextCSN values via LDAP I presume this is not relevant for my problem. Well, one never knows though... => will try to play with this (I don't need a high write rate on those systems). Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature