Dears,
I'm using 2.5.7 in a context of 4 MMR with 4 Replica and I just noticed contextCSN is no more updated for cn=config DB or other DB when I do a modification which one is well applied.
What could be the issue ?
Thx, J-L.
Dears,
I found the cause if I can tell it like this, in fact, it's only for cn=config for which there are replication settings set for the 4MMR but not for the replica, then the contextCSN of replica isn't modified when I do any kind of modification to its cn=config.
I still have a question about it, is there a way to know if cn=config is updated (in any area) for a replica which has not syncrepl accord ? like contextCSN attribute ?
I knew that entryCSN is modified for the object modified but it's object by object and I'd like to have it globaly.
Thx in advance, J-L.
--On Monday, October 25, 2021 1:29 PM +0000 bourguijl@gmail.com wrote:
Dears,
I found the cause if I can tell it like this, in fact, it's only for cn=config for which there are replication settings set for the 4MMR but not for the replica, then the contextCSN of replica isn't modified when I do any kind of modification to its cn=config.
I still have a question about it, is there a way to know if cn=config is updated (in any area) for a replica which has not syncrepl accord ? like contextCSN attribute ?
I knew that entryCSN is modified for the object modified but it's object by object and I'd like to have it globaly.
A contextCSN is only maintained on a database that is replicated. If your consumers don't also replicate cn=config, then there will not be any contextCSN on the cn=config db. One question would be, why do you have consumers at all if you're running in an MMR environment? Alternatively, if there is some need that mandates consumers, there are examples in the test suite on how to set things up so that a group of consumers share a replicated database (See test059 or test086).
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 25.10.2021 um 17:15 in
Nachricht <BA996D86ACF3015D89F3395A@[192.168.1.11]>:
‑‑On Monday, October 25, 2021 1:29 PM +0000 bourguijl@gmail.com wrote:
Dears,
I found the cause if I can tell it like this, in fact, it's only for cn=config for which there are replication settings set for the 4MMR but not for the replica, then the contextCSN of replica isn't modified when I do any kind of modification to its cn=config.
I still have a question about it, is there a way to know if cn=config is updated (in any area) for a replica which has not syncrepl accord ? like contextCSN attribute ?
I knew that entryCSN is modified for the object modified but it's object by object and I'd like to have it globaly.
A contextCSN is only maintained on a database that is replicated. If your consumers don't also replicate cn=config, then there will not be any contextCSN on the cn=config db. One question would be, why do you have consumers at all if you're running in an MMR environment? Alternatively, if there is some need that mandates consumers, there are examples in the test suite on how to set things up so that a group of consumers share a replicated database (See test059 or test086).
Hi!
The point is whether it was some historical design decision to make slapo-syncprov provide the contextCSN. It would be a rather handy modification timestamp for a database independently from syncing. My guess it that it might be rather easy to add it to the base slapd.
Also: Does contextCSN correspond to RFC 4533's syncCookie?
Regards, Ulrich
Regards, Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hello Ulrich,
I totally agree with you, it’ll help somehow db update checks in non syncrepl usage.
Brgds, J-L.
On 28 Oct 2021, at 08:47, Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Quanah Gibson-Mount quanah@symas.com schrieb am 25.10.2021 um 17:15 in
Nachricht <BA996D86ACF3015D89F3395A@[192.168.1.11]>:
‑‑On Monday, October 25, 2021 1:29 PM +0000 bourguijl@gmail.com wrote:
Dears,
I found the cause if I can tell it like this, in fact, it's only for cn=config for which there are replication settings set for the 4MMR but not for the replica, then the contextCSN of replica isn't modified when I do any kind of modification to its cn=config.
I still have a question about it, is there a way to know if cn=config is updated (in any area) for a replica which has not syncrepl accord ? like contextCSN attribute ?
I knew that entryCSN is modified for the object modified but it's object by object and I'd like to have it globaly.
A contextCSN is only maintained on a database that is replicated. If your consumers don't also replicate cn=config, then there will not be any contextCSN on the cn=config db. One question would be, why do you have consumers at all if you're running in an MMR environment? Alternatively, if there is some need that mandates consumers, there are examples in the test suite on how to set things up so that a group of consumers share a replicated database (See test059 or test086).
Hi!
The point is whether it was some historical design decision to make slapo-syncprov provide the contextCSN. It would be a rather handy modification timestamp for a database independently from syncing. My guess it that it might be rather easy to add it to the base slapd.
Also: Does contextCSN correspond to RFC 4533's syncCookie?
Regards, Ulrich
Regards, Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
bourguijl＠gmail.com -
Jean-Luc Bourguignon
-
Quanah Gibson-Mount -
Ulrich Windl