MySQL abort due to over 600s semaphore waiting, triggered by the drop table SQL
Bug #1074255 reported by
Hui Liu
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
It's the first time for the Percona-5.5(.18) caught this bug on product environment. Detail info could refer to the attached alert.log.
The basic scenario is:
Drop tables xxx_001/0064 sequentially, most of the tables are dropped successfully, but at last of the task, mysqld aborts, as several drop_table SQL wait for some semaphore over 600 secs.
The load data is started after the batch drop_table task, while as the drop tables are blocked, these load SQL could be seen in trx lists, but it has no relation with this issue.
Changed in percona-server: | |
status: | Incomplete → New |
tags: | added: xtradb |
Changed in percona-server: | |
assignee: | nobody → Valerii Kravchuk (valerii-kravchuk) |
Changed in percona-server: | |
assignee: | Valerii Kravchuk (valerii-kravchuk) → nobody |
To post a comment you must log in.
Here are the threads that semaphore shows: _lock, owned by 1383319872
1331538240 waits for row0purge.c:680 for 241s on &dict_operation
1321048384 waits for buf0flu.c:1335 for 1s on &block->lock, owned by 1383319872 (1321048384 is main thread)
1368525120 waits for fsp0fsp.c:3144 for 231s on &dict_sys->mutex
1354787136 waits for dict0dict.c:742 for 23s on &dict_sys->mutex
I think the key threads are: 1331538240 , 1383319872 and 1392122. freeze_ data_dictionary over 600s.
1331538240 triggered the problem and I am not sure it's the purge thread. It waits dict_operation_lock in row_mysql_
1383319872 owns the dict_operation_ lock, which lasted for ever, and seen from the last time write lock info, it was last owned in row_mysql_ lock_data_ dictionary of row_drop_ table_for_ mysql, which should be the DDL, but the DDL is 1392122.