Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Incomplete
-
10.2.14
-
windows server 2012
Description
i seem to get this with ANY slow query or even DDL instruction on a large table. It's compounded by the server then insisting on doing a crash recovery which seems to take hours.
today a customer's server was running out of disk space so i (foolishly) tried to purge some now redundant audit stuff with a "delete where like". And now my customer looks like being without a server for an entire business day.
After about 3 hours of crashrecovery i stopped the service (windows btw) and set innodb_force_recovery but that has crapped on the tables. so now having to fetch 65gb from off-site backup.
Is there a setting to suppress the initial timeout and 'intentional crash'?
Now i admit it was my fault for running such an expensive command today but that is really much too easy to crash a production server. And as i said i've had same issue doing DDL (alter table) on v large tables (50gb)
nigelgomm, you are being hit by the InnoDB watchdog. It is catching a long wait for an InnoDB internal RW-lock or mutex. These should normally not be held for more than a few milliseconds. The option that you asked for is called innodb_fatal_semaphore_wait_threshold. Its default value is 600 seconds. A hung server would typically not be killed after 600 seconds sharp, but more like after 900 seconds (15 minutes).
Locks acquired by user transactions can be held for arbitrarily long times without InnoDB’s watchdog getting upset.
I would like to see more data so that we can reproduce and diagnose the issue. Can you upload the server error log?