| Bug #86595 | MySQL Instance sudden restart | ||
|---|---|---|---|
| Submitted: | 6 Jun 2017 3:37 | Modified: | 12 Oct 2017 15:09 |
| Reporter: | Sik Yin Wong | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S1 (Critical) |
| Version: | 5.7.16 | OS: | Red Hat (RHEL6.8) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | failure in thread, innodb | ||
[6 Jun 2017 3:37]
Sik Yin Wong
[20 Jun 2017 16:58]
MySQL Verification Team
Hi! In order to verify the bug, we need the entire test case. We need the test case that always lead to the assert that InnoDB executed. Test cases are required, because, on most commodity hardware, high load leads to the temporary glitches in RAM, cache, controller or disk or their caches. More rarely, those asserts occur due to some inherent hardware failure. So, in order to be able to verify that this is a genuine bug, please, send us a set of commands that always lead to this assert. We can not proceed further without it. Thank you very much in advance.
[21 Jul 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".
[6 Sep 2017 8:51]
Sik Yin Wong
Due to company policy, it is infeasible to provide a test plan to repeat the bug. However, this case happens frequently in the previous month. Is there any information I can provide instead of the test plan, such as some kind of log after the database restart or enable some audit function etc. Thanks.
[6 Sep 2017 9:19]
MySQL Verification Team
Here is the stack trace, pretty printed. 0x0000000000f40b15: my_print_stacktrace at stacktrace.c:225 0x00000000007cdf24: handle_fatal_signal at signal_handler.cc:150 0x00000000007bccf4: ut_print_timestamp(_IO_FILE*) at ut0ut.cc:215 0x000000000113560b: btr_insert_on_non_leaf_level_func(unsigned long, dict_index_t*, unsigned long, dtuple_t*, char const*, unsigned long, mtr_t*) at btr0btr.cc:2167 0x000000000113b5f3: mem_heap_free at mem0mem.ic:528 (inlined by) btr_attach_half_pages at btr0btr.cc:2280 0x000000000113c185: btr_page_split_and_insert(unsigned long, btr_cur_t*, unsigned long**, mem_block_info_t**, dtuple_t const*, unsigned long, mtr_t*) at btr0btr.cc:2684 0x0000000001146948: btr_cur_pessimistic_insert(unsigned long, btr_cur_t*, unsigned long**, mem_block_info_t**, dtuple_t*, unsigned char**, big_rec_t**, unsigned long, que_thr_t*, mtr_t*) at btr0cur.cc:3428 0x000000000107cd2a: row_ins_sorted_clust_index_entry at row0ins.cc:2744 0x000000000109327b: row_insert_for_mysql_using_cursor at row0mysql.cc:1597 0x0000000000fbdcad: ha_innobase::intrinsic_table_write_row(unsigned char*) at ha_innodb.cc:7319 0x0000000000fcda75: ha_innobase::write_row(unsigned char*) at ha_innodb.cc:7340 0x000000000081bde7: handler::ha_write_row(unsigned char*) at handler.cc:7890 0x0000000000cd9c4e: end_write at sql_executor.cc:3365 0x0000000000cddc2e: THD::get_stmt_da() at sql_class.h:3381 (inlined by) evaluate_join_record at sql_executor.cc:1640 0x0000000000cdf2c3: sub_select(JOIN*, QEP_TAB*, bool) at sql_executor.cc:1291 0x0000000000cddc2e: THD::get_stmt_da() at sql_class.h:3381 (inlined by) evaluate_join_record at sql_executor.cc:1640 0x0000000000cdf2c3: sub_select(JOIN*, QEP_TAB*, bool) at sql_executor.cc:1291 0x0000000000e96698: JOIN_CACHE::generate_full_extensions(unsigned char*) at sql_join_buffer.cc:2218 0x0000000000e96ceb: JOIN_CACHE_BNL::join_matching_records(bool) at sql_join_buffer.cc:2101 0x0000000000e97036: JOIN_CACHE::join_records(bool) at sql_join_buffer.cc:1905 0x0000000000cddc2e: THD::get_stmt_da() at sql_class.h:3381 (inlined by) evaluate_join_record at sql_executor.cc:1640 0x0000000000cdf2c3: sub_select(JOIN*, QEP_TAB*, bool) at sql_executor.cc:1291 0x0000000000cddc2e: THD::get_stmt_da() at sql_class.h:3381 (inlined by) evaluate_join_record at sql_executor.cc:1640 0x0000000000cdf2c3: sub_select(JOIN*, QEP_TAB*, bool) at sql_executor.cc:1291 0x0000000000cde1ea: do_select at sql_executor.cc:945 (inlined by) JOIN::exec() at sql_executor.cc:199 0x0000000000d48630: st_select_lex_unit::set_executed() at sql_lex.h:662 (inlined by) handle_query(THD*, LEX*, Query_result*, unsigned long long, unsigned long long) at sql_select.cc:185 0x0000000000d09553: execute_sqlcom_select at sql_parse.cc:5143 0x0000000000d0cf18: mysql_execute_command(THD*, bool) at sql_parse.cc:2756 0x0000000000d0eccd: mysql_parse(THD*, Parser_state*) at sql_parse.cc:5559 0x0000000000d0fe4e: Parser_state::reset(char const*, unsigned long) at sql_lex.h:3645 (inlined by) dispatch_command(THD*, COM_DATA const*, enum_server_command) at sql_parse.cc:1506 0x0000000000d10ab4: do_command(THD*) at sql_parse.cc:997 0x0000000000de2e0c: handle_connection at connection_handler_per_thread.cc:300 0x0000000001252bb4: pfs_spawn_thread at pfs.cc:2191
[6 Sep 2017 9:34]
MySQL Verification Team
This seems to happen when a SELECT uses innodb intrinsic table. It seems the function btr_cur_pessimistic_insert returns an error of some kind, that is not expected. btr_cur_pessimistic_insert might return errors: o) error from btr_cur_ins_lock_and_undo (DB_WAIT_LOCK for example). o) DB_OUT_OF_FILE_SPACE o) DB_TOO_BIG_RECORD Anyway, please try a workaround to prevent crash :: [mysqld] internal-tmp-disk-storage-engine=MyISAM
[12 Sep 2017 15:09]
MySQL Verification Team
Hi! First of all, we need a fully repeatable test case. If the workaround works, it will help you, but it would not help us much.
[13 Oct 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".
