The changes in the Retro-Changelog (RCL) database are not guaranteed to be in order
even in case of a single server, because the incoming requests are processed
independently, and the scheduling of the worker threads – that process LDAP requests
– is driven by the thread library.
There is a much higher risk for out-of-order changes in the RCL database in case
replication is deployed (for reasons other than the above mentioned thread scheduling
issue).
Invalid Changelog Entries
The contents of the RCL database cannot be fully trusted, because RCL plugin
records the changes received by the directory server and not the changes applied to
the database by the directory server. Typically, the URP code (update reconciliation
protocol) may modify the received change and the RCL plugin may record false
changes in the RCL database.

 

Is solved it?