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

Corruption during online table-rebuilding ALTER of ROW_FORMAT=REDUNDANT tables (assertion failure or "index is corrupt")

    XMLWordPrintable

    Details

      Description

      The basic test case is this:

      --source include/have_innodb.inc
       
      CREATE TABLE t1 (i INT) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
      --send
        OPTIMIZE TABLE t1;
       
      --connect (con1,localhost,root,,test)
       
      INSERT INTO t1 VALUES (1);
       
      --connection default
      --reap
       
      # Cleanup
      --disconnect con1
      --connection default
      DROP TABLE t1;
      

      It fails well for me, but still it's non-deterministic, so run it with --repeat=N.
      I think this sync point makes it (more) reliable. I'm not sure it's the most precise place to synchronize, but I wanted to use an existing sync point:

      --source include/have_innodb.inc
      --source include/have_debug_sync.inc
       
      CREATE TABLE t1 (i INT) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
       SET debug_sync= 'alter_table_inplace_after_lock_downgrade SIGNAL there_now WAIT_FOR go';
      --send
        OPTIMIZE TABLE t1;
       
      --connect (con1,localhost,root,,test)
       
      SET debug_sync= 'now WAIT_FOR there_now';
      INSERT INTO t1 VALUES (1);
      SET debug_sync= 'now SIGNAL go';
       
      --connection default
      --reap
       
      # Cleanup
      --disconnect con1
      --connection default
      SET debug_sync= 'RESET';
      DROP TABLE t1;
      

      10.2 debug ca3c8d9b58fdc267b7c4df1ce3afde5ec6599344

      mysqld: /data/src/10.2/storage/innobase/row/row0log.cc:3118: dberr_t row_log_table_apply_ops(que_thr_t*, row_merge_dup_t*, ut_stage_alter_t*): Assertion `0' failed.
      170923 18:49:16 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f76015f5ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x000055afddb128b8 in row_log_table_apply_ops (thr=0x7f75ac0360b0, dup=0x7f75fc0cf080, stage=0x7f75ac160100) at /data/src/10.2/storage/innobase/row/row0log.cc:3118
      #9  0x000055afddb12bea in row_log_table_apply (thr=0x7f75ac0360b0, old_table=0x7f75ac067f38, table=0x7f75ac133280, stage=0x7f75ac160100) at /data/src/10.2/storage/innobase/row/row0log.cc:3186
      #10 0x000055afdd9f753a in ha_innobase::inplace_alter_table (this=0x7f75ac12fe28, altered_table=0x7f75ac133280, ha_alter_info=0x7f75fc0cf3b0) at /data/src/10.2/storage/innobase/handler/handler0alter.cc:6483
      #11 0x000055afdd5109e1 in handler::ha_inplace_alter_table (this=0x7f75ac12fe28, altered_table=0x7f75ac133280, ha_alter_info=0x7f75fc0cf3b0) at /data/src/10.2/sql/handler.h:3768
      #12 0x000055afdd507c56 in mysql_inplace_alter_table (thd=0x7f75ac000b00, table_list=0x7f75ac012508, table=0x7f75ac12f220, altered_table=0x7f75ac133280, ha_alter_info=0x7f75fc0cf3b0, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7f75fc0cf420, alter_ctx=0x7f75fc0cffe0) at /data/src/10.2/sql/sql_table.cc:7331
      #13 0x000055afdd50cf98 in mysql_alter_table (thd=0x7f75ac000b00, new_db=0x0, new_name=0x0, create_info=0x7f75fc0d0be0, table_list=0x7f75ac012508, alter_info=0x7f75fc0d0b30, order_num=0, order=0x0, ignore=false) at /data/src/10.2/sql/sql_table.cc:9323
      #14 0x000055afdd50f6f6 in mysql_recreate_table (thd=0x7f75ac000b00, table_list=0x7f75ac012508, table_copy=false) at /data/src/10.2/sql/sql_table.cc:10099
      #15 0x000055afdd590c8d in admin_recreate_table (thd=0x7f75ac000b00, table_list=0x7f75ac012508) at /data/src/10.2/sql/sql_admin.cc:58
      #16 0x000055afdd593f15 in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *)) (thd=0x7f75ac000b00, tables=0x7f75ac012508, check_opt=0x7f75ac005588, operator_name=0x55afdded4cc8 "optimize", lock_type=TL_WRITE, open_for_modify=true, repair_table_use_frm=false, extra_open_options=0, prepare_func=0x0, operator_func=(int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0x55afdd6b2150 <handler::ha_optimize(THD*, st_ha_check_opt*)>, view_operator_func=0x0) at /data/src/10.2/sql/sql_admin.cc:1022
      #17 0x000055afdd595260 in Sql_cmd_optimize_table::execute (this=0x7f75ac012b20, thd=0x7f75ac000b00) at /data/src/10.2/sql/sql_admin.cc:1364
      #18 0x000055afdd44299a in mysql_execute_command (thd=0x7f75ac000b00) at /data/src/10.2/sql/sql_parse.cc:6203
      #19 0x000055afdd44724a in mysql_parse (thd=0x7f75ac000b00, rawbuf=0x7f75ac012438 "OPTIMIZE TABLE t1", length=17, parser_state=0x7f75fc0d2200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7875
      #20 0x000055afdd434efb in dispatch_command (command=COM_QUERY, thd=0x7f75ac000b00, packet=0x7f75ac13ea71 "", packet_length=17, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1812
      #21 0x000055afdd433875 in do_command (thd=0x7f75ac000b00) at /data/src/10.2/sql/sql_parse.cc:1360
      #22 0x000055afdd580ae1 in do_handle_one_connection (connect=0x55afe0590340) at /data/src/10.2/sql/sql_connect.cc:1354
      #23 0x000055afdd58086e in handle_one_connection (arg=0x55afe0590340) at /data/src/10.2/sql/sql_connect.cc:1260
      #24 0x000055afdd99d616 in pfs_spawn_thread (arg=0x55afe059a8b0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
      #25 0x00007f760353a494 in start_thread (arg=0x7f75fc0d3700) at pthread_create.c:333
      #26 0x00007f76016b293f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      10.2 non-debug

      Table	Op	Msg_type	Msg_text
      test.t1	optimize	note	Table does not support optimize, doing recreate + analyze instead
      test.t1	optimize	error	Index for table 't1' is corrupt; try to repair it
      test.t1	optimize	status	Operation failed
      Warnings:
      Error	1034	Index for table 't1' is corrupt; try to repair it
      

      The problem appeared in 10.2 tree with this commit:

      commit f5a833c3e085524585d1ae5b8303c168f075dab3
      Author: Marko Mäkelä <marko.makela@mariadb.com>
      Date:   Wed Sep 13 15:41:04 2017 +0300
       
          Clean up the logging of virtual column values in table-rebuilding online ALTER
      

        Attachments

          Activity

            People

            Assignee:
            marko Marko Mäkelä
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: