MySQL - Lock wait timeout exceeded
今天突然出了个奇怪的问题,原本正常启动的项目,在什么都没有修改的情况下,启动到一半的时候会卡住几分钟,几分钟后又成功启动了,刚好是卡在Quartz那里,还以为出什么奇奇怪怪的幺蛾子了,一看日志,数据库锁住了~ 记录一下解决方法。
转载 : http://blog.csdn.net/mchdba/article/details/38313881
1,查看数据库的隔离级别:
mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)
mysql>
2,去查看先当前库的线程情况:
mysql> show full processlist;
+----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+-----------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+-----------------------+
| 1 | event_scheduler | localhost | NULL | Daemon | 9635385 | Waiting on empty queue | NULL |
| 9930577 | business_web | 192.168.1.21:45503 | business_db | Sleep | 153 | | NULL |
| 9945825 | business_web | 192.168.1.25:49518 | business_db | Sleep | 43 | | NULL |
| 9946322 | business_web | 192.168.1.23:44721 | business_db | Sleep | 153 | | NULL |
| 9960167 | business_web | 192.168.3.28:2409 | business_db | Sleep | 93 | | NULL |
| 9964484 | business_web | 192.168.1.21:24280 | business_db | Sleep | 7 | | NULL |
| 9972499 | business_web | 192.168.3.28:35752 | business_db | Sleep | 13 | | NULL |
| 10000117 | business_web | 192.168.3.28:9149 | business_db | Sleep | 6 | | NULL |
| 10002523 | business_web | 192.168.3.29:42872 | business_db | Sleep | 6 | | NULL |
| 10007545 | business_web | 192.168.1.21:51379 | business_db | Sleep | 155 | | NULL |
......
+----------+-----------------+-------------------+-----------------+-------------+---------+-------------------------+-----------------------+
没有看到正在执行的慢SQL记录线程,再去查看innodb的事务表INNODB_TRX,看下里面是否有正在锁定的事务线程,看看ID是否在show full processlist里面的sleep线程中,如果是,就证明这个sleep的线程事务一直没有commit或者rollback而是卡住了,我们需要手动kill掉。
mysql> SELECT * FROM information_schema.INNODB_TRX\G;
*************************** 1. row ***************************
trx_id: 20866
trx_state: LOCK WAIT
trx_started: 2014-07-31 10:42:35
trx_requested_lock_id: 20866:617:3:3
trx_wait_started: 2014-07-30 10:42:35
trx_weight: 2
trx_mysql_thread_id: 9930577
trx_query: delete from dltask where id=1
trx_operation_state: starting index read
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 376
trx_rows_locked: 1
trx_rows_modified: 0
trx_concurrency_tickets: 0
trx_isolation_level: READ COMMITTED
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0
3,看到有这条9930577的sql,kill掉,执行kill 9930577;
mysql> kill 9930577;
Query OK, 0 rows affected (0.00 sec)
mysql>
然后再去查询INNODB_TRX表,就没有阻塞的事务sleep线程存在了,如下所示:
mysql> SELECT * FROM INNODB_TRX\G;
Empty set (0.00 sec)
ERROR:
No query specified
mysql>
再去执行update语句,就能正常执行了,如下所示:
mysql> update order_info set province_id=15 ,city_id= 1667 where order_from=10 and order_out_sn='1407261241xxxx';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql>
MySQL - Lock wait timeout exceeded的更多相关文章
- mysql Lock wait timeout exceeded; try restarting transaction解决
前面已经了解了InnoDB关于在出现锁等待的时候,会根据参数innodb_lock_wait_timeout的配置,判断是否需要进行timeout的操作,本文档介绍在出现锁等待时候的查看及分析处理: ...
- MySql Lock wait timeout exceeded该如何处理? (转载)
转载 https://ningyu1.github.io/site/post/75-mysql-lock-wait-timeout-exceeded/ 这个问题我相信大家对它并不陌生,但是有很多人对它 ...
- Mysql Lock wait timeout exceeded; try restarting transaction的问题
今天在后台跑任务的时候,发现了数据库报错1205 - Lock wait timeout exceeded; try restarting transaction.问题原因是因为表的事务锁,以下是解决 ...
- mysql Lock wait timeout exceeded; try restarting transaction
查看innodb的事务表INNODB_TRX,看下里面是否有正在锁定的事务线程,看看ID是否在show full processlist里面的sleep线程中,如果是,就证明这个线程事务一直没有com ...
- mysql 操作突然断网,MySQL: “lock wait timeout exceeded”
show processlist;//显示所有进程select * from information_schema.innodb_trx;//查询锁的进程-- kill 310;//杀掉锁进程
- MySQL事务锁等待超时 Lock wait timeout exceeded; try restarting transaction
工作中处理定时任务分发消息时出现的问题,在查找并解决问题的时候,将相关的问题博客收集整理,在此记录下,以便之后再遇到相同的问题,方便查阅. 问题场景 问题出现的场景: 在消息队列处理消息时,同一事务内 ...
- mysql死锁,等待资源,事务锁,Lock wait timeout exceeded; try restarting transaction解决
前面已经了解了InnoDB关于在出现锁等待的时候,会根据参数innodb_lock_wait_timeout的配置,判断是否需要进行timeout的操作,本文档介绍在出现锁等待时候的查看及分析处理: ...
- MySQL事务锁问题-Lock wait timeout exceeded
转载:https://cloud.tencent.com/developer/article/1356959 问题现象: 接口响应时间超长,耗时几十秒才返回错误提示,后台日志中出现Lock wai ...
- 排查mysql innodb Lock wait timeout exceeded; try restarting transaction的问题
OMG写的时候崩溃了一次. 触发关注这个问题的事情是 我们在使用pt-online-schedule 改表的时候总是拿不到锁,并且报出mysql innodb Lock wait timeout ex ...
随机推荐
- python文件的读写总结
读写文件是最常见的IO操作.Python内置了读写文件的函数,用法和C是兼容的. 读写文件前,我们先必须了解一下,在磁盘上读写文件的功能都是由操作系统提供的,现代操作系统不允许普通的程序直接操作磁盘, ...
- BUUCTF CRYPTO部分题目wp
对密码学了解不多,做一下熟悉熟悉 1,看我回旋踢 给的密文synt{5pq1004q-86n5-46q8-o720-oro5on0417r1} 简单的凯撒密码,用http://www.zjslove. ...
- elasticsearch 嵌套对象使用Multi Match Query、query_string全文检索设置
参考: https://www.elastic.co/guide/en/elasticsearch/reference/1.7/mapping-nested-type.html https://sta ...
- redis出现MISCONF Redis is configured to save RDB snapshots...的错误
今天重启服务器在连接redis数据库时突然报错: MISCONF Redis is configured to save RDB snapshots, but it is currently not ...
- linux文件管理--压缩打包
目录 linux文件管理--压缩打包 1.压缩打包介绍 2.gzip压缩工具 3.zip压缩工具 注意: 4.tar压缩工具 5.tar生产案例实践 linux文件管理--压缩打包 1.压缩打包介绍 ...
- How can I check the last time stats was run on Oracle without using OEM
All of the following data dictionary tables have a LAST_ANALYZED column (replace * with USER/ALL/DBA ...
- 二、sqlyog的使用
1. 创建数据库. 注意字符集 2.创建表 注意 表名.引擎名.字符集
- window常见操作
cmd查看进程命令 nestat -aon|findstr "端口" 杀进程: taskkill /f /pid 端口号 /f参数强制杀进程 通过注册表删除桌面图标 cmd re ...
- webpack第一节(1)
跟着慕课网的老师做了下笔记 webpack是一个前端打包工具 它可以优化网页.例如 页面模块化加载.图片优化.css.js压缩等等. 模块化加载也就是懒加载,按需加载,以前的模式是所以得css写在一起 ...
- Delphi 字符串函数SysUtils单元 AnsiSameStr、AnsiSameText、AnsiCompareStr、AnsiCompareText、AnsiCompareFileName、AnsiUpperCase、AnsiLowerCase、AnsiUpperCaseFileName、AnsiLowerCaseFileName、AnsiPos、AnsiQuotedStr
USES 单元 SysUtils 非 StrUtils AnsiSameStr.AnsiSameText.AnsiCompareStr.AnsiCompareText.AnsiCompareFileN ...