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=
>>
>>
>>
>
>
>
>
