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

Re: ldapdelete recursive (-r) with syncrepl



Well, OK.   Our formal test procedures (created and executed by a separate team) will intentionally do all manner of destructive changes to the DIT after taking a snapshot.    After which they want to clean and reload the entire DIT in order to: 1) be able to run the tests multiple times with the same data, and 2) restore the DIT for normal (non-OpenLDAP related) testing that does need the DIT intact.

During production use, we would not be doing that.   For that, I think the individual node repair (slapadd/slapcat) would be exactly what we need.

I took your suggestion and forwarded the list of changes since 2.4.40 (with the syncrepl fixes highlighted) to the important people up the "flag pole" this morning.   I am "fighting the good fight" with them but they are hesitant to move without strenuous "encouragement!"   ;-)

Thanks,
Frank


On Wed, Apr 13, 2016 at 11:17 AM, Quanah Gibson-Mount <quanah@zimbra.com> wrote:
--On Wednesday, April 13, 2016 11:51 AM -0400 Frank Crow <fjcrow2008@gmail.com> wrote:


I did see that and do know how to do slapadd/slapcat backups.    What
I'm not clear on is how that works with N-Way MMR.    Wouldn't I have
to go and delete the the /var/lib/ldap on every master replica machine
prior to loading the backup with slapadd?    Or is that not necessary?

Is your intent to drop the database and reload it on every master?  That would seem to indicate you've got significant issues with how you manage your servers.

You can trivially recover any one given server with the backup from another MMR node.  I.e., say you want to take down node 3... slapcat node1 or node2, and load that onto node 3...

Again, more information on what it is you're really trying to do here would be useful.


In any case, I did update my syncrepl to use cn=accesslog and I no longer
have any issues with bulk operations being propagated to the other master
replicas.

Good, delta-syncrepl's definitely better.  But this doesn't resolve the many replication problems that still exist in 2.4.40.


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
A division of Synacor, Inc



--
Frank