On Aug 10, 2013, at 11:08 AM, Michael Ströder <[email protected]> wrote:
> 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. > I always set the syncprov checkpoint on all servers, replicas or masters. --Quanah
