Rein Tollevik wrote:

Yes, this is a sort of multi-master configuration, but not what I think 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 more then one subordinate db (in a glued environment) that replicates from any single master,

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 single-master 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.