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 environment.

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.)