故障分析：全局读锁一直没有释放

原创已于 2022-10-25 14:59:58 修改 · 733 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库 #java

于 2022-10-25 13:16:54 首次发布

mysql 专栏收录该内容

27 篇文章

订阅专栏

博客围绕MySQL备份时出现的问题展开。指出线上需开启锁监控相关设置，备份时使用参数会使MySQL执行全局锁，若有长查询运行，FTWRL会被阻塞，进而阻塞DML操作。还介绍了排查方法，如开启慢日志、查看锁表、查出锁源SQL语句等。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

FLUSH TABLES WITH READ LOCK

ps aux | grep mysqldump 

show processlist;
show open tables where in_use > 0;

线上没有开启 performance_schema 的 instruments 和 consumers（PS：这个对于锁监控很重要，一定记得打开）。如果开启了 performance_schema，可以通过 metadata_locks 查到相关锁记录，这个我们在后面的复现中看一下。

select * from metadata_locks;
select * from threads order by processlist_time desc limit 10;

原因

mysql备份时使用--master-data参数在SQL文件的头部会写入binlog和position信息，所以在执行备份前mysql需要执行flush tables。flush tables with read lock 全局锁锁住整个数据库。如果数据库中有一个长查询在运行，那么FTWRL就不能获得，会被阻塞，进而阻塞所有的DML操作。

排查

开启慢日志:

SET GLOBAL log_slow_queries = ON; 
SET GLOBAL long_query_time = 3;
set global  slow_query_log_file='/opt/mysql/slow.log'

查看锁表


select * from metadata_locks;
select * from threads order by processlist_time desc limit 10;

查出锁源 SQL 语句


SELECT THREAD_ID, SQL_TEXT AS '锁源当前执行的SQL语句' ,CURRENT_SCHEMA AS '数据库' FROM performance_schema.`events_statements_current` 
WHERE thread_id IN (SELECT THREAD_ID FROM performance_schema.threads pt WHERE processlist_id IN (SELECT blocking_pid FROM sys.innodb_lock_waits));

show full processlist；