Rein Tollevik wrote:
ServerID 0 should be reserved for single-master configurations, ref http://www.openldap.org/lists/openldap-bugs/200809/msg00131.html. But this is neither enforced in the code, nor mentioned in the doc. as far as I can see.
I guess you should file a doc ITS for that. I don't think it's been a critical issue so far since most deployments were coming from 2.3 where there was no serverID or MMR to begin with, and the docs state that a serverID is required for MMR.
Reserving serverID 0 for the single-master case would make it easier to distinguish between old single-master and new multi-master configuration based on the SID of the CSNs. But the main benefit would be to catch the apparently far too common configuration error of failing to set a correct serverID in multi master configurations. Is it OK if I implement it?
This would mean that slapd would refuse to start if syncrepl or syncprov finds a contextCSN value with SID=0 in the database upon startup and there is more than one contextCSN, or if MirrorMode is enabled. Syncrepl should refuse to receive updates to contextCSN values under the same conditions, and tear down the connection (and retry later) if one is seen.
The above check is going to be pretty annoying since there's no convenient offline tool to correct the situation. Note that the tool interface now provides a modify entry point, which is used by slapadd to update the contextCSN. If we provide a slapmodify offline tool, then this might be acceptable, but I still think it's going to be pretty annoying.
Just from a simple usage perspective, aside from adding a serverID to my config, I shouldn't have to do anything special to convert an existing single-master DB to a MM deployment.
Syncprov should also refuse slapd to start if serverID is 0 and MirrorMode is enabled
That sounds OK.
or any contextCSN with non-zero SIDs are found.
That's probably going too far.
This would require a non-zero serverID also on pure forwarding servers that never changes anything by them self.
I don't think so. If they never change anything then their SID never propagates.
But I think this minor drawback is worth it if it allows us to catch the serverID configuration errors. Syncrepl should probably allow serverID 0, so that pure consumers can exist without requiring separate serverID values.