Re: (ITS#5431) syncrepl on a subordinate DB writes contextCSN to suffix of parent DB

[rein@basefarm.no]

On Tue, 18 Mar 2008, Howard Chu wrote:

> rein@basefarm.no wrote:
>> 
>> syncrepl_updateCookie() writes the contextCSN to the suffix of si->si_wbe
>> (assigned to op->o_bd).
>
> Yes.
>
>> In a subordinate database this is the parent DB, it
>> should be written to the suffix of si->si_be instead as the attached patch
>> fixes.
>
> No. It works as designed.

Hm, that sounds as a bit odd design to me.  I find it most natural that
the contextCSN should be stored in the suffix of the backendDB where
syncrepl is used.  Then it doesn't interfere with the contextCSN of
other neighboring databases replicated below the same common superior,
nor with the contextCSN a syncprov overlay on the superior glue database
maintains.  But I will not claim to have understood more than a tiny
fraction of the syncrepl protocol and code, so I might be complete lost
on this one.  If I'm wrong this raises a few other questions though.

Upon startup syncrepl reads (in do_syncrep1()) its initial contextCSN
value from the suffix of the backend where it is used.  If it is correct
that it in a glue'ed environment should write it to the suffix of the
superior glue DB, shouldn't it be read from there as well?

My experience from the 2.4.8 release is that syncrepl and syncprov tends
to interfere with each other when they both try to maintain the
contextCSN of the same backend DB.  I.e if they are both used on the
same database or if syncrepl writes its contextCSN to the suffix of a
superior glue database where syncprov is used.  I realize that using
both on the same backend may be necessary in many configurations, but
luckily we was able to avoid it.  I see that the syncrepl code that uses
delete/add to update the attribute (which would fail after syncprov has
replaced all values) has been rewritten in cvs, so I guess this would
not be a problem in an upcoming release.

Rein