Peter Mogensen wrote:
Howard Chu wrote:
apm@mutex.dk wrote:
Pierangelo Masarati wrote:
You appear to be using back-hdb.
Yes.
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 DN get fixed anyway, though, because missing entries should exist as "glue" objects.
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 used 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?