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

innodb_undo_log_truncate=ON is blocking page writes




      The implementation of innodb_undo_log_truncate=ON in trx_purge_truncate_history() is interfering with log checkpoint and page write performance.

      Before MDEV-13564, we used the MySQL 5.7 implementation, which would force a full flush of the entire buffer pool and a sharp log checkpoint. In MDEV-13564 we changed it so that only the pages of the being-truncated undo tablespace would be removed from the buffer pool, but no log checkpoint would be needed.

      There is a less intrusive, lazy approach: We can actually let the 'garbage' undo log pages remain in the buffer pool, just like we do on DROP TABLE or DROP INDEX or when freeing pages in any operation: Simply, if the newest modification to a page (FIL_PAGE_LSN) is older than the LSN of the latest tablespace rebuild, we will discard the page, just like in MDEV-15528 we do for pages whose underlying file page has been freed. With this approach, there is no need for trx_purge_truncate_history() to traverse the buffer pool.

      For the similar case of shrinking the InnoDB system tablespace (MDEV-14795), there would not be a complete tablespace rebuild (like there is with innodb_undo_log_truncate=ON), so we must only discard pages that are beyond the end of the current tablespace size; their FIL_PAGE_LSN must be older than the latest LSN of shrinking the FSP_SIZE. I think that we can do that by relaxing the logic around invoking fil_invalid_page_access_msg() in fil_space_t::io().


        Issue Links



              marko Marko Mäkelä
              marko Marko Mäkelä
              1 Vote for this issue
              4 Start watching this issue



                Git Integration

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