Steven G. Harms wrote:
On Wed, Dec 13, 2006 at 07:36:22PM -0500, Aaron Richton wrote:
> Use of slurpd certainly isn't a modern architecture, especially with
> concern for rapid DR, for reasons including your question at hand. Look
> into syncrepl (make sure to upgrade to 2.3.30 first) and mirrormode.
Due to reasons beyond my control, I'm currently at OpenLDAP version slapd
2.2.13 (Aug 18 2005 22:22:34). As such syncrepl, based on your
versioning guideline below isn't an option.
Nothing good will come of this. It sounds like you're just entering
deployment, with a release that's been obsolete for quite a while.
(2.2.13 was released June 2004. It was superseded by 2.2.14 only 4 days
later. That's hardly a good place from which to launch a new project.)
> I would argue that the way to deal with HA/DR with OpenLDAP is to
> enough slaves that you feel the odds of complete failure are tolerable,
I have built replicas in different data centers etc. So I'm going for a
'multiple replica' theory of backup. The DR need not be instant, nor does it
need to be perfectly synchronized.
In light of these constraints, would it be appropriate to use slurpd for
Assuming slurpd for replication, what are the answers to these
1. Can I assign multiple replicas
2. How can I clean out the replog back-queue to a pristine start?
3. I suppose, more generally, I'm asking: How do a start
over. What files can / should I delete. Which should I not under any
Should i delete the slurpd.replog.lock file or/and the slurpd.replog?
just cat /dev/null into them? How can I start over? And further, how do i
rotate the replog as it starts to eat up more filesystem.
For the record I'm using a BDB back end.
If you're using multiple replicas then you can't simply delete the
replog file, unless you're reinitializing all the replicas at once. The
simplest approach may be to rewrite the records in the slurpd.status
file with timestamps matching the snapshot they started from.
Rotating the replog should never be needed, since slurpd truncates it
automatically as changes are propagated. Deleting the lock files is
irrelevant, since they don't contain anything.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/