[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.



On 13.01.11 21.31, hyc@symas.com wrote:
> cmikk@qwest.net wrote:
>> On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote:
>>> On 11/19/10 23:55 , cmikk@qwest.net wrote:
>>>
>>>> will evaluate to true in cases where it should not. A quick fix would be to
>>>> compare directly against the CSN of the sessionlog's head:
>>>
>>> An extended version of this fix, which also ensures that the
>>> sessionlog is kept in csn order, is now in head.  Please test,
>>> syncprov.c revision 1.320.
>>
>> Looks good to me. Thank you.
>>
>> I discovered this bug while trying to reproduce ITS#6717.
>>
>> I've attached a patch to that ITS which appears to fix
>> that problem. If you have the time, I'd appreciate some
>> feedback on that patch. The issue makes it very inefficient
>> to run a slave in refreshOnly mode with a multimaster /
>> mirrormode master.
>>
>> Best Regards,
>
> The current code is broken.

Which current code?  My patch for this its, or his patch for its#6717?

>> Other than the patch I suggested (using the list head's
>> CSN value directly), I can think of two other approaches:
>>
>> 	1) When adding an entry to the sessionlog, check
>> 	if sl_mincsn is empty. If it is, update sl_mincsn
>> 	to the new entry's CSN.
>>
>> 	2) When initializing the sessionlog, set sl_mincsn
>> 	to the maximum contextCSN value of the underlying
>> 	database.
>>
>> #2 seems ideal from an efficiency standpoint, although it
>> differs from the algorithm the current code appears to be
>> intended to implement.
>
> We should have gone with #2. The problem scenario:
>
> 1: Provider and consumer in sync, both started fresh, sessionlog is empty.
> 2: stop consumer
> 3: write on provider
> 4: start consumer
>
> Result: the sessionlog is ignored, because the sl_head is newer than the
> consumer's cookie.
>
> After the consumer syncs, you can repeat steps 2-4 and see that the sessionlog
> is used from then on.

Initializing sl_mincsn from the maximum csn won't do much good here, as 
long as the (current) requirement to use the log is that the consumers 
mincsn is greater or equal to sl_mincsn.  Assuming there is more than 
one csn in the set that is..

Initializing with the minimum csn should cause the current log to be 
used in this scenario.  But, if the provider restarts between 3 and 4 it 
would incorrectly appear that replaying the log would be sufficient to 
bring the consumer in sync.   A situation far worse than doing a refresh 
when replaying the log would have been sufficient.

More on possible fixes in my reply to your other message.

Rein