Hi!
Trying to better understand the contextCSN attribute. ContextCSN is formatted like:
TIMESTAMP#COUNT#SID#MOD
My question is on the SID part: ServerID.
I have the following serverID configuration in our 4-server Multi-Master PoC setup:
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:
syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand
Now the actual question:
contextCSN displays these SID's: 001, 002, 0dd, 0de. None of which I have configured *anywhere*. Not as a SID, not as a RID, as can be seen above.
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..?
Curious :-)
Thanks!
--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
openldap-technical@openldap.org