On Thu, Jul 09, 2026 at 03:38:28PM -0700, Ben Poliakoff wrote:
The active overlays on the db in question are: dynlist, syncprov, and unique
Here are the sanitized syncrepl configs, please let me know if there are other bits of config I can provide:
dn: olcDatabase={2}mdb [...]
Right, those should be ok with all that.
Could you provide a little more context from the log? In particular, is the entry being modified locally at the same time? When syncrepl tries to update an entry, it now attaches an assert control ensuring the entry still carries the entryCSN it did as it was trying to figure out what changes were needed. If that failed, it's because **something** updated the entry before syncrepl's change managed to land there and the assert control didn't match anymore.
We do, as a practice, force almost all write operations through a single "primary" slapd instance (slapd-a). So, in general, only syncrepl should be making any changes/updates to entries on the two non-primary slapd instances (slapd-b and slapd-c).
Sure, but a longer excerpt of the log for rid=011 might show what else happened during the session as far as the consumer was concerned.
And (but there isn't sufficient information in the logs) the retried modification (rereading the entry and checking what to do) probably succeeded. If you temporarily enable accesslog on the database and record both successful and failed operations, we might be able to see what happened in detail.
The syncrepl process seems to get hung up "every so often" (might run for several days without issue). Today I found that it had gotten "stuck" again (newer change to an entry on slapd-a that wasn't being propagated to slap-b and slapd-c). Sometimes in these cases, simply restarting slapd on the non-primary instances gets things moving again. Today, though, that didn't work, and I was only able to get replication moving again, by deleting the entry (on the primary slapd instance) that was being referenced in the logs, and then recreating it (also on the primary slapd instance).
I'll try enabling accesslog on our test cluster (to make sure I know how to do that cleanly) and then try enabling it on our test cluster.
Great, that will also help. Thanks.