Ben Poliakoff wrote:
> Just noticed another thing when this issue comes up.... the entryCSN for an entry that's not replicating from the primary server to the two consumers has a
> slightly different format:
>
> Primary/provider:
>
> entryCSN: 20260715174316.844052Z#000000#001#000000
>
> Non-primary/consumer:
>
> entryCSN: 20210115230536Z#000001#00#000000
> entryCSN: 20210115230536Z#000001#00#000000
These are in an obsolete format, last used in OpenLDAP 2.3. No OpenLDAP software has produced them
in the last 20 years.
That's interesting. In our environment we have a mix of these two formats (I assume the shorter format being the obsolete one). About a fifth of our ~22k entries (4291) have the shorter format of entryCSN.
I see now that I can reliably trigger this issue: by modifying an entry with the shorter (obsolete?) form of entryCSN. When I do that the entryCSN is updated on the primary/provider slapd instance (the *updated* entryCSN is in the longer format), and the syncrepl replication process fails to sync those changes on the non-primary/consumer slapd instances. Doing an ldapdelete of the entry in question (on the primary/provider) followed by an ldapadd of the entry on the primary/provider results in the newly created entry being replicated to the two consumer slapd instances.
So it appears that perhaps I need to "fix" all of the entries with the older format of entryCSN.
My quick "fix" that I've been doing when this issue comes up has been to:
I don't love the idea of having to do this ~4k times, but can certainly do that if that's the best way forward. Is there any better/more efficient way to fix these entries with entryCSNs that are in the older format?
Ben