[MDEV-23874] Crash in ALTER TABLE ... IMPORT TABLESPACE for the table after instant ALTER was used on it Created: 2020-10-02  Updated: 2021-11-01  Resolved: 2021-11-01

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.4.14
Fix Version/s: 10.4.22, 10.5.13, 10.6.5

Type: Bug Priority: Major
Reporter: Valerii Kravchuk Assignee: Marko Mäkelä
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Blocks
is blocked by MDEV-18543 IMPORT TABLESPACE fails after instant... Closed

 Description   

When .ibd tablespace is imported for the table without corresponding .cfg file, the following crash happens:

Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: 2020-09-30 20:50:29 36 [Note] InnoDB: Phase I - Update all pages
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: 2020-09-30 20:50:29 36 [Note] InnoDB: Sync to disk
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: 2020-09-30 20:50:29 36 [Note] InnoDB: Sync to disk - done!
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: 2020-09-30 20:50:29 36 [Note] InnoDB: Phase III - Flush changes to disk
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: 2020-09-30 20:50:29 36 [Note] InnoDB: Phase IV - Flush complete
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: 2020-09-30 20:50:29 36 [ERROR] InnoDB: Table `db.`t` is missing instant ALTER metadata
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: 200930 20:50:29 [ERROR] mysqld got signal 11 ;
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: This could be because you hit a bug. It is also possible that this binary
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: or one of the libraries it was linked against is corrupt, improperly built,
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: or misconfigured. This error can also be caused by malfunctioning hardware.
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: We will try our best to scrape up some info that will hopefully help
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: diagnose the problem, but since we have already crashed,
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: something is definitely wrong and this may fail.
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: Server version: 10.4.14-MariaDB-1:10.4.14+maria~bionic-log
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: key_buffer_size=134217728
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: read_buffer_size=131072
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: max_used_connections=2
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: max_threads=2002
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: thread_count=9
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: It is possible that mysqld could use up to
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 33237558 K bytes of memory
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: Hope that's ok; if not, decrease some variables in the equation.
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: Thread pointer: 0x7f3134000c08
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: Attempting backtrace. You can use the following information to find out
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: where mysqld died. If you see no messages after this, something went
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: terribly wrong...
 
Sep 30 20:50:29 db-nightly-primary-1 mysqld[12479]: stack_bottom = 0x7f3778347da8 thread_stack 0x49000
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55f8f5cb255e]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(handle_fatal_signal+0x515)[0x55f8f572dea5]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x128a0)[0x7f37c95618a0]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(+0xa32150)[0x55f8f58e2150]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(_Z34mysql_discard_or_import_tablespaceP3THDP10TABLE_LISTb+0x17b)[0x55f8f55ab14b]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(_ZN33Sql_cmd_discard_import_tablespace7executeEP3THD+0xad)[0x55f8f5608b8d]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0xf24)[0x55f8f551cb64]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x1ea)[0x55f8f552408a]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x13d5)[0x55f8f55264e5]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(_Z10do_commandP3THD+0x104)[0x55f8f5527c64]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x25e)[0x55f8f5604c3e]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(handle_one_connection+0x3d)[0x55f8f5604cfd]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /usr/sbin/mysqld(+0xdacf9a)[0x55f8f5c5cf9a]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7f37c95566db]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f37c7f78a3f]
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: Trying to get some variables.
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: Some pointers may be invalid and cause the dump to abort.
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: Query (0x7f3134010140): ALTER TABLE t IMPORT TABLESPACE
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: Connection ID (thread ID): 36
 
Sep 30 20:50:30 db-nightly-primary-1 mysqld[12479]: Status: NOT_KILLED

It may be so that not copying .cfg was a mistake, it maybe even known that one can not successfully import tablespace until it is rebuilt entirely after instant ALTER, but crash should NOT happen anyway.

 Comments   
Comment by Marko Mäkelä [ 2020-10-16 ]

We already have MDEV-18543 for the case that instant DROP COLUMN or instant permutation of columns had been used. Is this report duplicating that?

Comment by Marko Mäkelä [ 2021-11-01 ]

This was fixed by MDEV-18543.

Generated at Thu Feb 08 09:25:43 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.