[Date Prev][Date Next]
Re: contextCSN interaction between syncrepl and syncprov
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/