MySQL常规日志排错
2013-05-14 23:37
134 查看
MySQL版本:5.0.82
测试环境中,开发人员告诉我,数据库无法insert插入提示 lock wait timeout;
第一印象是被某个语句锁住,多次执行show full processlist 查看对同一个表执行的操作,查看 show engine innodb status\G 只显示被锁住的语句,未显示被哪个语句锁住(在官方5.5版本中同样也是显示这样的情况,在mariadb分支中,显示的信息比较详细!);
这个时候采取的办法是打开 innodb 监控器,innodb_lock_monitor 16s 检测一次,在测试程序的时候仍然一无所获;此时我们只能开始怀疑 os问题,cpu负载,磁盘IO;由于网络是隔离的,起初怀疑网络原因,导致连接经常断掉,调整为同一个网络仍然无效;后来将数据全部mysqldump出来(这样排除了磁盘未损坏的问题,至少能读取)
这种情况只能去怀疑程序的问题,java 采用连接池,当初怀疑某个未commit的线程被复用的问题;这次打开了 general log; 显示的格式为: time thread id SQL语句;这次我们有较大的收获;通过比较commit 与 set autocommit 个数不同,对应到具体线程,即可知道哪个线程未提交事务;这个时候剩下的就是让开发人员修改代码啦。
小结:对于官方原版的数据库。5.5 及以下版本的锁信息 显示的是不全面的,可以的话切换为mariadb版本;针对锁信息的查看,可以使用5.5中新功能:performance_schema ,这个锁问题很方便;general log 要好好利用,他是诊断故障,测试性能的救命稻草!!
测试环境中,开发人员告诉我,数据库无法insert插入提示 lock wait timeout;
第一印象是被某个语句锁住,多次执行show full processlist 查看对同一个表执行的操作,查看 show engine innodb status\G 只显示被锁住的语句,未显示被哪个语句锁住(在官方5.5版本中同样也是显示这样的情况,在mariadb分支中,显示的信息比较详细!);
这个时候采取的办法是打开 innodb 监控器,innodb_lock_monitor 16s 检测一次,在测试程序的时候仍然一无所获;此时我们只能开始怀疑 os问题,cpu负载,磁盘IO;由于网络是隔离的,起初怀疑网络原因,导致连接经常断掉,调整为同一个网络仍然无效;后来将数据全部mysqldump出来(这样排除了磁盘未损坏的问题,至少能读取)
这种情况只能去怀疑程序的问题,java 采用连接池,当初怀疑某个未commit的线程被复用的问题;这次打开了 general log; 显示的格式为: time thread id SQL语句;这次我们有较大的收获;通过比较commit 与 set autocommit 个数不同,对应到具体线程,即可知道哪个线程未提交事务;这个时候剩下的就是让开发人员修改代码啦。
小结:对于官方原版的数据库。5.5 及以下版本的锁信息 显示的是不全面的,可以的话切换为mariadb版本;针对锁信息的查看,可以使用5.5中新功能:performance_schema ,这个锁问题很方便;general log 要好好利用,他是诊断故障,测试性能的救命稻草!!
相关文章推荐
- MySQL之——Replication的容量、故障排错以及多线程方式传输二进制日志
- mysql开启常规日志
- 开启mysql的常规查询日志
- mysql故障排错临时打开通用日志和慢查询日志
- MySQL日志文件
- CentOS 6.5下利用Rsyslog+LogAnalyzer+MySQL部署日志服务器
- MySQL慢查询日志和错误日志按天轮询
- mysql清理二进制日志 (xf版)
- MySQL日志
- mysql日志管理三.查询日志
- mysql复制日志删除设置和解决主键冲突的方法
- php慢日志和mysql慢日志
- MySQL之慢查询日志
- Mysql慢日志、缓存配置
- mysql慢查询日志分析工具
- MySQL优化之——日志
- MySQL的binlog日志恢复(转)
- MYSQL LOGBIN 数据日志恢复数据库随笔
- 开启MySQL的binlog日志
- mysql 数据库优化 慢查询日志的开启