Why MySQL Hung: A Mutex Deadlock Bug and Its Fix

Environment

CentOS 6.7 with MySQL Community Edition 5.5.24.

Problem

Monitoring stopped and client connections hung without error messages.

Investigation Steps

Login attempts Both TCP and socket connections hung:

mysql -h192.168.150.21 -P50001 -uabc -pabc

mysql -S /var/lib/mysql/mysql.sock -uabc -pabc

Check MySQL error log No entries indicating failure.

Collect thread stacks with pstack Run: pstack <mysqld_pid> > pstack.log The log showed many threads blocked on two different mutexes, suggesting a deadlock.

Threads 2 and 3 each waited on a distinct mutex.

Deep inspection with gdb Attach to the mysqld process: gdb -p <mysqld_pid> Running info thread confirmed that multiple threads were stuck on locks. Thread 2 waited on LOCK_index , thread 3 on LOCK_thread_count .

Source‑code analysis Examined the implementations of PURGE BINARY LOGS and RESET MASTER . The two commands acquire LOCK_thread_count and LOCK_index in opposite order, creating a circular wait when executed concurrently.

Root Cause

Concurrent execution of PURGE BINARY LOGS and RESET MASTER caused a lock‑order inversion, leading to a deadlock where all threads blocked on LOCK_index and LOCK_thread_count.

Resolution

The issue was fixed in later MySQL releases. Upgrading the server and migrating the data eliminated the deadlock and restored normal operation.