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

Assertion `id.page_no() < space.size' during recovery

    XMLWordPrintable

    Details

      Description

      This issue was happened while testing bb-10.5-thiru for MDEV-8139.
      Back trace is

       
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
      #1  0x000055705e6778b1 in __GI_abort () at abort.c:79
      #2  0x000055705e66742a in __assert_fail_base (fmt=0x55705e7eea38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55705cd0811a "id.page_no() < space.size",
          file=file@entry=0x55705cd07918 "/home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc", line=line@entry=1254,
          function=function@entry=0x55705cd099a0 <buf_flush_check_neighbors(fil_space_t const&, page_id_t&, IORequest::flush_t)::__PRETTY_FUNCTION__> "page_id_t buf_flush_check_neighbors(const fil_space_t&, page_id_t&, IORequest::flush_t)") at assert.c:92
      #3  0x000055705e6674a2 in __GI___assert_fail (assertion=0x55705cd0811a "id.page_no() < space.size", file=0x55705cd07918 "/home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc", line=1254,
          function=0x55705cd099a0 <buf_flush_check_neighbors(fil_space_t const&, page_id_t&, IORequest::flush_t)::__PRETTY_FUNCTION__> "page_id_t buf_flush_check_neighbors(const fil_space_t&, page_id_t&, IORequest::flush_t)") at assert.c:101
      #4  0x000055705c56af9c in buf_flush_check_neighbors (space=..., id=..., flush=IORequest::FLUSH_LIST) at /home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc:1254
      #5  0x000055705c56b93b in buf_flush_try_neighbors (page_id=..., flush=IORequest::FLUSH_LIST, n_flushed=164, n_to_flush=200) at /home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc:1392
      #6  0x000055705c56c7dd in buf_do_flush_list_batch (min_n=200, lsn_limit=18446744073709551615) at /home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc:1640
      #7  0x000055705c56cd03 in buf_flush_batch (lru=false, min_n=200, lsn_limit=18446744073709551615, n=0x2fef7a41bc40) at /home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc:1697
      #8  0x000055705c56d0ec in buf_flush_do_batch (lru=false, min_n=200, lsn_limit=18446744073709551615, n=0x2fef7a41bc40) at /home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc:1800
      #9  0x000055705c56d322 in buf_flush_lists (min_n=200, lsn_limit=18446744073709551615, n_processed=0x2fef7a41bc98) at /home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc:1858
      #10 0x000055705c570640 in buf_flush_page_cleaner () at /home/mleich/bb-10.5-thiru/storage/innobase/buf/buf0flu.cc:2746
      #11 0x000000006fde86db in start_thread (arg=0x2fef7a41c700) at pthread_create.c:463
      #12 0x000055705e758a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Error log contains the following:

      [rr 99536 5963]2020-07-14 12:31:07 0 [Warning] InnoDB: Parent table of FTS auxiliary table test/FTS_0000000000000159_BEING_DELETED not found.
      [rr 99536 5967]2020-07-14 12:31:07 0 [Warning] InnoDB: Parent table of FTS auxiliary table test/FTS_0000000000000159_BEING_DELETED_CACHE not found.
      [rr 99536 5971]2020-07-14 12:31:07 0 [Warning] InnoDB: Parent table of FTS auxiliary table test/FTS_0000000000000159_CONFIG not found.
      [rr 99536 5975]2020-07-14 12:31:07 0 [Warning] InnoDB: Parent table of FTS auxiliary table test/FTS_0000000000000159_DELETED not found.
      [rr 99536 5979]2020-07-14 12:31:07 0 [Warning] InnoDB: Parent table of FTS auxiliary table test/FTS_0000000000000159_DELETED_CACHE not found.
      [rr 99536 5983]2020-07-14 12:31:07 0 [Warning] InnoDB: Parent table of FTS auxiliary table test/FTS_0000000000000159_00000000000001df_INDEX_1 not found.
      [rr 99536 5987]2020-07-14 12:31:07 0 [Warning] InnoDB: Parent table of FTS auxiliary table test/FTS_0000000000000159_00000000000001df_INDEX_2 not found.
      

      Problem:
      =======

      During recovery, InnoDB encounters INIT_PAGE for page 1. So it does buf_page_create() and add the page 1 to flush list. It never encounters INIT_PAGE for page0 and FSP_SIZE redo log also. So InnoDB never sets the size for the tablespace. While flushing, InnoDB fails in assert `id.page_no() < space.size'

      Root cause is that InnoDB does mtr_commit separately for page 1 before doing commit for page 0 and FSP_SIZE

      In the reported case, fsp_header_init() is being called from dict_build_table_def_step()

                      mtr.start();
                      mtr.set_named_space(table->space);
                      fsp_header_init(table->space, FIL_IBD_FILE_INITIAL_SIZE, &mtr);
                      mtr.commit();
      

      Inside fsp_header_init(), InnoDB does fsp_fill_free_list() to add the new extent to free list.

      In fsp_fill_free_list(), the following code does have seperate mtr to commit ibuf bitmap page.

                              /* Initialize the ibuf bitmap page in a separate
                              mini-transaction because it is low in the latching
                              order, and we must be able to release its latch.
                              Note: Insert-Buffering is disabled for tables that
                              reside in the temp-tablespace. */
                              if (space->purpose != FIL_TYPE_TEMPORARY) {
                                      mtr_t   ibuf_mtr;
       
                                      mtr_start(&ibuf_mtr);
                                      ibuf_mtr.set_named_space(space);
       
                                      /* Avoid logging while truncate table
                                      fix-up is active. */
                                      if (srv_is_tablespace_truncated(space->id)) {
                                              mtr_set_log_mode(
                                                      &ibuf_mtr, MTR_LOG_NO_REDO);
                                      }
       
                                      const page_id_t page_id(
                                              space->id,
                                              i + FSP_IBUF_BITMAP_OFFSET);
       
                                      block = buf_page_create(
                                              page_id, page_size, &ibuf_mtr);
       
                                      buf_page_get(
                                              page_id, page_size, RW_SX_LATCH,
                                              &ibuf_mtr);
       
                                      buf_block_dbg_add_level(block, SYNC_FSP_PAGE);
       
                                      fsp_init_file_page(space, block, &ibuf_mtr);
       
                                      ibuf_bitmap_page_init(block, &ibuf_mtr);
       
                                      mtr_commit(&ibuf_mtr);
      
      

      So InnoDB should commit everything within same mtr or handle the scenario during recovery.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              marko Marko Mäkelä
              Reporter:
              thiru Thirunarayanan Balathandayuthapani
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: