Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23874

Crash in ALTER TABLE ... IMPORT TABLESPACE for the table after instant ALTER was used on it

    XMLWordPrintable

Details

    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.

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              valerii Valerii Kravchuk
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.