| Bug #85327 | MySQL crash on InnoDB: Failing assertion: btr_page_get_prev(get_page, mtr) == bu | ||
|---|---|---|---|
| Submitted: | 6 Mar 2017 18:09 | Modified: | 17 Feb 2022 13:40 |
| Reporter: | Jose Chinchilla | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
| Version: | 5 | OS: | Linux (btr_page_get_prev and btr_page_get_next) |
| Assigned to: | CPU Architecture: | Any | |
[6 Mar 2017 18:09]
Jose Chinchilla
[7 Mar 2017 16:42]
MySQL Verification Team
Hi! What you see are the consequences of the InnoDB page corruption. For your information, the crashes that you experience, are forced by InnoDB. InnoDB HAS to crash the server in order to prevent that bad data gets written into the table(s). This is due to the ACID conformance. Corruption is discovered, most likely, because the root page of the index tree of the clustered index of db1.table10 is full of zero bytes. This can be caused by the errors in the RAM modules, errors in the disk system, errors in the disk controller or the errors in the cache on the controller or the disk. In order to locate the problem, you should first analyze your RAM modules. If you use ECC RAM, two bits checking, one bit correcting, then problem is not there. If you do not use the reliable ECC RAM, then you have to check your RAM very thoroughly, with specialized tools, which will take lot's of time. Next on the list is checking hard disks or SSD. If you have mirrored disks , or disks with parity, then the report should be logged. Otherwise, you are facing another extensive testing. Checking of the dedicated caches should be done in accordance with manufacturers recommendations. Last, but not least, check the system logs, for the last couple of weeks for the report of any hardware problem. Especially check logs around the time when asserts occurred.
[8 Mar 2017 2:41]
Jose Chinchilla
Hi Sinisa, thank you very much for your answer, we will be using our hardware diagnostic tool, I'll be in contact if I find something related.
[9 Apr 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".
[17 Feb 2022 8:13]
Weejar zhang
we are also hit it . slave database crash. 2022-02-17T12:15:54.786989+08:00 5 [Note] Multi-threaded slave statistics for channel '': seconds elapsed = 130; events assigned = 11587807233; worker queues filled over overrun level = 706483; waited due a Worker queue full = 72764; waited due the total size = 12263875; waited at clock conflicts = 384564899141400 waited (count) when Workers occupied = 31291857 waited when Workers occupied = 380547160900 2022-02-17 12:16:52 0x7f9f48448700 InnoDB: Assertion failure in thread 140322088978176 in file btr0cur.cc line 325 InnoDB: Failing assertion: btr_page_get_next( latch_leaves.blocks[0]->frame, mtr) == page_get_page_no(page) InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 04:16:52 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=2097152 read_buffer_size=1048576 max_used_connections=11 max_threads=214 thread_count=6 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 443178 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f9f280008c0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7f9f48447e30 thread_stack 0x40000 /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x2c)[0xeb750c] /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x451)[0x7a5601] /lib64/libpthread.so.0(+0xf100)[0x7fa05e3df100] /lib64/libc.so.6(gsignal+0x37)[0x7fa05cfe05f7] /lib64/libc.so.6(abort+0x148)[0x7fa05cfe1ce8] /usr/local/mysql/bin/mysqld[0x775ee3] /usr/local/mysql/bin/mysqld(_Z20btr_cur_latch_leavesP11buf_block_tRK9page_id_tRK11page_size_tmP9btr_cur_tP5mtr_t+0x8ac)[0x109790c] /usr/local/mysql/bin/mysqld(_Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t+0x19fc)[0x109e90c] /usr/local/mysql/bin/mysqld(_Z30btr_pcur_restore_position_funcmP10btr_pcur_tPKcmP5mtr_t+0x249)[0x10a5459] /usr/local/mysql/bin/mysqld[0xfeb230] /usr/local/mysql/bin/mysqld(_Z14row_purge_stepP9que_thr_t+0x659)[0xfedb59] /usr/local/mysql/bin/mysqld(_Z15que_run_threadsP9que_thr_t+0x83a)[0xf9d64a] /usr/local/mysql/bin/mysqld(srv_worker_thread+0x255)[0x10236a5] /lib64/libpthread.so.0(+0x7dc5)[0x7fa05e3d7dc5] /lib64/libc.so.6(clone+0x6d)[0x7fa05d0a11cd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0): Connection ID (thread ID): 0 Status: NOT_KILLED
[17 Feb 2022 13:40]
MySQL Verification Team
Hi All, Please read our comments on the most probable cause of this assert. Errors in hardware or OS can be diagnosed or they can be transient. Glitches that are transient can not be diagnosed. But, if you use reliable hardware, most of all, ECC RAM 2 bytes checking, 1 byte correcting, you will be much safer. Otherwise, we can not do anything without a proper and fully repeatable test case.
