Then just slapcat the data first, do your destructive tests, and then
restore from slapadd. Doing repetitive ldap deletes/adds will just causes massive database growth.
OK, but I just want to be clear - I'm still not. Does that mean that I need to nuke /var/lib/ldap on every master replica prior to restoring the DIT?
Also, another question, if I do that will I have to know the server ID (for "-w -S <SID>") in order to properly reload? I'm asking because then my testers need to know which master is which - and there is no guaranteed order at the moment with our configuration.
Thanks, Frank
On Wed, Apr 13, 2016 at 11:51 AM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Wednesday, April 13, 2016 12:29 PM -0400 Frank Crow < fjcrow2008@gmail.com> wrote:
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.
Then just slapcat the data first, do your destructive tests, and then restore from slapadd. Doing repetitive ldap deletes/adds will just causes massive database growth.
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!" ;-)
I guess it just depends on whether or not they consider data loss acceptable. If they do find it acceptable, by all means, stay on 2.4.40. ;)
Also not sure which database backend you're using, but I'd strongly advise back-mdb once you get to 2.4.44.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
--On Wednesday, April 13, 2016 1:16 PM -0400 Frank Crow fjcrow2008@gmail.com wrote:
Then just slapcat the data first, do your destructive tests, and then restore from slapadd. Doing repetitive ldap deletes/adds will just causes massive database growth.
OK, but I just want to be clear - I'm still not. Does that mean that I need to nuke /var/lib/ldap on every master replica prior to restoring the DIT?
Yes.
Also, another question, if I do that will I have to know the server ID (for "-w -S <SID>") in order to properly reload? I'm asking because then my testers need to know which master is which - and there is no guaranteed order at the moment with our configuration.
No, you do not need to pass any -S SID option for a slapcat that was taken from a real master. You *only* use that if you're loading an LDIF where you are forcing entryCSN generation, which you would not want to do for your backups. In fact, that will likely cause serious issues if you do set that when loading a DB taken from a real master.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
--On Wednesday, April 13, 2016 10:20 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Wednesday, April 13, 2016 1:16 PM -0400 Frank Crow fjcrow2008@gmail.com wrote:
Then just slapcat the data first, do your destructive tests, and then restore from slapadd. Doing repetitive ldap deletes/adds will just causes massive database growth.
OK, but I just want to be clear - I'm still not. Does that mean that I need to nuke /var/lib/ldap on every master replica prior to restoring the DIT?
Yes.
Or I should say, depends on what you've done. If all masters are in a "bad" state (which would be likely given your test scenario), then yes, you want to reload them all from the same slapcat dump that was taken, so their DBs are identical after restore.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
openldap-technical@openldap.org
-
Frank Crow -
Quanah Gibson-Mount