Value of contextCSN not persisted

["Torsten Schlabach (Tascel eG)" <tschlabach@tascel.net>]

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