--On Wednesday, July 5, 2023 11:17 AM +0200 cYuSeDfZfb cYuSeDfZfb
<cyusedf...@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
