Re: cascading syncrepl

[Howard Chu <hyc@symas.com>]

Stephan Dühr wrote:

> Howard Chu <hyc@symas.com> wrote:  
>  
>
> > Stephan Duehr wrote: 
> >
> >    
> >
> > > Hi all, 
> > >
> > > is it possible to set up replicas using syncrepl in a cascading way? 
> > > like this: master -> replica1 -> replica2 
> > >  
> > >
> > >      
> > Yes. 
> >
> >    
> >
> > > 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 
> > >      
> lenght 
>  
>
> > > file. 
> > >
> > > Is cascading syncrepl replication supposed to work? 
> > >  
> > >
> > >      
> > Yes. See test019 in the test suite, it is there explicitly for testing a  
> > cascaded setup. 
> >    
>
> 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 
> using refreshAndPersist. 
> 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
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support