我有一个dag,它运行4个任务,都是bash操作符。最近我转到了airflow版本1.10.2。我经常看到下面的错误-
ERROR - Scheduler heartbeat got an exception: (MySQLdb._exceptions.OperationalError) (1213, 'Deadlock found when trying to get lock; try restarting transaction') (Background on this error at: http://sqlalche.me/e/e3q8)
我使用mysql作为元数据
下面的死锁可以有两个或两个以上的实例吗?
START TRANSACTION
SELECT mycolumn FROM mytable WHERE myid IN (list-of-ids) FOR UPDATE
:
COMMIT
要记住的要点:
我的列是索引的
这是mariaDB/innoDB
只涉及一个表(mytable)
例A:
Thread 1:
START TRANSACTION
SELECT mycolumn FROM mytable WHERE myid IN (100,200) FOR UPDATE
:
COMMIT
Thread 2
在查询包含UPDATE和JOIN的语句时,我们将得到以下错误:
Statements writing to a table with an auto-increment column after selecting
from another table are unsafe because the order in which rows are
retrieved determines what (if any) rows will be written.
This order cannot be predicted and may differ on master and the slave
假设我试图在mysql (Innodb)中执行以下UPDATE语句:
UPDATE main SET name = "Ralph" WHERE rowid=19283
在执行此语句之前,是否有方法在运行此更新之前查看rowid=19283上是否存在行/表级别的锁?或者,处理死锁的应用策略是捕获异常,然后在事实发生后处理它们?我发现一旦达到死锁,在没有非常循环的逻辑的情况下更新该行通常是不可能的,因此我正在查看是否可以在潜在的UPDATE/INSERT语句之前检测到死锁。
我有以下查询(所有表都是innoDB)
INSERT INTO busy_machines(machine)
SELECT machine FROM all_machines
WHERE machine NOT IN (SELECT machine FROM busy_machines)
and machine_name!='Main'
LIMIT 1
当我在线程中运行它时,这会导致死锁,显然是因为内部select,对吧?
我得到的错误是:
(1213
我使用的是mysql 5.0.92。最近,我们有许多插入到一个表的死锁,向其中插入(以及更新或删除)行的速度相对较快。我已经在StackOverflow、mysql文档和论坛上研究了这些问题,但并不了解这个问题。令我困惑的一件事是,根据innodb的状态,其中一个表没有锁定任何资源。
下面是SHOW INNODB STATUS的输出
*** (1) TRANSACTION:
TRANSACTION 0 2326105503, ACTIVE 0 sec, process no 18871, OS thread id 1078532416 inserting
mysql tables in use
我们已经安装了mariadb和列存储引擎,从过去几周开始,在重新启动服务之后,内存被塞满,所有的DML/DDL操作都卡住了。
below are the stats :
total used free shared buff/cache available
Mem: 15 2 7 0 5 12
Swap: 4 0 4
[mysqld]
我有一些带有死锁的MySQL (innodb),我只是想杀死这些事务,然后继续前进。
“显示引擎INNODB状态”显示如下:
*** (1) TRANSACTION:
TRANSACTION 74D88AFE, ACTIVE 14 sec starting index read
mysql tables in use 3, locked 3
LOCK WAIT 3 lock struct(s), heap size 1248, 2 row lock(s)
MySQL thread id 4637121, OS thread handle 0x7f51f91be700, query id 979