Howard Chu wrote:
> Peter Mogensen wrote:
>> This is mirrormode.
>> There's no "provider" as such. However, there's one server
>> 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"
>> 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
> 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
> its parent. Once the Refresh phase ends and it transitions to the
> phase, all entries' parents will exist and so this particular condition
> no longer occur.
> Of course, no one is saying for certain that this is the explanation,
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.