List:Internals« Previous MessageNext Message »
From:Mats Kindahl Date:May 13 2009 11:45am
Subject:Re: Feedback needed for WL#2687
View as plain text  
Alfranio Correia wrote:
> Mats Kindahl wrote:
>> Alfranio Correia wrote:
>>   
>>> Hi all,
>>>
>>> Find below a proposal on how to handle WL#2687.
>>> There is also a draft of a patch available in a related bug (BUG#40278).
>>>     
>> There is also BUG#28976 to consider when implementing WL#2687.
>>   
> 
> ok. Which bug should I reference when committing a patch?
> The fix will be same anyway.

I suggest that you reference the worklog and then close the bugs manually. There
might be other bugs, that we do not know about right now, that are fixed by this
as well.

[snip]

>>> PROPOSAL
>>> --------
>>> To correctly handle the mix of transactional and non-transactional
>>> tables, we
>>> propose what follows.
>>>
>>> In STMT and MIXED modes, statements are copied to the binary log upon
>>> commit or rollback thus preserving any semantic among the statements in a
>>> transaction.
>>>     
>> You need to clarify this and point out that the non-transactional statements are
>> *not* written out of order but will appear in the same order in the transaction
>> as they are written.
>>   
> 
> ok.
> 
>> However, I am not sure why this need to apply to mixed mode. We can easily
>> switch to row-based, and write the T(s) part to the transaction cache and the
>> N(s) part directly to the binary log.
>>   
> 
> So let's do it. I will change the implementation to do so.
> 
>>   
>>> Unfortunately, we cannot ensure that mixing transactional and
>>> non-transactional tables will be handled correctly
>>>     
>> ... in statement-based replication...
>>
>>   
> 
> This is related to statement based if we switch to rows in mixed mode.

Right.

>>> and as such we should
>>> properly document this and discourage such modes under this circumstance.
>>>     
>> Clarify "this circumstance." Do you mean when using statement-based replication?
>>   
> 
> ok. This is related to statement based if we switch to rows in mixed mode.

OK. Agree.

[snip]

>>> Note that we are not proposing to distinguish the case that
>>> non-transactional changes are processed before any transactional change, what
> could be safely
>>> handled with minor changes to our proposal.
>>>     
>> I don't understand this sentence.
>>   
> 
> I will rewrite this but I meant to say that we will not distinguish the
> cases presented below:
> 
> start;
> N
> T
> commit;
> 
> and
> 
> start;
> T
> N
> commit;
> 
> In other words, we will not implement any sort of optimization based on
> the position of the
> non-transactional changes.

OK.

[snip]

>>> TODO ------- WE NEED TO DISCUSS THIS CASE --------- DISCUSSION 1
>>> 1.1 - Should we distinguish between safe and unsafe cases?
>>>     
>> Do you mean unsafe as in "statements containing, e.g., non-deterministic
>> changes" or in any other sense. You were using "safe" in the preceding sentence,
>> so I am not sure which one you are referring to.
>>   
> I am using safe and unsafe here to denote the mix of non-transactional
> and transactional tables in STMT mode.

OK.

>>> 1.2 - Should we either print out warning messages or throw an error for the
>>> unsafe cases?
>>>     
>> Yes?
>>   
> If you are switching to rows in MIXED mode when mixing non-transactional
> and transactional tables, I think we should print warning messages in STMT
> mode.

OK. Well... strictly speaking, they are not unsafe any more when switching to
row format.

[snip]

>>> Thus to check the behavior provided by the current code we divided
>>> the test as follows:
>>>
>>> 1 - MIXING TRANSACTIONAL and NON-TRANSACTIONAL TABLES
>>>      1.1 - NN TT
>>>      1.2 - TT NN
>>>      1.3 - TT NN TT
>>> 2 - CONCURRENCY:
>>>      2.1 - NON-TRANSACT TABLES -  SET AUTOCOMMIT = 0  | COMMIT
>>>      2.1 - NON-TRANSACT TABLES -  SET AUTOCOMMIT = 1
>>>      2.2 - NON-TRANSACT TABLES -  SET AUTOCOMMIT = 1  | START - COMMIT
>>> 3 - CREATING TABLES through SELECT * FROM
>>> 4 - UPDATING MULTIPLE TABLES
>>> 5 - PROCEDURES, FUNCTIONS AND TRIGGERS
>>> 6 - EVENTS
>>>
>>> TODO ------- WE NEED TO DISCUSS THIS CASE --------- DISCUSSION 2
>>> 2.1 Are the tests proposed for procedures, functions and triggers enough?
>>>     
>> You need to ensure that you have different nesting levels for stored routines:
>> the behavior is different depending on the nesting level (not for RBR, but for
> SBR).
>>   
> How many levels?
> What I have is "statement --> proc --> proc". Three levels?
> Is this enough?

Yes, I think that should be enough. AIUI, stored routines called from stored
routines are separate, but then it's all the same.

[snip]

>>> TODO ------- WE NEED TO DISCUSS THIS CASE --------- DISCUSSION 3
>>> 3.1 Do we really need a cache for non-transactional events? IMHO, a cache to
>>> address the only the current worklog is overkilling.
>>>     
>> I don't think so, and here is why:
>>
>> Suppose that we start a statement "s" that contain transactional ( T(s) ) and
>> non-transactional ( N(s) ) changes so that the non-transactional changes span
>> more than one event. If we flush the N(s) part immediately, the binary log will
>> look something like this:
>>
>> Table-map  n1
>> Write-rows N(s)  STMT_END_F
>> Table-map  n1
>> Write-rows N(s)  STMT_END_F
>> BEGIN;
>> Table-map  t2
>> Write-rows T(s)
>> Write-rows T(s)
>> COMMIT;
>>
>> When we execute these statements on the master, any concurrent operations on n1
>> will be blocked, waiting for the statement to complete. However, on the slave,
>> concurrent operation on n1 will block until the first part has been executed,
>> then the lock will be released, and it will be allowed to execute. In that
>> sense, the changes to n1 will not be atomically executed, which can have all
>> sorts of consequences.
>>   
> Hummm ok !!! I thought this was not a problem as you are
> changing a non-transactional table.
> 
> But I understood your point and agree with you.
> We need a cache. :)

OK. Good. :)

Best wishes,
Mats Kindahl
-- 
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
Thread
Feedback needed for WL#2687Alfranio Correia13 May
  • Re: Feedback needed for WL#2687Mats Kindahl13 May
    • Re: Feedback needed for WL#2687Alfranio Correia13 May
  • Re: Feedback needed for WL#2687He Zhenxing14 May
    • Re: Feedback needed for WL#2687He Zhenxing14 May
    • Re: Feedback needed for WL#2687Alfranio Correia15 May
      • Re: Feedback needed for WL#2687He Zhenxing18 May
  • re: Feedback needed for WL#2687Michael Widenius14 May