Howard Chu skrev:
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.
I understand that syncprov needs to be informed about changes in the subordinate DBs, and it is my intention that it shall stay that way. syncrepl on the subordinate db must continue to write through the glue database so that syncprov sees all changes, including the update to the contextCSN. It is already being specially informed about the contextCSN updates, to exclude them from replication. Syncprov must itself update the contextCSN values it manages in its own suffix when it receives these updates from syncrepl. I.e the contextCSN values would end up being stored in the suffix of both the glue and the subordinate DB. And as syncprov in some situations must advertise an older csn value (for a given sid) than syncrepl on the subordinate DBs this seems correct to do.
My suggested change would add support for the kind of configuration I have outlined, without harming the currently supported configurations. It should be a fairly simple change, so I still suggest that it is made.
Rein