[Date Prev][Date Next]
Re: contextCSN values and MMR
On Aug 10, 2013, at 12:01 PM, Quanah Gibson-Mount <email@example.com> wrote:
> On Aug 10, 2013, at 11:08 AM, Michael StrÃder <firstname.lastname@example.org> 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
>>>> 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 systems).
>> 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 checkpoint.