Ulrich Windl wrote: >>>> Christian Kratzer <ck-lists@cksoft.de> schrieb am 10.08.2013 um 19:43 in > Nachricht <alpine.BSF.2.00.1308101942120.18017@pohjola.cksoft.de>: >> 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. >> >> Not sure though. > > do you "query" by slapcat or by an LDAP search? For the former it's documented > that contextCSN is updated lazily. For the latter I'm not sure. Using slapcat in a monitoring check invoked every minute would be pretty dumb. So of course I'm retrieving the contextCSN values from replicated DBs via LDAP. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature