How to resolve and debug MySQL Error: ER_LOCK_WAIT_TIMEOUT: Lock wait timeout exceeded; try restarting transaction

Question

I've read a few posts here on this, but still do not understand how can I resolve the error. Also how do I decipher show engine innodb status output. I suspect its a deadlock or a transaction that never commits/rollbacks resulting in it holding the lock forever (is this possible?).

# show engine innodb status;
=====================================
2015-09-27 04:43:54 2b9cf470f700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 33 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 16140 srv_active, 0 srv_shutdown, 3941554 srv_idle
srv_master_thread log flush and writes: 3957687
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 25915
OS WAIT ARRAY INFO: signal count 25874
Mutex spin waits 1675, rounds 50212, OS waits 1581
RW-shared spins 24307, rounds 729240, OS waits 24278
RW-excl spins 16, rounds 1680, OS waits 56
Spin rounds per wait: 29.98 mutex, 30.00 RW-shared, 105.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 712274
Purge done for trx's n:o < 712178 undo n:o < 0 state: running but idle
History list length 1593
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 18286, OS thread handle 0x2b9cf470f700, query id 2307113 bb116-14-164-108.singnet.com.sg 116.14.164.108 meclub2359 init
show engine innodb status
---TRANSACTION 0, not started
MySQL thread id 18285, OS thread handle 0x2b9cf4444700, query id 2306954 bb116-14-164-108.singnet.com.sg 116.14.164.108 meclub2359 cleaning up
---TRANSACTION 712266, not started
MySQL thread id 18270, OS thread handle 0x2b9cf43c2700, query id 2307088 172.31.8.174 meclub2359 cleaning up
---TRANSACTION 712235, not started
MySQL thread id 18268, OS thread handle 0x2b9cf3896700, query id 2306757 172.31.8.174 meclub2359 cleaning up
---TRANSACTION 712268, not started
MySQL thread id 18267, OS thread handle 0x2b9cf4381700, query id 2307091 172.31.8.174 meclub2359 cleaning up
---TRANSACTION 712272, not started
MySQL thread id 5214, OS thread handle 0x2b9cf31dd700, query id 2307112 localhost 127.0.0.1 rdsadmin cleaning up
---TRANSACTION 712269, ACTIVE 31 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 18288, OS thread handle 0x2b9cf44c6700, query id 2307092 172.31.8.174 meclub2359 updating
UPDATE stardate SET winnersSelected=1 WHERE id='6'
------- TRX HAS BEEN WAITING 31 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 4067 page no 3 n bits 72 index `PRIMARY` of table `ebdb`.`stardate` trx id 712269 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 16; compact format; info bits 0
 0: len 4; hex 00000006; asc     ;;
 1: len 6; hex 0000000addcd; asc       ;;
 2: len 7; hex 180000021d2d57; asc      -W;;
 3: len 30; hex 68747470733a2f2f73332d61702d736f757468656173742d312e616d617a; asc https://s3-ap-southeast-1.amaz; (total 62 bytes);
 4: len 30; hex 4d75736963616c204576656e696e67207769746820456c6c696520476f75; asc Musical Evening with Ellie Gou; (total 35 bytes);
 5: len 30; hex 4d75736963616c204576656e696e67207769746820456c6c696520476f75; asc Musical Evening with Ellie Gou; (total 35 bytes);
 6: len 30; hex 4d75736963616c204576656e696e67207769746820456c6c696520476f75; asc Musical Evening with Ellie Gou; (total 255 bytes);
 7: len 22; hex 53696e6761706f72650d0a4d6172696e612042617920; asc Singapore  Marina Bay ;;
 8: len 20; hex 52443230313530394d434d4543444153434d5346; asc RD201509MCMECDASCMSF;;
 9: len 4; hex 80000002; asc     ;;
 10: len 5; hex 9997295000; asc   )P ;;
 11: len 5; hex 999702a000; asc      ;;
 12: len 4; hex 8000000c; asc     ;;
 13: len 1; hex 81; asc  ;;
 14: len 5; hex 999706e345; asc     E;;
 15: len 5; hex 99972ee820; asc   .  ;;

------------------
---TRANSACTION 712213, ACTIVE 501 sec
5 lock struct(s), heap size 1184, 1 row lock(s), undo log entries 3
MySQL thread id 18284, OS thread handle 0x2b9cf3daa700, query id 2307007 172.31.8.174 meclub2359 cleaning up
Trx read view will not see trx with id >= 712249, sees < 712141
---TRANSACTION 712197, ACTIVE 574 sec
5 lock struct(s), heap size 1184, 1 row lock(s), undo log entries 3
MySQL thread id 18283, OS thread handle 0x2b9cf4403700, query id 2306959 172.31.8.174 meclub2359 cleaning up
Trx read view will not see trx with id >= 712241, sees < 712141
---TRANSACTION 712184, ACTIVE 595 sec
5 lock struct(s), heap size 1184, 1 row lock(s), undo log entries 3
MySQL thread id 18281, OS thread handle 0x2b9cf468d700, query id 2306856 172.31.8.174 meclub2359 cleaning up
Trx read view will not see trx with id >= 712240, sees < 712141
---TRANSACTION 712141, ACTIVE 935 sec
7 lock struct(s), heap size 1184, 12 row lock(s), undo log entries 19
MySQL thread id 18279, OS thread handle 0x2b9cf4485700, query id 2306383 172.31.8.174 meclub2359 cleaning up
Trx read view will not see trx with id >= 712146, sees < 712146
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
562 OS file reads, 295536 OS file writes, 202242 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.24 writes/s, 0.18 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 1241027, node heap has 2 buffer(s)
0.06 hash searches/s, 0.27 non-hash searches/s
---
LOG
---
Log sequence number 87135734
Log flushed up to   87135734
Pages flushed up to 87135734
Last checkpoint at  87135734
0 pending log writes, 0 pending chkp writes
133514 log i/o's done, 0.09 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 641744896; in additional pool allocated 0
Dictionary memory allocated 264646
Buffer pool size   38271
Free buffers       20250
Database pages     18019
Old database pages 6631
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 423, not young 82
0.00 youngs/s, 0.00 non-youngs/s
Pages read 521, created 17502, written 131006
0.00 reads/s, 0.00 creates/s, 0.12 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 18019, unzip_LRU len: 0
I/O sum[4]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
4 read views open inside InnoDB
Main thread process no. 14465, id 47953069967104, state: sleeping
Number of rows inserted 55739, updated 14635, deleted 309, read 1463461
0.00 inserts/s, 0.03 updates/s, 0.00 deletes/s, 35.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

Does it appear like there are some queries hanging? Output of show processlist

If so how do I debug more where in my application causes this? I am using AWS RDS, Elastic Beanstalk, NodeJS/SailsJS.

UPDATE

I noticed this problem only occurs on one row. When I attempt to UPDATE stardate SET winnersSelected=1 WHERE id='6'.

UPDATE

I found that a change in code closing a connection works. But still curious, how do I tell from the output above whats the cause? I think it will be useful. I am not sure if this is the cause.

For example, I see

---TRANSACTION 0, not started
MySQL thread id 18285, OS thread handle 0x2b9cf4444700, query id 2306954 bb116-14-164-108.singnet.com.sg 116.14.164.108 meclub2359 cleaning up

---TRANSACTION 712235, not started
MySQL thread id 18268, OS thread handle 0x2b9cf3896700, query id 2306757 172.31.8.174 meclub2359 cleaning up

Why does it seem like the cleanup is taking so long? Should I be concerned?

---TRANSACTION 712269, ACTIVE 31 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 18288, OS thread handle 0x2b9cf44c6700, query id 2307092 172.31.8.174 meclub2359 updating
UPDATE stardate SET winnersSelected=1 WHERE id='6'
------- TRX HAS BEEN WAITING 31 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 4067 page no 3 n bits 72 index `PRIMARY` of table `ebdb`.`stardate` trx id 712269 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 16; compact format; info bits 0
 0: len 4; hex 00000006; asc     ;;
 1: len 6; hex 0000000addcd; asc       ;;
 2: len 7; hex 180000021d2d57; asc      -W;;
 3: len 30; hex 68747470733a2f2f73332d61702d736f757468656173742d312e616d617a; asc https://s3-ap-southeast-1.amaz; (total 62 bytes);
 4: len 30; hex 4d75736963616c204576656e696e67207769746820456c6c696520476f75; asc Musical Evening with Ellie Gou; (total 35 bytes);
 5: len 30; hex 4d75736963616c204576656e696e67207769746820456c6c696520476f75; asc Musical Evening with Ellie Gou; (total 35 bytes);
 6: len 30; hex 4d75736963616c204576656e696e67207769746820456c6c696520476f75; asc Musical Evening with Ellie Gou; (total 255 bytes);
 7: len 22; hex 53696e6761706f72650d0a4d6172696e612042617920; asc Singapore  Marina Bay ;;
 8: len 20; hex 52443230313530394d434d4543444153434d5346; asc RD201509MCMECDASCMSF;;
 9: len 4; hex 80000002; asc     ;;
 10: len 5; hex 9997295000; asc   )P ;;
 11: len 5; hex 999702a000; asc      ;;
 12: len 4; hex 8000000c; asc     ;;
 13: len 1; hex 81; asc  ;;
 14: len 5; hex 999706e345; asc     E;;
 15: len 5; hex 99972ee820; asc   .  ;;

Can I say from the above output that the query UPDATE stardate SET winnersSelected=1 WHERE id='6' is being blocked? But how can I tell by what?

Answer 1

When dealing with difficult MySQL diagnostic issues, quite often you have to resort to gdb. You can do something like this:

gdb -ex "set pagination 0" -ex "thread apply all bt" \
  --batch -p $(pidof mysqld)

Then you dig through the list of stack traces, and with a little bit of knowledge of the source you can figure out what is going on.

A likely cause for a long "cleaning up" is some critical lock somewhere being hogged by another thread, and there could be a multitude of reasons for that. If you paste the stack trace, I'll be able to give you an idea of what is happening.

Deadlock in InnoDB is actually a legitimate scenario. It is designed in a way that in some circumstances, hopefully rare, the locking algorithm finds itself deadlocked. The problem is mitigated by the lock wait timeout - when it is reached, a transaction is aborted to get out of the deadlock. In theory, ideal InnoDB client code should be written to retry all transactions should they fail due to a deadlock. In practice, it can be very difficult to refactor a large code base to conform to this principle, but I would still recommend picking a few critical battles and refactoring the most troublesome code to conform.

To avoid deadlocks, commit your transactions frequently and avoid updating records in unpredictable order. This would include, of course, a proper cleanup of connections - as you have observed in your case. If you do not close a connection, you could have a seemingly innocent scenario like this:

• BEGIN
• SELECT
• no activity for a long time

The problem is that the transaction locks the rows it has read with the SELECT, and will not unlock them until COMMIT/ROLLBACK.

If you have a lot of messy code that is difficult to clean up, you may want to consider moving away from using a connection pool. MySQL has a very low session initiation overhead and can handle frequent reconnects quite well. This way inactive connections will likely be closed upon application request termination automatically (I am assuming some things about the code that would be common in a large number of applications) and you will not have dangling connections with an open transaction that are being returned to the connection pool in that state.