关键字：分布式事务框架、分布式数据库 事务、分布式数据库产品

你是否会经常遇到MySQL hang了而不知所措？面对繁杂的callstack信息如何才能快速分析出原因？

本文将通过一个案例，介绍如何快速分析这类问题的方法。

当我们遇到MySQL hang的场景时，大概率是程序内部发生了mutex冲突造成的。这时我们需要在重启服务前，先搜集callstack信息。

pstack `pidof mysqld` > mysql_callstack

注意：mysqld需要包含符号表

有了callstack信息，我们便可以开始进行分析了。

分析步骤

1.  首先，在callstack日志筛选出每个线程调用inline_mysql_mutex_lock前的函数，以及对应的mutex代码位置，此处便是线程在等待的mutex。

请点击输入图片描述

2. 然后，从该函数向前遍历每个函数调用，寻找这些函数，看已经成功获得哪些mutex。

请点击输入图片描述

这里我用脚本对日志进行格式化处理，将每个函数都映射到了github的代码位置，点击链接可以直接跳转，使用Chrome浏览器配合sourcegraph查看代码也很香。

3. 最后，从日志中回溯每个上锁函数所对应的前端操作行为，并绘制一张关于线程持有和等待mutex的表格，便能直观的分析出函数的冲突关系。

请点击输入图片描述

总结

由于show binlog logs操作、purge binlog以及从读取 performance_schema读取会话变量几个操作并行发生产生mutex冲突，导致无法新建连接请求。

• show binary logs，持有LOCK_log，等待LOCK_index

• binlog purge，持有LOCK_index,  等待LOCK_thd_data

• 读取performance_schema.session_variables，持有LOCK_thd_data, LOCK_global_system_variables, 等待LOCK_log

• 新建连接，等待LOCK_global_system_variables

最终确认是binlog_transaction_dependency_*变量的读取需要获取LOCK_log锁，此处容易造成死锁，MySQL 5.7.25 修复了此问题。

关键字：分布式事务框架、分布式数据库 事务、分布式数据库产品