Rein Tollevik wrote: > Howard Chu wrote: >> Rein Tollevik wrote: > >> Syncrepl should never be propagating contextCSN updates whose SID >> matches the current serverID. By definition, only the current server >> should ever be generating changes with the current serverID. > > Syncrepl is updating all csn values, including those with its own sid. > Syncprov must correct those values in the very likely case that > syncrepl's provider isn't up to date with the local servers changes. Or > the csn with the current servers sid could be lowered, which is a really > bad thing!
The obvious thing to do then is make syncprov ignore CSNs from syncrepl which match the local sid. (Assuming the sid is valid in the first place.) >>> Syncprov must, when syncrepl updates the contextCSN in the suffix of a >>> subordinate DB, update its own knowledge of the "foreign" CSNs to be the >>> *lowest* CSN with any given SID stored in all the subordinate DBs (where >>> syncrepl is configured). And no update must take place unless a >>> contextCSN value have been stored in *all* the syncrepl-enabled >>> subordinate DBs. Any values matching the current non-zero serverID >>> should be updated in this case too, but a new value should probably not >>> be inserted. >> >> Every source of updates to a DB must use its own unique SID. There >> should not be a lowest/highest foreign CSN to choose; there should only >> be one per SID. And as already noted, no syncrepl should ever be sending >> in a contextCSN update for the current serverID, those can only come >> from clients directly writing the local DB. > > All updates takes place on a remote server, with its unique sid. The > problem with this configuration is that there may more than one syncrepl > instance, each in its own subordinate db, replicating from that same > remote provider. Some of these databases may be in sync, other not, > implying that their csn values must not be mixed. Syncprov, sitting on > the glue database and maintaining the joint set of databases, must not > advertise that it is in sync when one of its subordinates isn't. I.e, > it must choose the lowest foreign csn (for any given sid) stored in all > its subordinate databases. I suppose so, but that means you will get redundant updates across subtrees that were already up to date. > Note that, for ordinary MMR, syncrepl and syncprov must be configured in > the same database, meaning that this case is not valid there. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
