[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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 so that:

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.

Rein