Question

我的应用程序使用Master-master Galera复制设置在Maria DB上运行。

该应用程序可以处理死锁，但是我一直在努力尽量减少死锁填满我的日志文件时发生的死锁。仍然有一个事务会定期陷入僵局，我不知道该如何避免。

该过程从一个表中删除一条记录，对其他表执行一些操作，然后最终将一条记录插入原始表中。交易大致如下：

1. DELETE FROM table_a WHERE `id` = 'Foo'
2. REPLACE INTO table_b ( ... )
3. UPDATE table_c SET ....
4. INSERT INTO table_a (id,...) VALUES ('Bar',...)

最终插入通常会陷入死锁，尽管重试该事务可以解决此问题。这种模式导致死锁的原因是什么？我该怎么做以减少发生？

Answer 1

问题：您要写入的节点中的“死锁”是吗？否则直到COMMIT才会发生死锁；也就是说，当尝试在整个群集之间进行协调时？

如果在写入节点上...

在交易中尽快进行

SELECT id FROM table_a WHERE ... FOR UPDATE;

表示您将在步骤4中插入哪行。

此外，请考虑将REPLACE更改为等效的INSERT .. ON DUPLICATE KEY UPDATE ..。我不知道它是否可以直接帮助解决僵局，但至少（可能）它更有效率。

如果在群集上...

您要触摸很多不同的行吗？您是否使用轮询机制来选择要写入哪个节点？

无论如何，加快交易速度将有所帮助。有什么可以退出交易的吗？那里的一些想法：

规范化通常可以在其自己的事务中完成。
如果您的交易中有一个“ if”，那么事先进行初步测试可能是值得的。（但是您可能需要在交易中保留“ if”。）

为什么该交易会产生僵局？

1 个答案: