故障分析：全局讀鎖一直沒有釋放

• ​

  ​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;      

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；      

參考

• ​​MySQL備份導緻的waiting for global read lock​​

• ​​故障分析 | 全局讀鎖一直沒有釋放，發生了什麼​​