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 Monday, July 3, 2023 2:25 PM +0000 "Windl, Ulrich" <u.windl(a)ukr.de>
wrote:
> Hi!
>
> I'm wondering: Did you examine whether some indices might help?
Those don't help with the issue being addressed in regards to accesslog
databases.
--Quanah
