clickhouse 避免可能的死锁 deadlock

最新推荐文章于 2024-03-16 15:02:33 发布

原创最新推荐文章于 2024-03-16 15:02:33 发布 · 3.9k 阅读

0 ·

CC 4.0 BY-SA版权

Clickhouse 专栏收录该内容

102 篇文章

订阅专栏

文章详细介绍了在Inversion19.14中发现的严重问题——一个导致服务器死锁的竞态条件。核心团队在2020年对此进行了深入工作，逐步移除了引起死锁的锁，并在后续版本中优化了检查机制。到了20.6版本，所有可能的表级锁都被移除，ALTER操作变得完全无锁。此外，从20.10开始，默认启用数据库Atomic特性，允许在不加锁的情况下执行DROP命令。当遇到频繁的死锁异常时，建议更新并检查运行的查询，特别是那些涉及系统表的操作。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

In version 19.14 a serious issue was found: a race condition that can lead to server deadlock. The reason for that was quite fundamental, and a temporary workaround for that was added ("possible deadlock avoided").
Those locks are one of the fundamental things that the core team was actively working on in 2020.
In 20.3 some of the locks leading to that situation were removed as a part of huge refactoring.
In 20.4 more locks were removed, the check was made configurable (see lock_acquire_timeout ) so you can say how long to wait before returning that exception
In 20.5 heuristics of that check ("possible deadlock avoided") was improved.
In 20.6 all table-level locks which were possible to remove were removed, so alters are totally lock-free.
20.10 enables database=Atomic by default which allows running even DROP commands without locks.
Typically issue was happening when doing some concurrent select on system.parts / system.columns / system.table with simultaneous table manipulations (doing some kind of ALTERS / TRUNCATES / DROP)I
If that exception happens often in your use-case: An update is recommended. In the meantime, check which queries are running (especially to system.tables / system.parts and other system tables) and check if killing them / avoiding them helps to solve the issue.

参考：

https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-possible-deadlock-avoided.-client-should-retry