Description:
I guess this is likely to be true of later versions, but noticed in MySQL 5.6.5.
I had a crash (probably a known issue) on a version of 5.6.5 that runs.
mysqld_safe restarts mysqld and this immediately tries to recover (innodb).
However, the server has a ~300GB database, and 2x16GB innodb redo log files so recovery can take ~2 hours even with the storage being on SSD.
It also appears to not be interruptable as I sent the process SIGTERM and it does not stop, and exit.
I would like to interrupt the process so I can update to a newer version of 5.6, but now I have to wait for the recovery to complete.
I don't want to do kill -9 <mysqld_pid> as the server is configured to enable core dumps and this would dump a 192GB core file which isn't ideal either.
So please add a feature so that SIGTERM is caught during startup Innodb recovery and this will allow the server to terminate "as cleanly as possible", even when in InnoDB recovery mode.
Logging shows:
InnoDB: Doing recovery: scanned up to log sequence number 8978398965248
InnoDB: Doing recovery: scanned up to log sequence number 8978400656369
InnoDB: Transaction 4184556500 was in the XA prepared state.
InnoDB: Transaction 4184556502 was in the XA prepared state.
InnoDB: 3 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 13 row operations to undo
InnoDB: Trx id counter is 4184556800
121001 8:07:52 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 13 14 15 16 17
How to repeat:
If the server crashes, while doing recovery send it the SIGTERM signal and notice that it does not interrupt the recovery process.
Suggested fix:
Make the recovery thread(s) recognise the SIGTERM signal, and interrupt the recovery process, hopefully making the mysqld process terminate (cleanly).
