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
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
>> *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
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/