11

突然之间（没有对相关代码进行任何更改），我们通过活动记录收到锁定错误，例如：

ActiveRecord::StatementInvalid: Mysql2::Error: Lock wait timeout exceeded; 
try restarting transaction: UPDATE `items` SET `state` = 'reserved', `updated_at` = '2012-09-15 17:58:21' WHERE `items`.`id` = 248220

和

ActiveRecord::StatementInvalid: Mysql2::Error: Lock wait timeout exceeded; 
try restarting transaction: DELETE FROM `sessions` WHERE `sessions`.`id` = 41997883

我们没有在这两种模型中进行自己的交易，所以唯一的交易是内置的 rails 交易。流量或请求量没有激增。

这些错误似乎是当“新”查询尝试在锁定的表上运行并且必须等待时，我们如何看到它在等待什么？我们如何确定代码的哪一部分正在发出长时间锁定表的查询？

关于我们可以在哪里查看或如何调查其原因的任何想法？

4

1 回答 1

4

看看 pt-deadlock-logger，虽然与 rails 没有直接关系，但应该可以为您提供大量有关发生死锁的信息。

http://www.percona.com/doc/percona-toolkit/2.1/pt-deadlock-logger.html

有一些很好的例子： http ://www.mysqlperformanceblog.com/2012/09/19/logging-deadlocks-errors/

该工具非常简单实用。它监视 SHOW ENGINE INNODB STATUS 的输出并将新死锁记录到文件或我们以后可以查看的表中。让我们用一个例子来看看它是如何工作的。

文章继续解释说，这可以记录有关死锁的信息，例如涉及的查询、哪些主机、线程 ID 等。

我还发现在查询前加上注释有助于跟踪，例如文件或模块、函数，甚至是哪个用户。查询注释通常会一直传递给这样的诊断工具，并且可以帮助追踪代码的哪些部分以及在哪些情况下导致死锁。

于 2012-09-22T00:19:00.923 回答