Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie

[hyc@symas.com]

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/