--On Thursday, July 6, 2023 3:44 PM +0200 cYuSeDfZfb cYuSeDfZfb cyusedfzfb@gmail.com wrote:
Hi Quanah,
Thanks again for your answer.
From what you have written, we understand now that we should not aim for four identical timestamps in contextCSN attributes on each node. As contextCSN is updated (as you said) only when a server receives a direct write. (and NOT for writes received through replication)
So, as long as the contextCSN output across all four MM-ldap nodes is identical, replication is doing it's thing.
Specifically, from my original post:
contextCSN: 20230622151102.137085Z#000000#001#000000 contextCSN: 20230622151105.174343Z#000000#002#000000 contextCSN: 20230627112536.529432Z#000000#0dd#000000 contextCSN: 20230627112536.529512Z#000000#0de#000000
The first two servers (001/002) are just as up-to-date as the last two, only: more recent writes have come into the cluster through the 0de/0dd servers.
I have written a script to compare actual ldap served content, and that confirms that they all serve the same data.
If any of the above is wrong, I'd appreciate to be corrected :-)
If you were using delta-syncrepl (I see from your configs you are not) you'd also need to do comparisons on the CSNs in the accesslog DB.
If you use the Symas OpenLDAP packages, there's also a nice utility called slapd-watcher that shows you the status of your servers included in their builds.
--Quanah