Christian Kratzer wrote:
On Mon, 12 Aug 2013, Ulrich Windl wrote:
>> 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
>> 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
> that contextCSN is updated lazily. For the latter I'm not sure.
I have had the same use case Michael is getting at in the back of me
head for some time. I would also like to verify replication status by
checking the contextCSN on all servers via an ldapsearch from a
I would expect an ldapsearch of the contextCSN to deliver a current
and valid value that should be identical over all servers.
It seems this is not the case. I will run a couple of tests to verify
this myself in my testbed of 2 mmr masters and 2 slaves.
Even worse my results with 3 MMR providers and 2 read-only consumer replicas
are sometimes not very pleasant regarding data consistency. At the moment this
test servers are running as VMs on ESX server. I will repeat my tests with
real hardware to make sure there's nothing wrong because of the virtual
Using delta-sync MMR does not make sense in my case because entries will be
completely added, modified or delete. (I have no influence on the client app