Follow-up, some progress. Using our o=company,c=com rootDN I do get some replication info, but only two lines of them, and not the four that seem to be the current *actual* configured RIDs.
The four (current) contextCSN's are displayed with slapcat and ldapsearch: dn: o=company,c=com contextCSN: 20180917142109.725361Z#000000#000#000000 contextCSN: 20230622022112.071635Z#000000#001#000000 contextCSN: 20230622151105.174343Z#000000#002#000000 contextCSN: 20230706131809.608140Z#000000#0d3#000000 contextCSN: 20230706131825.932137Z#000000#0d4#000000 contextCSN: 20230707083130.119957Z#000000#0dd#000000 contextCSN: 20230706132303.902949Z#000000#0de#000000 Tips? On Fri, 7 Jul 2023 at 10:19, cYuSeDfZfb cYuSeDfZfb <cyusedf...@gmail.com> wrote: > Follow-up question on slapd-watcher. > > In a youtube video (https://www.youtube.com/watch?v=rYW2jQnS_PM) I can > see that slapd-watcher can display contextCSN replication info, real time > as it happens, but I'm not getting that info. > > Starting it like: > > slapd-watcher -i 1 \ > -b o=company,c=com \ > -D cn=monitoring,cn=Monitor \ > -w abc...xyz \ > ldaps://ldap01.company.com \ > ldaps://ldap02.company.com \ > ldaps://ldap03.company.com \ > ldaps://ldap04.company.com \ > > I also tried adding "-s 222 221 212 211" (and also (learning from this > list) :-) in HEX format) but it only gives: "Number of sids doesn't equal > number of server URLs" > (same result with four separate -s options) (for the record: the number > of SIDs DID match the number of server URLs: four) > > This is openldap 2.5, symas packages, RHEL9, in a 4-host multimaster setup > > Can anyone explain what is required to also get the real-time replication > info? > > (in the youtube video I see the command is issued even more basic, with > just -b -i and 4 server URI) > > And should I file an issue on the "Number of sids doesn't equal number of > server URLs"? (as the number DID match) > > On Thu, 6 Jul 2023 at 22:17, sacawulu <cyusedf...@gmail.com> wrote: > >> Hi Quanah! >> >> Did NOT know that tool! >> >> Thanks again! Great info. >> >> MJ >> >> Op 06-07-2023 om 22:06 schreef Quanah Gibson-Mount: >> > >> > >> > --On Thursday, July 6, 2023 3:44 PM +0200 cYuSeDfZfb cYuSeDfZfb >> > <cyusedf...@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 >> > >> > >> > >> >
