[Date Prev][Date Next]
Re: Issue in syncprov findcsn code
Howard Chu skrev:
Rein Tollevik wrote:
Pierangelo Masarati wrote:
- initialize slapd_serverID with some SID_UNDEFINED in order to take the
action above only when SID is not defined
I agree, although I would prefer to take it one step further and reserve
serverID==0 for the tools case. In ITS#5536 I tried to distinguish
between a defaulted and configured serverID==0, but it didn't quite slip
through and was closed without being properly fixed. It should probably
Well, a serverID of 0 is basically the same as no serverID. For
mirrormode/multimaster the serverID must be non-zero. For single-master
the serverID must be zero.
This is not how I read the doc nor the source. But if it was like this
then it should be what I need :-) To enforce it syncprov must be changed
If serverID is 0 it should only allow one contextCSN value, and it
should have 0 in the sid field. Maybe not required to enforce, but it
should help to quickly identify incorrectly configured servers.
If serverID is not 0 it should not accept contextCSN values from
syncrepl with 0 in the sid field, to make sure it don't receives updates
from a single-master configured server.
If serverID is not 0 it must ignore contextCSN values with 0 in the sid
field read from the database. This is to allow a single-master server
to be promoted to a multi-master without leaving the old sid=0 csn
around forever. Hmm, if a csn with sid=0 is found, but none with the
serverID value, then it could maybe be better to replace the sid in that
csn? More hmm, when starting up it would probably be correct to include
entries with 0 in the sid fields of their entryCSN value in those that
could cause the current servers contextCSN to be updated? I expect I'm
not the only one that forgets to add the -S argument to slapadd...
The serverID in existing mirrormode/multimaster configurations that uses
0 as the value must be changed, but this should be all that is needed
when upgrading to this version.
What would be the correct action if a contextCSN with an invalid sid
value is received from syncrepl? Asserting it could be a bit too
strict, better to ignore the value and complain loudly in the logs?
Does this make any sense? If so, I'll volunteer to implement.