[Date Prev][Date Next]
Re: cascading syncrepl
Stephan Dühr wrote:
Howard Chu <email@example.com> wrote:
Stephan Duehr wrote: lenght
Hi all, Yes.
is it possible to set up replicas using syncrepl in a cascading way?
like this: master -> replica1 -> replica2
I tried it using refreshOnly mode and did not succeed. Data Files were
created, but not all index files that should but queries with ldapsearch
resulted in "no such object" error message. slapcat created a zero
file. Yes. See test019 in the test suite, it is there explicitly for testing a
Is cascading syncrepl replication supposed to work?
Ah, thanks. I think the sessionlog was missing in my first replica.
But one thing I wonder about. There are 6 config files used in test019,
one for the master, two slave instances using refreshOnly mode and three
A sessionlog is configured in the masters and the first refreshOnly
replicas config, but not in any of the refreshAndPersist replicas.
Is sessionlog not needed in refreshAndPersist mode?
Is one sessionlog used for all slaves or must there be one for each slave?
The sessionlog directive in those config files is a red herring, none of
the servers in the test make use of the session log.
The documented intent was for multiple sessionlogs to be available on a
provider, each identified by a specific sid. Any number of consumers can
use a particular sessionlog by having the corresponding sid set in their
syncrepl cookie. In practice, the sessionlogs never get used because
there is no config keyword on the consumer for specifying the sid.
I intend to allow only one sessionlog per provider, thus eliminating the
need for the sid everywhere. All consumers will then use the log
whenever the provider has one enabled.
The sessionlog is of course unnecessary in the Persist phase, but it may
still be useful for a refreshAndPersist consumer when the consumer is
initally connecting to the provider, since it still must execute a
Refresh phase before entering Persist mode. This is only an issue if the
consumer was disconnected from the provider from some length of time,
and new updates were made to the provider during that time. Most of the
time, a refreshAndPersist consumer will stay connected to the provider,
so the sessionlog will be irrelevant.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support