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