[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!

Updates to "foreign" contextCSN values (i.e those
with a SID not matching the current non-zero serverID) should be
imported into the set of contextCSN values syncprov itself maintain.
Syncprov could also short-circuit the contextCSN update and delay it to
its own checkpoint.  I'm not sure what effect the checkpoint feature
have today when syncrepl constantly updates the contextCSN..
The checkpoint probably only made sense for single-master.

OK, any point in making it work again? It shouldn't be that hard..

Perhaps. Most likely we should move si_cookieState into the BackendDB structure, and let both syncrepl and syncprov update it directly instead of each having their private copies.

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.


OK.

Note that, for ordinary MMR, syncrepl and syncprov must be configured in
the same database, meaning that this case is not valid there.


Right.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/