[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Disaster recovery question wrt replication

Steven G. Harms wrote: 
Replies inline:

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 install 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
replication?


Assuming slurpd for replication, what are the answers to these questions:

1. Can I assign multiple replicas 

Yes.

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 replication all
over.  What files can / should I delete.  Which should I not under any
circumstance touch?


Should i delete the slurpd.replog.lock file or/and the slurpd.replog? Should i
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/