Howard Chu wrote:

...

Peter Mogensen wrote:

...

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.

It sounds reasonable to me :) But unless you are not in any way allowed to - ever - make writes to more than one server in a mirromode setup, this could (as I hear it) potentially happen at any time. The only reason I have to only make writes to one server is that I currently (this will change) have an application which is dependant on making writes and immediately reading back the entry.

As I hear what you're saying is that any write to a server in a mirrormode setup could invalidate a slapcat running on the other. This would mean that you can never write to more that one server at all and that's the only server you can slapcat while running. That takes a lot of the "mirror" out of "mirrormode". Doesn't it?

Based on my *very incomplete and possibly wrong* analysis, the problem would be automatically cured by using back-bdb. Also, fixing back-hdb *if it's broken at all* should be possible.

p.