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 > and investigate 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? Thanks, -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
