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

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/