On Mon, 2016-07-04 at 09:37 +0200, Ludwig Krispenz wrote:
On 07/04/2016 01:32 AM, William Brown wrote:
>>> It's not the "post init" operations I'm worried about.
>>> It's that operations that were part of the init to the consumer are
>>> replayed from the changelog.
>>> Operations that occurred after the init starts, definitely still need to
>>> be replayed, and this makes sense.
>>> Lets say we have:
>>> 1 - insert A
>>> 2 - insert ou=B
>>> 3 - modrdn A under ou=B
>>> 4 - insert C
>>> xxxxxx <<-- We start to transmit the data here.
>> if we start the total update here, the supplier will send its RUV in the
>> start repl request, it will be set as RUV in the consumer after total
>> init is complete.
>> it skips to send the ruv entry
> Are you sure? The behaviour that people are claiming to see would
> contradict this behaviour.
yes. As I said, with this behaviour and with teh fix for 48755 there is
still a potential error if the modrdn is done while the online init is
in progress. So we would have to make the "people claim" more precise
The issue is not with operation 5 post the init (it's just put in the
changelog awaiting replication.) The issue is with operation 3 being
sent *but not applied* during online init. At least, this was the
*previous* behaviour of the server prior to 48755.
So, in the previous behaviour of the server, with 3 being skipped, how
was the modrdn applied? You are claiming the RUV of the consumer is set
to that of the supplier which would mean that operation 3 would *never*
be applied to the consumer, causing inconsistency.
Prior to 48755, the only way to send 3, was to set the RUV of the
consumer to some low value, ie start of the changelog. This way, the
changelog would be replayed as a whole.
I seem to remember Mark fixing a bug in URP earlier this year, related
to this topic. Because the consumer RUV was set to an earlier CSN, the
modrdn was being replayed. In the case the entries *were* in order, and
was able to be applied, the URP was failing to double-apply the modrdn.
The fix I think Mark applied was just to skip the failing update. This
bug could only have existing *because* of the consumer having it's RUV
set to a low CSN, and after the init, having the CL replayed.
Given I don't know my way around the repl code very well, can you point
me to the location where the consumer ruv is updated as part of the
replication total init?
Red Hat, Brisbane