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

InnoDB shutdown should not be blocked by a large transaction rollback

    XMLWordPrintable

Details

    • 10.2.11, 10.1.30

    Description

      At shutdown, the server initiates rollback for all transactions that were running on the active sessions. InnoDB shutdown would wait until the rollback of all these transactions is completed. This could take a very long time.

      This is perfectly valid for a slow shutdown (innodb_fast_shutdown=0), but not acceptable for a normal shutdown, let alone a crash-like shutdown (innodb_fast_shutdown=2).

      Unless innodb_fast_shutdown=0, InnoDB could just abort the rollback of every transaction, letting the rollback operation of the current undo log record finish. Then, on next startup, InnoDB would recover these incomplete transactions and roll back them in a background operation. Again, when InnoDB shutdown is initiated while a large recovered transaction is being rolled back in the background operation, that rollback should be aborted immediately. (With MDEV-12091 the server would wait for the currently executing rollback of a recovered transaction to finish.)

      Care should be taken to ensure that when the rollback is aborted by shutdown, we will mark the current position, so that on restart, effort will not be wasted to re-rollback already processed undo log records. (The rollback is an idempotent operation, but it can be expensive to process the same records over and over again.)

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              1 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.