| Bug #86822 | MySQL crash InnoDB: Assertion failure .. in file rem0rec.cc line 578 | ||
|---|---|---|---|
| Submitted: | 26 Jun 2017 4:06 | Modified: | 13 Aug 2017 13:40 |
| Reporter: | Artyom Konovalenko | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | 5.7.18 | OS: | Oracle Linux (Percona build mysqld 5.7.18-15-log) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | _Z15row_search_mvccPh15page_cur_mode_tP14row_prebuilt_tmm, double free or corruption | ||
[26 Jun 2017 4:06]
Artyom Konovalenko
[26 Jun 2017 10:29]
MySQL Verification Team
Thank you for the bug report. Please test with MySQL binaries, also you have not commented if you tried to check some remarks done by the error message: have you checked hardware problems, have you checked corruption data?, also how was the process you applied in the upgrade process?. Try to find a repeatable test case. Thanks.
[28 Jun 2017 2:07]
Artyom Konovalenko
Hi. Thank you for reply. > Please test with MySQL binaries, Ok, I will run MySQL binaries from your site. > also you have not commented if you tried to check some remarks done by the error message: have you checked hardware problems This is virtual guest. There were no hardware related issues on the host when the problem appeared > have you checked corruption data? Yes. We did full logical dump/restore of the data after first crash (so recreated ibd files) and there were definitely no corruption at the moment of 2nd crash. > also how was the process you applied in the upgrade process?. We followed Percona recommended upgrade procedure: https://www.percona.com/doc/percona-server/LATEST/upgrading_guide_56_57.html What we did: - demoted server to slave - stopped mysqld - removed all mysql-server, mysql-client, and shared libs binaries (without deps) - installed 5.7.18 version of the above - started the server in standalone mode (slave with stopped replication) - ran mysql_upgrade script (there were no errors) - restarted mysqld - started slave, - waited for replication to be completed - promoted server to master > Try to find a repeatable test case. Thanks. I'll try, but no guarantee.
[28 Jun 2017 15:33]
MySQL Verification Team
Hi! You need to provide us with additional info. Have your run mysql_upgrade and have you altered your partitions to native partitions ???? If not, please, follow those steps.
[29 Jun 2017 1:36]
Artyom Konovalenko
We had run mysql_upgrade, then we altered original tables (there were no partitions initially). It was one big alter, that changed: - primary key - added column - changed default charset for table (was utf8, new latin1) - changed block_size (was=default, new=2) - added native partitions old definition (before alter): CREATE TABLE `table1` ( `id` bigint(20) NOT NULL, `format` varchar(32) NOT NULL, `meta` text NOT NULL, `created_date` timestamp NULL DEFAULT NULL, PRIMARY KEY (`format`,`id`), ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED; new definition (after alter): CREATE TABLE `table1` ( `id` bigint(20) NOT NULL, `format` varchar(32) CHARACTER SET utf8 NOT NULL, `meta` text CHARACTER SET utf8 NOT NULL, `created_date` timestamp NULL DEFAULT NULL, `namespace_id` int(5) NOT NULL DEFAULT '7', PRIMARY KEY (`namespace_id`,`format`,`id`), KEY `format` (`format`,`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=1 PARTITION BY LIST COLUMNS(namespace_id) (PARTITION p_1 VALUES IN (1) ENGINE = InnoDB, PARTITION p_2 VALUES IN (2) ENGINE = InnoDB, PARTITION p_3 VALUES IN (3) ENGINE = InnoDB, PARTITION p_4 VALUES IN (4) ENGINE = InnoDB, PARTITION p_5 VALUES IN (5) ENGINE = InnoDB, PARTITION p_6 VALUES IN (6) ENGINE = InnoDB, PARTITION p_7 VALUES IN (7) ENGINE = InnoDB, PARTITION p_8 VALUES IN (8) ENGINE = InnoDB, PARTITION p_9 VALUES IN (9) ENGINE = InnoDB) P.S. I know, the primary key is ugly (contains varchar, too long), but that's all we have.
[11 Jul 2017 15:17]
MySQL Verification Team
Hi ! Thank you for your answers. If Innodb crashes, then we must take a close look at the problem. In order to repeat the crash, please make a dump of the table, gzip it or bzip it and upload it to this bug, by using "Files" tab. Thank you very much in advance.
[13 Jul 2017 7:22]
Artyom Konovalenko
Hi. I installed clean mysqld 5.7.18 from RPM from mysql site and made it master (there were recent crash with the similar backtrace on Percona build). Now waiting for crash to happen on clean mysqld, then I update the ticket if it happens again (usually it takes 1-2 weeks from crash to crash). Then I provide you more information. Best regards, Arty
[13 Jul 2017 13:40]
MySQL Verification Team
Hi! Thank you for your effort to repeat the bug with our binaries. If you are successful, please upload the dump of the table in pre-ALTER format, by using "Files" tab of this bug.
[14 Aug 2017 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
