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:
Hi all,
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.
- Establish replacement replicas
- (master) slapcat -l /resync.ldif. Copy to each replica.
- (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 not necessary.
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 circumstance touch?
Steven