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
--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
openldap-technical@openldap.org
-
Frank Crow -
Quanah Gibson-Mount