Dear list!
We found one issue with a quite simple syncrepl replication; we have one provider and just one consumer. The consumer got set up about a week ago and loaded its initial database content from the provider. Then - after a couple of days - one object got deleted on the provider. So the consumer had to perform that delete operation as well; which is what it did fine. No problem so far.
Today we compared the contextCSN values for the provider and the consumer and first thought we may have a problem, actually, because we found the contextCSN on the consumer to be newer than on the provider. Here are the actual values:
consumer
contextCSN: 20111216215531.923716Z#000000#003#000000
provider
contextCSN: 20110124140058.246484Z#000000#003#000000
Looking twice, we found out that on the provider we got the above contextCSN value (the one which is too small) using slapcat. If we ask the provider using ldapsearch it actually reports the expectec contextCSN value, i.e. the same one which we can see on the consumer. (Note: The above value on the consumer has been taken from slapcat as well.
In other words: The provider's latest contextCSN value has not been written to the disk until now; actually 4 days since the change.
I guess if the power would fail now for example, the provider would load it's context CSN from the database, reading the lower value, and thus replication would get seriously out of sync, wouldn't it.
Also we found that the result of the operation which increased the contextCSN (deleting an object on the provider) has been written to the disk, in contrast to the contextCSN value.
Is that epxected behaviour or would we need to configure the flushing to the disk?
We're using OpenLDAP 2.4.23 on Debian Linux. The backend is a back-hdb.
Regards, Torsten