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

Debug assertion failure on bootstrap with innodb_undo_tablespaces>107

Details

    Description

      Assertion with innodb-undo-tablespaces=108 or more

      ./mtr 1st --mysqld=--innodb-undo-tablespaces=108 
      

       
      2024-06-19 11:54:00 0 [Note] InnoDB: Database physically writes the file full: wait...
      2024-06-19 11:54:00 0 [Note] InnoDB: Data file .//undo107 did not exist: new to be created
      2024-06-19 11:54:00 0 [Note] InnoDB: Setting file .//undo107 size to 10.000MiB
      2024-06-19 11:54:00 0 [Note] InnoDB: Database physically writes the file full: wait...
      2024-06-19 11:54:00 0 [Note] InnoDB: Data file .//undo108 did not exist: new to be created
      2024-06-19 11:54:00 0 [Note] InnoDB: Setting file .//undo108 size to 10.000MiB
      2024-06-19 11:54:00 0 [Note] InnoDB: Database physically writes the file full: wait...
      mariadbd: /git/bb/storage/innobase/buf/buf0buf.cc:2602: buf_block_t* buf_page_get_gen(page_id_t, ulint, ulint, buf_block_t*, ulint, mtr_t*, dberr_t*): Assertion `mode == 9 ? __builtin_expect(recv_sys.recovery_on, (0)) || log_sys.get_lsn() < 50000 : !__builtin_expect(recv_sys.recovery_on, (0)) || recv_sys.after_apply' failed.
      240619 11:54:00 [ERROR] mysqld got signal 6 ;
       
      Server version: 11.1.6-MariaDB-debug source revision: d34289a3e269de69796a3309ce441af836776ef7
      ]
      /lib/x86_64-linux-gnu/libc.so.6(+0x22729)[0x7fe8c663b729]
      /lib/x86_64-linux-gnu/libc.so.6(+0x33fd6)[0x7fe8c664cfd6]
      buf/buf0buf.cc:2605(buf_page_get_gen(page_id_t, unsigned long, unsigned long, buf_block_t*, unsigned long, mtr_t*, dberr_t*))[0x55ba0c0e1a5b]
      log/log0recv.cc:3674(recv_sys_t::recover(page_id_t, mtr_t*, dberr_t*))[0x55ba0bcb2067]
      dict/dict0boot.cc:224(dict_boot())[0x55ba0c14d2c7]
      dict/dict0boot.cc:189(dict_create())[0x55ba0c14d0a9]
      srv/srv0start.cc:1505(srv_start(bool))[0x55ba0bf92746]
      handler/ha_innodb.cc:4207(innodb_init(void*))[0x55ba0bac6ad4]
      sql/handler.cc:694(ha_initialize_handlerton(st_plugin_int*))[0x55ba0b10203d]
      sql/sql_plugin.cc:1454(plugin_do_initialize(st_plugin_int*, unsigned int&))[0x55ba0a83729e]
      sql/sql_plugin.cc:1507(plugin_initialize(st_mem_root*, st_plugin_int*, int*, char**, bool))[0x55ba0a837c39]
      sql/sql_plugin.cc:1765(plugin_init(int*, char**, int))[0x55ba0a839764]
      sql/mysqld.cc:5291(init_server_components())[0x55ba0a3e9819]
      sql/mysqld.cc:5926(mysqld_main(int, char**))[0x55ba0a3ebad5]
      sql/main.cc:34(main)[0x55ba0a3d313d]
      /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fe8c663d083]
      
      

      Attachments

        Issue Links

          Activity

            I had added this debug assertion in MDEV-34212, which fixed a regression that had been introduced in MDEV-32042. The assertion is failing on the server bootstrap.

            The purpose of the assertion is to ensure that the special mode == BUF_GET_RECOVER is only being used during server bootstrap, or in early startup while there are no other users of the buffer pool. My assumption was that during server bootstrap, the log sequence number would not grow beyond 50000. I did not think of the overhead of creating undo log tablespaces. I relaxed the assertion and ran with the maximum value:

            ./mtr 1st --boot-rr --mysqld=--innodb-undo-tablespaces=127
            

            Curiously, there are no shutdown messages for the bootstrap (which confirms the finding that was made during the review of MDEV-33853, and maybe deserves another bug to be filed):

            11.1 d34289a3e269de69796a3309ce441af836776ef7

            2024-06-19 14:09:57 0 [Note] InnoDB: Doublewrite buffer not found: creating new
            2024-06-19 14:09:57 0 [Note] InnoDB: Opened 127 undo tablespaces
            2024-06-19 14:09:57 0 [Note] InnoDB: 128 rollback segments in 127 undo tablespaces are active.
            2024-06-19 14:09:57 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
            2024-06-19 14:09:57 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
            2024-06-19 14:09:57 0 [Note] InnoDB: log sequence number 0 (memory-mapped); transaction id 3
            2024-06-19 14:09:57 0 [Note] Plugin 'INNODB_TABLESPACES_ENCRYPTION' is disabled.
            2024-06-19 14:09:57 0 [Note] Plugin 'THREAD_POOL_STATS' is disabled.
            2024-06-19 14:09:57 0 [Note] Plugin 'unix_socket' is disabled.
            2024-06-19 14:09:57 0 [Note] Plugin 'wsrep_provider' is disabled.
            

            So, I had to resort to using

            rr replay var/log/bootstrap.rr/latest-trace
            

            continue
            print log_sys.lsn._M_i
            

            Thread 1 received signal SIGKILL, Killed.
            0x0000000070000002 in syscall_traced ()
            (rr) print log_sys.lsn._M_i
            $1 = 105625
            

            I think that the 50000 in the assertion expression had better be relaxed to 120000, to add some safety margin.

            marko Marko Mäkelä added a comment - I had added this debug assertion in MDEV-34212 , which fixed a regression that had been introduced in MDEV-32042 . The assertion is failing on the server bootstrap. The purpose of the assertion is to ensure that the special mode == BUF_GET_RECOVER is only being used during server bootstrap, or in early startup while there are no other users of the buffer pool. My assumption was that during server bootstrap, the log sequence number would not grow beyond 50000. I did not think of the overhead of creating undo log tablespaces. I relaxed the assertion and ran with the maximum value: ./mtr 1st --boot-rr --mysqld=--innodb-undo-tablespaces=127 Curiously, there are no shutdown messages for the bootstrap (which confirms the finding that was made during the review of MDEV-33853 , and maybe deserves another bug to be filed): 11.1 d34289a3e269de69796a3309ce441af836776ef7 2024-06-19 14:09:57 0 [Note] InnoDB: Doublewrite buffer not found: creating new 2024-06-19 14:09:57 0 [Note] InnoDB: Opened 127 undo tablespaces 2024-06-19 14:09:57 0 [Note] InnoDB: 128 rollback segments in 127 undo tablespaces are active. 2024-06-19 14:09:57 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ... 2024-06-19 14:09:57 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. 2024-06-19 14:09:57 0 [Note] InnoDB: log sequence number 0 (memory-mapped); transaction id 3 … 2024-06-19 14:09:57 0 [Note] Plugin 'INNODB_TABLESPACES_ENCRYPTION' is disabled. 2024-06-19 14:09:57 0 [Note] Plugin 'THREAD_POOL_STATS' is disabled. 2024-06-19 14:09:57 0 [Note] Plugin 'unix_socket' is disabled. 2024-06-19 14:09:57 0 [Note] Plugin 'wsrep_provider' is disabled. So, I had to resort to using rr replay var/log/bootstrap.rr/latest-trace continue print log_sys.lsn._M_i Thread 1 received signal SIGKILL, Killed. 0x0000000070000002 in syscall_traced () (rr) print log_sys.lsn._M_i $1 = 105625 I think that the 50000 in the assertion expression had better be relaxed to 120000, to add some safety margin.

            People

              marko Marko Mäkelä
              alice Alice Sherepa
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.