On Aug 10, 2013, at 12:01 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
On Aug 10, 2013, at 11:08 AM, Michael Ströder <michael(a)stroeder.com> 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
>>> 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
> => will try to play with this (I don't need a high write rate on those
> Ciao, Michael.
I always set the syncprov checkpoint on all servers, replicas or masters.
Correction. I load slapo-syncprov on all replicated db backends. I don't set the