[Date Prev][Date Next]
Disaster recovery question wrt replication
- To: <firstname.lastname@example.org>
- Subject: Disaster recovery question wrt replication
- From: "Steven Harms \(stharms\)" <email@example.com>
- Date: Wed, 13 Dec 2006 12:16:27 -0800
- Authentication-results: sj-dkim-7; header.Fromfirstname.lastname@example.org; dkim=pass ( sig from cisco.com/sjdkim7002 verified; );
- Content-class: urn:content-classes:message
- Thread-index: Acce85HhlhNp+U8YQzWS2gDsNyF+uA==
- Thread-topic: Disaster recovery question wrt replication
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