Rein Tollevik wrote:
Yes, this is a sort of multi-master configuration, but not what I
of when I hear it (and read the doc). The doc. could be clearer that
different serverID values are always required when there are multiple
master servers, even if the configuration ensures that there will never be
more than one master for any backend.
We should update the manpages with this ITS as well then.
Btw, if I have understood things correctly there cannot safely be
then one subordinate db (in a glued environment) that replicates from any
If the master has multiple DBs, and they're being separately replicated into a
single DB, that would be a problem (regardless of glue on the consumer). If
the DBs are glued on the master, then there's no problem.
My thought was that with serverID=0 reserved for the true
configuration and tool mode we could safely ignore a contextCSN with 0 in
the sid field when serverID>0 is in use (to get rid of values already
in the databases). At startup syncprov could update its own contextCSN
value with newer entryCSN values that has 0 in the sid field. Ref
ITS#5537. Slapadd'ing on more than one master without synchronizing
them between each run could still be a potential problem though..
That's not a viable solution.
The syncprov startup check is primarily to recover from unclean shutdowns.
I.e., it's looking for newer CSNs that may have been saved before syncprov got
a chance to write its final checkpoint. Ignoring values, or giving special
treatment to sid 0 isn't going to work for that purpose.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/