[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Antw: Re: contextCSN values and MMR

Christian Kratzer wrote:
> On Mon, 12 Aug 2013, Ulrich Windl wrote:
> <snipp/>
>>> 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.
>>> Not sure though.
>> do you "query" by slapcat or by an LDAP search? For the former it's documented
>> 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
> monitoring script.
> 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
writing there.)

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature