2009/2/9 Michael Ströder michael@stroeder.com:
No matter what you do at the LDAP server's side it could happen in between a series of related write operations leading to inconsistent state of data (from the application's point of view).
If you want better hints then you have to provide more details about your deployment.
Ciao, Michael.
We have a primary "hidden" master and two replicating secondaries which both get queried in a round-robin DNS fashion.
Applications such as phpLDAPadmin are configured to connect to these secondaries which pass writes to the primary via an updateref chain overlay.
At the moment I am using slapcat on the primary for backups but am open to other suggestions.
Perhaps I should just create a third read-only replicating secondary which no applications connect to and backup from that ?
The possible problem I see with that setup is what happens if the slapcat occurs during an update from the provider to the consumer ?
--On Monday, February 09, 2009 3:44 PM +0000 Andrew Hall whippyhubbles@googlemail.com wrote:
The possible problem I see with that setup is what happens if the slapcat occurs during an update from the provider to the consumer ?
I'm not sure why you feel it is necessary to set the server read-only before you run slapcat anyway. Do you actually have a process that knows exactly what changes occurred in any given second, so that, if say, your backup starts at 1:00:00, you can then replay all the changes from that point in time?
If you do, then it doesn't matter whether or not it was in read-only. Simply replay the changes. If you don't, then it doesn't matter whether or not it was in read-only, because you don't know what changes happened after that point.
I honestly am not aware of anyone who bothers to put their DB into read-only before slapcatting, although they may be out there.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org