Hi,
On Mon, 12 Aug 2013, Michael Ströder wrote:
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.
I have a mixed hardware / virtualisation based environment available. Will check the contextCSN over there and let you know.
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.)
same here. I also like the added bonus of giving the customer a stable and easy recovery roadmap of:
- stop slapd - rm -f /var/lib/ldap/* - start slapd
The customer has a relatively small dataset so replication is a matter seconds or at least under a couple of minutes.
Greetings Christian