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

[rein@OpenLDAP.org]

On Wed, 28 May 2008, Howard Chu wrote:

>> A case I have is where a consumer replicates a glue'ed database, with the
>> exception of one subordinate backend where the consumer is the master.  The
>> subordinate backend is replicated back to the master of the glue'ed 
>> database.
>> With the current code the master would send the content of the subordinate 
>> db back to its master.
>
> Understood. In fact, having multiple sources of data in a glued tree is 
> really a form of multi-master. (The separate glued branches cannot cause 
> inconsistencies with each other, but still their contextCSNs must be managed 
> individually.)

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.

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, but it is OK as long as all the subordinates replicates 
from different masters. That's why the syncrepl consumer in this case is 
used on the glue db itself, not the subordinates.  And it definitely tries 
to interfere with what goes on in the subordinates (as it should).

>> A patch that fixes this is at the referenced URL.  As I am not sure of the
>> consequences if a defaulted serverID=0 value was included in the syncCookie 
>> the
>> patch changes the internal default slap_serverID value to -1 to make it 
>> possible
>> to differentiate between a configured and defaulted serverID=0.
>
>> Btw, there are potential problems with using serverID=0, so it would be 
>> best if
>> that value was reserved for the default unconfigured case.  I.e, a default
>> serverID=0 value could be chosen be slapadd when the two-argument form of
>> serverID is used in the config, as resolving the URL needs the listener 
>> argument
>> to slapd to succeed.
>
> You mean the three-argument form? The two-argument form only allows a single 
> serverID to be configured anyway, so there is no ambiguity there. But you're 
> right, in tool mode when multiple serverIDs are configured, there's no way 
> for it to choose the right serverID. That's a problem regardless of whether 
> the default is 0 or -1 though.

Yes, I didn't count the serverID itself as an argument.

If it was clear that different serverID values are always required if 
there are more than one master server in a replication setup then it 
should be safe to always include the sid in the syncrepl cookie.  And the 
internal distinction between a configured and defaulted serverID=0 value 
this patch introduces would probably not be needed.

> For now I think this is a doc issue; we could simply recommend that slapadd 
> always be performed on the node with ID 0, and you manually change the 
> serverID config if you need to slapadd on some other node.

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

Rein