MySQL,RDS,锁定超时

时间:2015-03-19 22:48:21

标签: python mysql amazon-rds

我正在创建一个使用RDS的MySQL实例的应用程序,由节点和python程序访问。节点方面很好,直到几天前,python方面也很好。现在python程序在简单查询上失败了:

我正在通过上下文管理器运行查询,如下所示:

with safeExecute(dbConnection.cursor()) as cursor:
    log('about to run SQL')
    sql = """UPDATE ts
             SET ts.fails = ts.fails + 1,
                ts.attempts = ts.attempts + 1
             WHERE ts.id = 206 """
    cursor.execute(sql)
    log('sql executed')

@contextmanager
def safeExecute(cursor):
    try:
        yield cursor
        log('attempting to commit')
        dbConnection.commit()
        log('committed')
    except MySQLdb.OperationalError as e:
            dbConnection.rollback()
        log("--CRITICAL--")    
        traceback.print_exc()
        sys.exit(1)
    except Exception as e:
        dbConnection.rollback()
        log("Caught DB exception: ")
        traceback.print_exc()
        sys.stdout.flush()
    finally:
        cursor.close()  

控制台日志如下所示:

about to run sql
sql executed 
attempting to commit
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
      OR
OperationalError: (2006, 'MySQL server has gone away')

奇怪的是,这个错误是相当间歇的,并不会总是达到同一点。有时attempting to commit会出现,有时则永远不会超过cursor.execute()

我有另外两个类似的查询,只是更新各种计数器。它有时会毫无问题地执行所有3个,有时会卡在其中一个上面。这个应用程序不应该有任何并发​​问题,它花费约30秒处理,然后按顺序运行上面的这些查询(因此不应该是任何竞争条件)。

然而,查看打开的表格似乎没有锁定(当我执行以下操作时查询正在运行)

mysql> show open tables where in_use>0;
+------------+------------+--------+-------------+
| Database   | Table      | In_use | Name_locked |
+------------+------------+--------+-------------+
| tearsheets | tearsheets |      1 |           0 |
+------------+------------+--------+-------------+

Show processlist也没有透露任何内容。实际上它表明连接正在休眠:

 ID      | USER       | HOST            | DB         | COMMAND | TIME | STATE     | INFO                                                              |
 1230255 | <username>   | <ip-address> | <ts table> | Sleep   |   42 |           | NULL

state为空白,那里没有文字......

如何进一步调试?我不确定还有什么要看。

1 个答案:

答案 0 :(得分:0)

我通过简单地在每次事务之后关闭连接,然后为下一次数据库交互重新打开一个新事务来解决这个问题。不确定我的问题的原因是什么,但现在似乎正在起作用。