Howard Chu wrote:
Peter Mogensen wrote:
> 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.
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?
> 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?
I've taking that test setup down now to test other stuff, so I can't say