List:Commits« Previous MessageNext Message »
From:Daogang Qu Date:August 24 2010 10:14am
Subject:Re: bzr commit into mysql-next-mr-bugfixing branch (Dao-Gang.Qu:3192)
Bug#53167
View as plain text  
He Zhenxing wrote:
> Hi Daogang,
>
> There is still problem for RBR, the following test will crash:
>
> -------------------------------------------------------------
> source include/master-slave.inc;
>
> CREATE TABLE t1 (a INT);
> INSERT INTO t1 VALUES (sleep(1));
>
> sync_slave_with_master;
> --------------------------------------------------------------
>
> The problem is that the INSERT will be binlogged as the following:
> BEGIN;
> TABLE_MAP;
> WRITE_ROWS;
> COMMIT;
>
> And the execution time of the statement (1 second) will be set to the
> exec_time of the BEGIN event, while all other events will have exec_time
> as 0, which will result in a last_master_timestamp back traverse.
>
> I think the problem must be fix on the master side, set all events
> exec_time to the time of the statement.
>   
Yes. But even if we set all events exec_time to the time of the statement.
It still has lots of problems. I list a fragment from 
rpl_semi_sync_event.test
as following:

#100824 17:43:12 server id 1  end_log_pos 5003     Query    
thread_id=20    exec_time=1    error_code=0
SET TIMESTAMP=1282642992/*!*/;
SET @@session.pseudo_thread_id=20/*!*/;
BEGIN
/*!*/;
# at 5003
#100824 17:43:12 server id 1  end_log_pos 5126     Query    
thread_id=20    exec_time=0    error_code=0
SET TIMESTAMP=1282642992/*!*/;
UPDATE t1 SET f = CONCAT('up_',CONNECTION_ID()) WHERE i = 10
/*!*/;
# at 5126
#100824 17:43:12 server id 1  end_log_pos 5153     Xid = 86
COMMIT/*!*/;

I shows that the query_log_event still can't escape the 
DBUG_ASSERT(rli_last_master_timestamp <= rli->last_master_timestamp)
even if we set the event exec_time to the time of the statement;

We just want to take out the bug#53167 by DBUG_ASSERT.
So I want to update the diff code as  following:

-    if (!(ev->is_artificial_event() || ev->is_relay_log_event() || (ev->when ==
0)))
+    static rli_last_master_timestamp= 0;
+    if (!(ev->is_artificial_event() || ev->is_relay_log_event() ||
+          (ev->when == 0) || ev->get_type_code() == INTVAR_EVENT ||
+          ev->get_type_code() == FORMAT_DESCRIPTION_EVENT ||
+          ev->get_type_code() == USER_VAR_EVENT ||
+          ev->get_type_code() == RAND_EVENT))
     {
       rli->last_master_timestamp= ev->when + (time_t) ev->exec_time;
+      DBUG_ASSERT(rli_last_master_timestamp <= ev->when);
+      rli_last_master_timestamp= ev->when;
       DBUG_ASSERT(rli->last_master_timestamp >= 0);
     }

What do you think?

Best Regards,

Daogang

> Dao-Gang.Qu@stripped wrote:
>   
>> #At file:///home/daogangqu/mysql/bzrwork1/bug53167/mysql-next-mr-bugfixing/ based
> on revid:vvaintroub@stripped
>>
>>  3192 Dao-Gang.Qu@stripped	2010-08-20
>>       Bug #53167  	Seconds_Behind_Master is wrong after start slave
>>       
>>       When a slave server has an existing relay log and the user issues
>>       START SLAVE, the output from "SHOW SLAVE STATUS" shows a wrong
>>       value for Seconds_Behind_Master until the first event from the relay
>>       log has finished executing. The displayed value for Seconds_Behind_Master
>>       is calculated based on the timestamp of the relay log's
>>       Format_Description_Log_Event. This can be a very big number if the relay
>>       log was created long ago.
>>       
>>       The Timestamp recorded in Format_Description_Log_Event should not be used
>>       when executing the Format_Description_Log_Event on slave. So do not assign
>>       the Timestamp of the Format_Description_Log_Event to
> last_master_timestamp.
>>       The the peak value will disappear.
>>      @ sql/rpl_slave.cc
>>         Adde code to make sure that the Timestamp of
> Format_Description_Log_Event
>>         will be smaller than the last executed event on slave. It is not
> reasonable
>>         and then "rpl_seconds_behind_master" test will cause abort by the added
>>         DEBUG_ASSERT. The test will run OK if we do not assign the Timestamp of
>>         Format_Description_Log_Event to the last_master_timestamp on slave.
>>
>>     modified:
>>       sql/rpl_slave.cc
>> === modified file 'sql/rpl_slave.cc'
>> --- a/sql/rpl_slave.cc	2010-08-04 10:34:01 +0000
>> +++ b/sql/rpl_slave.cc	2010-08-20 07:36:27 +0000
>> @@ -2685,12 +2685,21 @@ static int exec_relay_log_event(THD* thd
>>        that are not replayed, so we keep falling behind).
>>  
>>        If it is an artificial event, or a relay log event (IO thread generated
>> -      event) or ev->when is set to 0, we don't update the 
>> -      last_master_timestamp.
>> +      event) or ev->when is set to 0, or a format description event which
> will
>> +      cause peak value for Seconds_Behind_Master(BUG#53167), or one of
>> +      Intvar_log_event, User_var_log_event and Rand_log_event which will result
>> +      in back traverse of last_master_timestamp if the exec_time of the
> statement
>> +      before these events are not zero, we don't update the
> last_master_timestamp.
>>       */
>> -    if (!(ev->is_artificial_event() || ev->is_relay_log_event() ||
> (ev->when == 0)))
>> +    if (!(ev->is_artificial_event() || ev->is_relay_log_event() ||
>> +          (ev->when == 0) || ev->get_type_code() == INTVAR_EVENT ||
>> +          ev->get_type_code() == FORMAT_DESCRIPTION_EVENT ||
>> +          ev->get_type_code() == USER_VAR_EVENT ||
>> +          ev->get_type_code() == RAND_EVENT))
>>      {
>> +      time_t rli_last_master_timestamp= rli->last_master_timestamp;
>>        rli->last_master_timestamp= ev->when + (time_t) ev->exec_time;
>> +      DBUG_ASSERT(rli_last_master_timestamp <=
> rli->last_master_timestamp);
>>        DBUG_ASSERT(rli->last_master_timestamp >= 0);
>>      }
>>  
>>
>> text/bzr-bundle 类型 附件
>> (bzr/dao-gang.qu@stripped)
>> # Bazaar merge directive format 2 (Bazaar 0.90)
>> # revision_id: dao-gang.qu@stripped
>> # target_branch: file:///home/daogangqu/mysql/bzrwork1/bug53167/mysql-\
>> #   next-mr-bugfixing/
>> # testament_sha1: 43daa04d52d343286a4a168d97aacd2896a71999
>> # timestamp: 2010-08-20 15:36:38 +0800
>> # base_revision_id: vvaintroub@stripped\
>> #   4v0fwe0l8uc2j4kd
>> # 
>> # Begin bundle
>> IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWc0KRS8AAn5fgFEweOf//3/v
>> /4C////0YAcDt9dZUFr0xPW3txTRTodBkgmU0mxMTKenqNTKeRpPKaaeo9NIYag9EPSNGgyKDAmo
>> xDTFNMpvVPKNB6nqAAAAA0Bqm1TyTQGmgAaAAAaaaaAAAHqANNERT9Sek9Q9R+qep6Rkeo0eoaAG
>> QaAAAA4yZNGIaaGAmhiaNMmIGRhNGmmEGTCSIEACSbQ0m1T9RgJo1NNkjajRpk0DJo0b2IAZSqjk
>> XLjC/Dd4CR8BZu4eDFM9AHKFsmb7R+QdOlCAGK4Mq1Z87PJv+ElPjLPhIBuoAXgHg508mX8SoiEd
>> GJ/5Ab7Mcy40NSBTKEEzwxbfKOAF6axiLwrVX47+vEXAPAl3XQdeIqCxVVDpjW14vDSqzNURqi0+
>> EHhlYtkED8/eDA2OlfZAUQnD9KCTwxdyBZURSIRAiQFD67kphY5OjlTaSNROEbYSbPJSsYkzDvXl
>> KmULI5UwbdNUVicOCJbFZhPOJVNewcEaq051t1lBy6GZbuf6WW5YFd6giFO7AxdAF8P93S2iiegB
>> 6TI315GtdntqNoI5Ij5g2BBT2jaoOmOnpV/Nl1jloBg6GgKMdUbGz0EVAZiZgb3wlKGfrmVsloxt
>> TWh1iiI46QEUUQ7CfyIBSIy5uigBS1WKpTk/EslegwaXSyF+DKvQ4vGzylphC0KweoZzg/ZPyLBt
>> 47vMbarmhMZWDNoQ1NuNCYgxBEC/XHZdwpaOk6xwurgGQfRa4HHypktNDLJZp8LSTqKAcRe8HGwt
>> maGJOrhWjnfs6ri7OhljmHUDzVw31mx6pa4VsiOqQNZrNrhSbtoFXpGvPhX38NJpzhRG3gVj0Zc4
>> rqeTkWTGbXsoqoEpN1C1CgQDTEsdEoI7YPDgVSJQLzbgbQaX7MD2C+A1sz5WKXIECPxOgvborzAi
>> yoCQpbdRMkXSWoUpMXrDUXA3Ik+ukxGaJc1X4UrXiQvKEccrix4vcxF6qXNSMSBScFJ6M48qgqqZ
>> R9WqubaNZHfFhsvabFoIyMnf7eUEOsNpP76fMf0K4cBVNUww3f/HrKwn4e+qPy2OLArtcKlCIjWi
>> o/1eKcc9L4JQHwUQYDuwAlV6XpJaDpVWWBgY65QQVE4QGCHkyi8pMzVH0pFqTGZHqW842qReGFPi
>> fiFOgWBdw94uUXQEqjkCS72edbo9x7K/g7yArPCyAxV7KARBt8HV8Hgcp2dSD0vv2a1Sdar4kAVv
>> MpiGzfXSi4gL1IJbcouqFuG2AOKAM/0nlEdREuaXenG9wtIG01IgIiQmRkUd1uANBGBAeZw7oDdu
>> WN3IwdhnIug7apWcY+XNoLMpNIWq416ojTV/cHSN7S2yrnOdjIazQK0jO8UfIlsgithOzjX6S4Dh
>> uKKqawM49U04vadw2O3XX6fFD3IwC2Gus+MARIUtoMqEbKL4TZpWc2BledNCmZM+tykFlj6NTod2
>> uk9kAtqAa5Q69x9YQ2856M9WXvH4QvKwRTMM44hZJtAqastXeD8bFs1ycudTtT0hRAnoATHWCkNg
>> 1fK5yDNFCCm6ERxJAKX3tMsTpFKDOQA4LJcZd1PIHKUg8ICZO2gfXeg96ondQoeKKwBCL3l/ZFSF
>> AgTKa+mzXo1LyjTcEE+sehL5r1Rg5jSGlaGJBeVoMtrG8XuOMBrTOI+4VQuYKUNUfMvTu8wzeNx/
>> IEMxhfezMkMMaRft+bD9J9jQNaKqGwVOsYk5dwYDacGvlBq/pqXWQ7MR60ZicM0wzJUOntRijVfE
>> bI9MDng90pQFMBOYG43ilOQU1wAUybTc4oXzoLTiEDxPZkoyOMPGLkUbBbv6SkF4Rc5k26nStVrG
>> +wz81gipE6R4/Lgi/jCcBcb0vgNcDQpIOdCjfNAcCGOYlUQpJt4HCiMzASwOvX+gNHS6CJFVdCZU
>> dSg8xiaTO02AxkEAGaCUbIEEyik0GkinarrBBYymDB76QVoeXuY5Bq70rp6bUSsS3w/cTBAiCukF
>> riNcURzmUYsUVeE4B8RNxbJLeQtzjwelYBkBxKifFEAvmHkAnD35QL58b3vhqJyyrSr8BWXoYGtd
>> FjuqxOOgiGlnYKEr3y32Rukh8vI5mrp0SidjViJ9VL+E7SzeivA8Kb1ucGe+Aqfq5L4ShQUwVgKS
>> 6oLKAIm4uWYHxpnBsMkHC0FCFqukiFEz2aaNZXTaiGJQli8BgGEqx0KMgvl1JQnwcrVNvqyFZql1
>> MTzelLoGtiso6O1tqok8gIlAcAjBrWKRNjLWwGIYzcW1gD1wqxL8vUxRg1MNbgciUggFFGDoqZb7
>> VB51PsXQL64HsOSkCTt5+d1jZb6iZwgqChS8vmgANh6i6CCvFdBHwqTAwmxT4xpmohsXKKK1Luva
>> CdhZ7qg+a2ui4vGL3HMg9CHn5xNbmq/+FAX/i7kinChIZoUil4A=
>>
>>
>>     
>
>
>
>   

Thread
bzr commit into mysql-next-mr-bugfixing branch (Dao-Gang.Qu:3192) Bug#53167Dao-Gang.Qu20 Aug
  • Re: bzr commit into mysql-next-mr-bugfixing branch (Dao-Gang.Qu:3192)Bug#53167He Zhenxing23 Aug
    • Re: bzr commit into mysql-next-mr-bugfixing branch (Dao-Gang.Qu:3192)Bug#53167Daogang Qu24 Aug