[Date Prev][Date Next]
Re: cascading syncrepl
--On Thursday, January 13, 2005 10:20 AM -0800 Howard Chu <firstname.lastname@example.org>
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.
That somewhat depends on how one implements their LDAP systems, and seems
to assume a constant uptime. Stanford, for example, shuts down each LDAP
server nightly in rotation. So it is entirely possible for there to be
updates received at the master while a consumer is disconnected. I look
forward to testing a working sessionlog implementation. :)
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin