[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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/