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

Execute InnoDB crash recovery in the background



      InnoDB startup unnecessarily waits for recovered redo log records to be applied to the data files.

      In fact, normally while the function trx_sys_init_at_db_start() is executing, the pages that it is requesting from the buffer pool will have any recovered redo log applied to them in the background.

      Basically, we only need to remove or refactor some calls in the InnoDB server startup. The crash recovery would ‘complete’ at the time of the next redo log checkpoint is written.

      One of the code pieces that must be removed is this one:

      commit 5103b38fc3cbc73d4a66a1b21740c4d7498f4a67
      Author: Marko Mäkelä <marko.makela@mariadb.com>
      Date:   Wed Nov 15 06:51:19 2017 +0200
          Remove one more trace of innodb_file_format
          innobase_start_or_create_for_mysql(): Remove an unnecessary call
          that should have been removed as part of
          commit 0c92794db3026cda03218caf4918b996baab6ba6
          when the dirty read of the innodb_file_format tag was removed.
      diff --git a/storage/innobase/srv/srv0start.cc b/storage/innobase/srv/srv0start.cc
      index 988ddf1a759..4f8823ef36c 100644
      --- a/storage/innobase/srv/srv0start.cc
      +++ b/storage/innobase/srv/srv0start.cc
      @@ -2194,13 +2194,6 @@ innobase_start_or_create_for_mysql()
       	} else {
      -		/* Invalidate the buffer pool to ensure that we reread
      -		the page that we read above, during recovery.
      -		Note that this is not as heavy weight as it seems. At
      -		this point there will be only ONE page in the buf_LRU
      -		and there must be no page in the buf_flush list. */
      -		buf_pool_invalidate();
       		/* Scan and locate truncate log files. Parsed located files
       		and add table to truncate information to central vector for
       		truncate fix-up action post recovery. */

      However, if we apply this patch, crash recovery will start failing. The reason could be that we are accessing the InnoDB system and undo tablespace files before opening the redo logs:

      	ut_d(fil_space_get(0)->recv_size = srv_sys_space_size_debug);
      	err = srv_undo_tablespaces_init(create_new_db);
      		err = recv_recovery_from_checkpoint_start(flushed_lsn);

      If we first open the redo log files and then the persistent data files, then there should be no need to invalidate the buffer pool contents.

      Similarly, later in the startup, we should rewrite or remove recv_recovery_from_checkpoint_finish() so that it will not wait for any page flushing to complete. While doing this, we must also remove the buf_pool_t::flush_rbt and use the normal flushing mechanism that strictly obeys the ARIES protocol for write-ahead logging.


          Issue Links



              • Assignee:
                thiru Thirunarayanan Balathandayuthapani
                marko Marko Mäkelä
              • Votes:
                1 Vote for this issue
                6 Start watching this issue


                • Created: