Quanah Gibson-Mount wrote:
On Aug 10, 2013, at 12:01 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
On Aug 10, 2013, at 11:08 AM, Michael Ströder michael@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 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 tothe 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).
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.
As said this is a MMR setup => slapo-syncprov is loaded on all replicated DB backends
Anythings else why contextCSN is not updated?
Ciao, Michael.