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 :-)


On Wed, 5 Jul 2023 at 17:09, Quanah Gibson-Mount <quanah@fast-mail.org> wrote:


--On Wednesday, July 5, 2023 11:17 AM +0200 cYuSeDfZfb cYuSeDfZfb
<cyusedfzfb@gmail.com> wrote:

> serverID 222 ldaps://ldapm01.company.com
> serverID 221 ldaps://ldapm02.company.com
> serverID 212 ldaps://ldapm03.company.com
> serverID 211 ldaps://ldapm04.company.com
>
> And when I (quick and dirty) check contextCSN using slapcat (I know that
> ldapsearch is the better way) I get:
>
> [root@ldapm04 ~]# slapcat | grep contextcsn -i
> contextCSN: 20180917142109.765066Z#000000#000#000000
> 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 2018 contextCSN is irrelevant (it has alwas been there, and I
> should probably try to get rid of it) but the last four seem to be the
> "actual" configured replication 'lines' on each node to the other three,
> like this:
>
>
> Yet: all info I can find tells me that the third field of contextCSN is
> "the SID".
>
>
> Can anyone explain? Are they perhaps HEX? If why the large gap between to
> consequtive pairs..?


Hi!

So #000# is as you noted an old SID from when the system used single
provider.

The SID values are indeed in hex.  Your current non-zero SIDS indicate:

You have servers with SID values 001, 002 that last received a direct write
operation on 2023/06/22, about 3 seconds apart.

You have servers with SID values 221 (0dd) and 222 (0de) that last received
a direct write operation on 2023/06/27, during the same second.

Any server that has a different SID value that has never received a direct
write operation will not appear in the list.

Regards,
Quanah