Re: syncrepl with accesslog database

[John Morrissey <jwm@horde.net>]

On Thu, Apr 03, 2008 at 12:10:49AM -0700, Howard Chu wrote:
> John Morrissey wrote:
> >On Thu, Mar 13, 2008 at 12:53:04PM -0400, John Morrissey wrote:
> > >I'm trying to replicate (with syncrepl) the bdb database generated by
> > >the accesslog overlay. This is with 2.3.41 on both provider and
> > >consumer. slapd complains:
> > >
> > >do_syncrep2: rid 002 got empty syncUUID
> > >do_syncrepl: rid 002 retrying (29 retries left)
> > >
> > >Sure enough, the entry for my accesslog database's suffix doesn't have
> > >an entryUUID:
> > >
> > >Given that my consumers are using delta-syncrepl (hence the accesslog),
> > >is there any reason I can't/shouldn't replicate the accesslog itself,
> > >too?
> >
> > I've poked at this a little more, and I'm still not sure why this
> > accesslog db didn't get an entryUUID. Am I silly wanting to replicate
> > the accesslog, or did I do something wrong during its initial
> > configuration/creation?
> 
> Yes, it seems a bit silly to explicitly replicate it; that means the 
> producer has to send its contents twice to each delta-sync consumer. Just 
> configure an accesslog overlay on each consumer and let them regenerate the 
> log locally.

Won't configuring a separate accesslog on the consumers result in slightly
different accesslogs (relative to each other and to the provider) being
generated, since there is inherent latency between the writes on the
provider and the writes on the slaves? Also, won't the reqAuthzID in the
consumers' accesslogs be different, since the syncrepl engine uses the
rootdn internally to make the changes to consumers' databases?

What I'm after here is to have a provider and a number of slaves that have
exactly the same contents in their databases. In the past, this has provided
us with some options when things have gone wrong.

For example, if we have a hardware failure on the provider, we can promote
one of the consumers easily, since its databases are identical copies. Also,
if our indexing needs change on the accesslog database (for example, if we
decide to read from it for something other than delta-syncrepl), we can down
one of the consumers and reindex the accesslog database, bring the consumer
back up so it re-syncs with the provider, bring both down simultaneously,
and copy the consumer's database files to the provider. This keeps the
provider's downtime to a minimum. AFAICT, slapindex(8) can't be run while
slapd is read-write, and doing this has saved us in the past.

Essentially, I want to have interchangable provider and consumers, so nobody
has to think in situations like these. Given these examples, am I still
silly wanting to replicate the accesslog database, or are there better ways
of accomplishing the same things?

john
-- 
John Morrissey          _o            /\         ----  __o
jwm@horde.net        _-< \_          /  \       ----  <  \,
www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__