Peter Mogensen wrote:
Howard Chu wrote:
> apm(a)mutex.dk wrote:
>> Pierangelo Masarati wrote:
>>> You appear to be using back-hdb.
>>> My guess is that if this can fail, e.g. because entries are being
>>> sync'ed out of order, the DN does not get fixed. If this is the case (I
>>> couldn't inspect code deep enough to make sure), I'd expect that the
>>> get fixed anyway, though, because missing entries should exist as
>> yes. But if you plan to use slapcat as a backup mechanism, then it's
>> still a problem.
> Sounds like a low priority issue at best. Taking backups of a replica while it
> is initializing is pointless, just take a backup of the provider instead.
This is mirrormode.
There's no "provider" as such. However, there's one server which is
for application access and to minimize disk load on that server, the
plan was to take most backups from the other.
I can't see any difference between what you call "initializing" and
normal running state, except that the difference between server-1 and
server-2 is (somewhat) larger.
If the problem is as Ando suggests, then it's because in the syncrepl Refresh
phase it's receiving entries out-of-order from the provider. Ando is
suggesting that the problem is caused when a child entry is replicated before
its parent. Once the Refresh phase ends and it transitions to the Persist
phase, all entries' parents will exist and so this particular condition will
no longer occur.
Of course, no one is saying for certain that this is the explanation, yet.
If I can't trust slapcat during this
phase, how can I trust slapcat for backups?
Does slapcat behave this way on the active server?
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/