10人参与 • 2025-07-24 • Mysql
mysql 5.7.19 版本出现 semaphore wait has lasted > 600 seconds
错误,意味着 innodb 内部某些线程等待信号量超过了10分钟,导致数据库挂起崩溃。
针对这个问题,排查和定位的思路及步骤如下:
mysql版本:
服务器硬件与资源状况:
数据库负载情况:
具体业务场景:
确认报错线程对应的源码文件和行号:
mtr0mtr.cc
,row0ins.cc
等,分别代表:
mtr0mtr.cc
:多版本事务相关管理(mini-transaction)row0ins.cc
:行插入相关代码这些提示可能表明在插入操作中出现了阻塞。
semaphore wait
块)可以通过查看5.7.19版本源码对应文件(mysql官方github或者源码包)定位:
mtr0mtr.cc line 567
涉及mini-transaction相关锁等待,可能是innodb内部的metadata锁或缓冲池访问竞争。
row0ins.cc line 193
插入行时等待信号量,可能是插入缓冲区竞争或插入锁等待。
show processlist
看是否存在长时间未提交的事务。information_schema.innodb_trx
查看当前活动事务。高并发大批量写入,缓冲池页锁争用严重。
调整 innodb 参数,如:
innodb_thread_concurrency
innodb_lock_wait_timeout
innodb_buffer_pool_size
(确保足够大,避免频繁刷盘)iostat
, vmstat
)检查磁盘负载和延迟。check table
检查相关表。启动mysql时添加:
[mysqld] innodb_print_all_deadlocks=on innodb_lock_wait_timeout=50
查看死锁详细信息。
performance_schema.data_locks
和 performance_schema.data_lock_waits
,定位锁资源。问题点 | 排查方法 | 解决措施 |
---|---|---|
长事务占用锁 | show processlist, innodb_trx | 关闭或优化长事务,合理拆分事务 |
高并发写压力大 | 观察缓冲池争用,线程锁等待 | 优化参数,分批写入,升级版本 |
磁盘io瓶颈 | iostat, vmstat | 优化存储,使用ssd,提高io性能 |
表空间或页损坏 | check table, innodb_force_recovery尝试 | 恢复数据,导出备份,重建表空间 |
innodb版本缺陷 | 官方bug报告,源码分析 | 升级mysql版本到最新稳定版 |
-- 查看当前阻塞事务 select * from information_schema.innodb_trx\g; -- 查看当前等待锁的线程 select * from performance_schema.data_locks where lock_status='waiting'; -- 查看进程列表,看长时间执行的sql show full processlist; -- 查看死锁日志(在错误日志中) -- 或启用 innodb_print_all_deadlocks=on 后捕获
先从当前活跃事务和锁等待入手排查。
结合innodb状态和系统io性能分析瓶颈。
若怀疑数据损坏,尝试使用 innodb_force_recovery
。
5.7.19版本较老,建议升级至5.7较新版本,或者8.0版本,获得更多稳定性和bug修复。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持代码网。
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论