[MDEV-12352] InnoDB shutdown should not be blocked by a large transaction rollback Created: 2017-03-24  Updated: 2020-08-25  Resolved: 2017-12-13

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 5.5, 10.0, 10.1, 10.2
Fix Version/s: 10.0.34, 10.1.30, 10.2.12, 10.3.3

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 1
Labels: performance, rollback, shutdown

Issue Links:
Problem/Incident
causes MDEV-21217 innodb_force_recovery=2 may wrongly a... Closed
Relates
relates to MDEV-12091 Shutdown fails to wait for rollback o... Closed
relates to MDEV-14705 systemd: EXTEND_TIMEOUT_USEC= to avoi... Closed
Sprint: 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.)



 Comments   
Comment by Marko Mäkelä [ 2017-04-11 ]

On a related note, we could consider introducing a configuration option to control the transaction rollback on shutdown. Currently, there only exists the parameter value innodb_fast_shutdown=0 which not only waits for all transactions to be rolled back (or committed), but also waits for the purge of transaction history to complete. It could be useful to detach the two from each other.

My preference would be a server-level parameter for all transactional storage engines, say, shutdown_rollback=ON. This parameter would control whether to rollback aborted transactions on shutdown. Inside InnoDB, it would affect both the background rollback and the rollback of transasactions of client connections that were killed due to shutdown.

Generated at Thu Feb 08 07:57:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.