[Date Prev][Date Next]
Re: Disaster recovery question wrt replication
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.
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,
and work on a good DR plan for the event of a master failure. With that
said, slapcat/slapadd is the preferred server turnup technique, DR or not.
With slapadd -q and sufficient RAM you can achieve reasonable (i.e.
minutes) turnup times even on fairly large databases. On modern storage
backends (bdb/hdb) slapcat is safe to do hot, so slapcat/slapadd will give
you a fairly quick recovery with any interval between backups that you
feel comfortable with. If you require greater availability than "minutes,"
mirrormode is probably the right idea.
I'm pretty sure that mirrormode requires syncrepl. I'm not personally
sure, I've deferred considering it until 2.4.
On Wed, 13 Dec 2006, Steven Harms \(stharms\) wrote:
New LDAP implementor here.
I'm trying to document disaster recovery steps.
Assuming a single master and 3 replicas.
[Q1]: Is this an acceptable architecture? In the master's slapd.conf I
define 3 replica statements, and on the 3 replica servers I use this
master as the updateref.
If all the replicas fail and the master survives, I'm trying to figure
out how to restore service.
1. Establish replacement replicas
2. (master) slapcat -l /resync.ldif. Copy to each replica.
3. (each replica) slapadd -l /resync.ldif
Now here's the sticky part. The slurpd.replog has entries that were
destined for the replicas. Now that I've sync'd via slapadd, these are
How can I clean out the replog back-queue to a pristine start?
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