Am Freitag 11 November 2011, 11:05:28 schrieb Howard Chu:
Ralf Haferkamp wrote:
> I wonder how we should go forward with test058-syncrepl-asymmetric.
> If I understand the test (and the comments in syncrepl.c)
> correctly the setup it is testing is unsupported in slapd, am I
> right? (Which is the reason why test failures are ignored
> currently, I guess)
> On the provider the syncprov overlay is setup for the glued
> database and the consumer's syncrepl clients (also glued) are
> configured on the individual child databases. Additionally the
> consumers have configure the the syncprov overlay also of the
> topmost database. AFAICS all of the failures that test058 reports
> are related to this unsupported config.
> Is anybody planning to work on adding support for such a setup. Or
> should we just rework the test to a supported scenario (or even
> remove it completely)?
No plans, but it's probably worth thinking about supporting it.
So how could
support for this look like? One problem is that the
consumers compute their sync cookies from the glued db's contextcsn
attribute (at least if the glued db has the syncprov overlay loaded).
This leads to the race problem upon consumer startup (I think) and also
to the problem that the initial sync for newly added consumer databases
does not work in such a setup.
One possible solution might be to store the contextCsn separately for
every db, even if the syncprov overlay is added to the glue database.
This would of course require special handling for consumers replicating
the complete glued tree.
Or how about having every consumer store its individual cookie separately
from the contextcsn (e.g. in a subentry)?
(Patches welcome.) Gluing different types of contexts together seems
to be a pretty important capability anyway, and in general our support
for multiple contexts is weak. (E.g., ITS#6942.)