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.
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.
Syncprov should also refuse slapd to start if serverID is 0 and MirrorMode is enabled or any contextCSN with non-zero SIDs are found. This would require a non-zero serverID also on pure forwarding servers that never changes anything by them self. 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.
Comments?
Rein
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.
----- "Howard Chu" hyc@symas.com wrote:
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.
I'll add it to the rest of fixes needed for the replication section too.
Thanks.
Howard Chu wrote:
Rein Tollevik wrote:
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.
Yes, it will be annoying for those that have it misconfigured. That's why I suggest the slapd -c sid=xxx change to allow them easy access to fix their mistakes. But, being informed of a config error instead of having to track down the effects of it might not be so bad after all.
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.
You must also get rid of your old contextCSN with sid=0. Or you will be stuck with a value that no-one updates, and all the refresh phases will replay everthing that have happend since you switch to MM..
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.
Maybe, but then we will not be enforcing serverID 0 is for single master, and cannot assume that a csn with sid=0 was received from a mis-configured server.
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.
Their sid will not propagate, but the forwarding only servers would still barf seeing the serverID 0 it it was enforced as I outlined it.
Rein