Re: contextCSN of subordinate syncrepl DBs
Rein Tollevik wrote:
I've been trying to figure out why syncrepl used on a backend
that is
subordinate to a glue database with the syncprov overlay should save the
contextCSN in the suffix of the glue database rather than the suffix of
the backend where syncrepl is used. But all I come up with are reasons
why this should not be the case. So, unless anyone can enlighten me as
to what I'm missing, I suggest that this be changed.
The problem with the current design is that it makes it impossible
to
reliably replicate more than one subordinate db from the same remote
server, as there are now race conditions where one of the subordinate
backends could save an updated contextCSN value that is picked up by the
other before it has finished its synchronization. An example of a
configuration where more than one subordinate db replicated from the
same server might be necessary is the central master described in my
previous posting in
http://www.openldap.org/lists/openldap-devel/200806/msg00041.html
There are only two supported modes of operation intended here. In one case,
the glued databases each have their own syncprov overlay, and replication does
not cross glue boundaries. In the other case, there is a single syncprov
overlay for the entire glued tree, and the boundaries between glued DBs are
ignored. In this config, all of the contextCSNs must be saved in the glue DB
so that the single syncprov overlay can stay informed about any underlying
changes.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/