Bug #34132 | Crash when replaying binary log | ||
---|---|---|---|
Submitted: | 29 Jan 2008 13:58 | Modified: | 5 Mar 2008 13:01 |
Reporter: | Philip Stoev | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S1 (Critical) |
Version: | 5.1-BK | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
Tags: | simpler_testcase_needed |
[29 Jan 2008 13:58]
Philip Stoev
[29 Jan 2008 14:11]
Philip Stoev
Just replaying the crashing binlog statement (after the table has been created) causes an assertion: CREATE TABLE test.pinsdel2_tbl(id MEDIUMINT NOT NULL AUTO_INCREMENT, dt TIMESTAMP, user CHAR(255), uuidf LONGBLOB, fkid MEDIUMINT, filler VARCHAR(255), PRIMARY KEY(id))ENGINE=Maria PARTITION BY RANGE(id) SUBPARTITION BY hash(id) subpartitions 2 (PARTITION pa1 values less than (10), PARTITION pa2 values less than (20), PARTITION pa3 values less than (30), PARTITION pa4 values less than (40), PARTITION pa5 values less than (50), PARTITION pa6 values less than (60), PARTITION pa7 values less than (70), PARTITION pa8 values less than (80), PARTITION pa9 values less than (90), PARTITION pa10 values less than (100), PARTITION pa11 values less than MAXVALUE)/*!*/; BINLOG ' rSqfRxcBAAAAPAAAAPgDKQEAAB4AAAAAAAAABP/wBAAAdT/3REMSAAAOcm9vdEBsb2NhbGhvc3TJ uus+ rSqfRxMBAAAAPQAAADUEKQEAABgAAAAAAAAABHRlc3QADHBpbnNkZWwyX3RibAAGCQf+/AkPBf7/ BP8APA== rSqfRxkBAAAAewAAALAEKQEQABgAAAAAAAEABv/AvgAArCqfRw5yb290QGxvY2FsaG9zdCQAAABh YjVlNjc0ZTFmLWJlMTAtMmJhYS0xZDAwLTBjMjljODMxNGMLAAAbR29pbmcgdG8gdGVzdCBNQlIg Zm9yIE15U1FM '/*!*/; The assert happens if with both Maria and MyISAM in the CREATE TABLE.
[29 Jan 2008 18:26]
Philip Stoev
The issue is reproducible on the latest 5.1 BitKeeper treee.
[29 Jan 2008 20:33]
Sveta Smirnova
Thank you for the report. Verified as described.
[8 Feb 2008 18:50]
Sven Sandberg
Philip, about your second comment (the assert): I pasted your two queries (CREATE TABLE and BINLOG) to a client (started with mtr --start-and-exit rpl_ps). It didn't give an assert, just an error message: ERROR 1609 (HY000): The BINLOG statement of type `Write_rows` was not preceded by a format description BINLOG statement. This was with the current mysql-5.1-new-rpl tree. Did you get something else?
[8 Feb 2008 19:45]
Philip Stoev
Yes I now see that very recently a new error message ER_NO_FORMAT_DESCRIPTION_EVENT_BEFORE_BINLOG_STATEMENT has been introduced which is printed when trying the CREATE + BINLOG query combination.
[8 Feb 2008 20:28]
Sven Sandberg
Right, I should have known. But even after I add a BINLOG statement with a Format_description_log_event, it only gives an error message: BINLOG ' 9CmfRw8BAAAAZgAAAGoAAAAAAAQANS4xLjIzLW1hcmlhLWFscGhhLWRlYnVnLWxvZwAAAAAAAAAA AAAAAAAAAAAAAAAAAAD0KZ9HEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC '/*!*/; CREATE TABLE test.pinsdel2_tbl(id MEDIUMINT NOT NULL AUTO_INCREMENT, dt TIMESTAMP, user CHAR(255), uuidf LONGBLOB, fkid MEDIUMINT, filler VARCHAR(255), PRIMARY KEY(id))ENGINE=Maria PARTITION BY RANGE(id) SUBPARTITION BY hash(id) subpartitions 2 (PARTITION pa1 values less than (10), PARTITION pa2 values less than (20), PARTITION pa3 values less than (30), PARTITION pa4 values less than (40), PARTITION pa5 values less than (50), PARTITION pa6 values less than (60), PARTITION pa7 values less than (70), PARTITION pa8 values less than (80), PARTITION pa9 values less than (90), PARTITION pa10 values less than (100), PARTITION pa11 values less than MAXVALUE)/*!*/; Query OK, 0 rows affected, 2 warnings (0.58 sec) BINLOG ' rSqfRxcBAAAAPAAAAPgDKQEAAB4AAAAAAAAABP/wBAAAdT/3REMSAAAOcm9vdEBsb2NhbGhvc3TJ uus+ rSqfRxMBAAAAPQAAADUEKQEAABgAAAAAAAAABHRlc3QADHBpbnNkZWwyX3RibAAGCQf+/AkPBf7/ BP8APA== rSqfRxkBAAAAewAAALAEKQEQABgAAAAAAAEABv/AvgAArCqfRw5yb290QGxvY2FsaG9zdCQAAABh YjVlNjc0ZTFmLWJlMTAtMmJhYS0xZDAwLTBjMjljODMxNGMLAAAbR29pbmcgdG8gdGVzdCBNQlIg Zm9yIE15U1FM '/*!*/; ERROR 1032 (HY000): Can't find record in 'pinsdel2_tbl' Please try this on your side, and if you get other results, include the full error message and any logs.
[8 Feb 2008 20:32]
Philip Stoev
The assert was present in the 5.1 tree as of 29th of January, however I think it is gone now -- I get either ER_NO_FORMAT_DESCRIPTION_EVENT_BEFORE_BINLOG_STATEMENT or "Can't find record in 'pinsdel2_tbl'". I would say that this part of the bug report has been resolved.
[26 Feb 2008 19:05]
Sergey Vojtovich
Philip, I'm a bit lost - what kind of problem this bug is about? I was unable to repeat server crash using provided binlogs (both raw binlog and mysqlbinlog dump). According to discussion with Sven this problem seem to be resolved. If this bug is about assertion failure (thd->lock == 0), could you please provide repeatable test case? Is this problem repeatable with the main 5.1 tree? If this bug is about incorrect binary log (row event is not preceded by a Table_map_log_event), could you please provide repeatable test case? Is this problem repeatable with the main 5.1 tree?
[3 Mar 2008 18:37]
Sven Sandberg
Please note that BUG#29020 may be related. It is possible (but I don't know for sure) that a fix to BUG#29020 would fix this bug too.
[5 Mar 2008 13:01]
Mats Kindahl
This bug is a duplicate of BUG#29020 and will be fixed by the patch that that bug.
[5 Mar 2008 13:09]
Philip Stoev
Ok then, this only leaves the assertion, for which I will file a separate bug report once I have a repeatable test case. Any pointers as to what the assertion is supposed to safeguard are still welcome.