Hi
Some time ago we switched our MMR config to "logsuccess FALSE" to let us record and investigate some (client-side) issues with unique constraint.
This records updates refused by unique constraint in the accesslog, so we can look into them. We have logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" in each syncrepl statement, so those failed updates don't propagate through the replication.
We noticed though that other failed updates, not due to unique constraint, such as adding an already existing object, or deleting a non-existing one, do cause a contextCSN update *on all replica's* but *not* in the provider, leading to contextCSN divergence - at least when no further updates happen on that provider. This usually remains hidden as other updates to the same provider keep increasing its contextCSN, but becomes apparant when no further updates happen on that provider (in this case because we were switching providers).
Eg. when adding an object that already exists, the provider refused the update (error 68, already exists) and logs the following to the accesslog:
dn: reqStart=20220616095229.000003Z,cn=accesslog objectClass: auditAdd reqStart: 20220616095229.000003Z reqEnd: 20220616095229.000004Z reqType: add reqSession: 1498 reqAuthzID: <...> reqDN: <some already existing object> reqResult: 68 reqMod: <...> reqMod: entryCSN:+ 20220616095229.618035Z#000000#001#000000
and its main db is not updated.
But the replica's log the following:
dn: reqStart=20220616095229.000006Z,cn=accesslog objectClass: auditModify reqStart: 20220616095229.000006Z reqEnd: 20220616095229.000007Z reqType: modify reqSession: 1 reqAuthzID: <...> reqDN: <root DN> reqResult: 0 reqMod: contextCSN:= 20220616095229.618035Z#000000#001#000000
And thus update the contextCSN of their root DN (despite no other changes to the main db) - their contextCSN is now different than the provider's.
This obviously only happens with "logsuccess FALSE", but even in that case this should not be expected behaviour; refused updates should not change anything except getting logged to the accesslog?
This is with OpenLDAP 2.5.12 (migrating from 2.4.x)
Geert