【问题标题】:How to handle MySQL deadlock situations on an application level?如何在应用程序级别处理 MySQL 死锁情况?
【发布时间】:2011-12-27 08:25:21
【问题描述】:

当 MySQL/InnoDB 发生死锁情况时,它会返回这个熟悉的错误:

'尝试获取锁时发现死锁;尝试重启事务'

所以我所做的是记录进入事务的所有查询,以便在事务中的语句失败时可以简单地重新发出它们。很简单。

问题:当您的查询依赖于先前查询的结果时,这不会很好。

例如:

START TRANSACTION;
INSERT INTO some_table ...;
-- Application here gets ID of thing inserted: $id = $database->LastInsertedID()
INSERT INTO some_other_table (id,data) VALUES ($id,'foo');
COMMIT;

在这种情况下,我不能简单地重新发出最初创建的交易。第一条 SQL 语句获取的 ID 在事务失败后不再有效,而是被第二条语句使用。同时,许多对象已经填充了来自事务的数据,然后当事务回滚时这些对象就变得过时了。当然,应用程序代码本身不会随数据库“回滚”。

问题是:如何在应用程序代码中处理这些情况? (PHP)

我假设两件事。如果您认为我走在正确的轨道上,请告诉我:

1) 由于数据库不能在所有情况下都逐字逐句地重新发出事务,所以我原来的解决方案不起作用,不应该使用。

2) 做到这一点的唯一好方法是将任何和所有事务发布代码包装在它自己的 try/catch 块中,并尝试重新发布代码本身,而不仅仅是 SQL。

感谢您的意见。你摇滚。

【问题讨论】:

    标签: php mysql database innodb deadlock


    【解决方案1】:

    交易可能会失败。死锁是一种失败的情况,在可序列化级别中也可能有更多失败。事务隔离问题是一场噩梦。试图避免失败是我认为的坏方法。

    我认为任何编写良好的事务代码都应该有效地为失败的事务做好准备。

    正如您所见,记录查询并重放它们不是解决方案,因为当您重新启动事务时,数据库已经移动。如果这是一个有效的解决方案,SQL 引擎肯定会为您做到这一点。对我来说,规则是:

    • 重做事务内部的所有读取(您在外部读取的任何数据都可能已被更改)
    • 抛出之前尝试的所有内容,如果您在事务之外编写了内容(日志、LDAP、SGBD 之外的任何内容),则应该因为回滚而取消它
    • 实际上重做所有事情 :-)

    这意味着重试循环。

    所以你有你的 try/catch 块,里面有事务。您需要添加一个 while 循环,可能尝试 3 次,如果代码的提交部分成功,则离开 while 循环。如果在 3 次重试之后事务仍然失败,那么向用户启动一个异常——这样你就不会尝试无限重试循环,实际上你可能遇到了一个非常大的问题——。请注意,您应该以不同的方式处理 SQL 错误和锁定或可序列化异常。 3 是任意数字,您可以尝试更多次数。

    这可能会给出类似的结果:

    $retry=0;
    $notdone=TRUE;
    while( $notdone && $retry<3 ) {
      try {
        $transaction->begin();
        do_all_the_transaction_stuff();
        $transaction->commit();
        $notdone=FALSE;
      } catch( Exception $e ) {
        // here we could differentiate basic SQL errors and deadlock/serializable errors
        $transaction->rollback();
        undo_all_non_datatbase_stuff();
        $retry++;
      }
    }
    if( 3 == $retry ) {
      throw new Exception("Try later, sorry, too much guys other there, or it's not your day.");
    }
    

    这意味着所有内容(读取、写入、功能性内容)都必须包含在 $do_all_the_transaction_stuff(); 中。暗示事务管理代码在控制器中,即 high-level-application-functional-main 代码,不会拆分为多个 low-level-database-access-models 对象 .

    【讨论】:

    • 要使其工作(并且应该),您还必须确保您不修改任何非数据库状态,例如全局变量等。或者如果您这样做,这些更改也需要发生异常时手动“回滚”(在适当的情况下使用 try/catch 块)。
    • 阿奇:没错。它可能会变得更加复杂,想象一下 LDAP 更新以反向方式重新滚动。当然,事务应该在高层而不是数据库层上处理。
    • 如果你不想打扰那个样板,你也可以使用TransactionalMutex。
    • 这真的很有帮助。特别是在我意识到我可以只写一次并为do_all_the_transaction_stuff 和undo_all_non_datatbase_stuff 使用匿名函数之后。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-04-22
    • 1970-01-01
    • 1970-01-01
    • 2012-02-19
    • 1970-01-01
    • 1970-01-01
    • 2013-12-03
    相关资源
    最近更新 更多