故障分析 | ClickHouse 叢集分散式 DDL 被阻塞案例一則

愛可生雲資料庫發表於2022-05-06
分散式

作者：任坤

現居珠海，先後擔任專職 Oracle 和 MySQL DBA，現在主要負責 MySQL、mongoDB 和 Redis 維護工作。

本文來源：原創投稿

*愛可生開源社群出品，原創內容未經授權不得隨意使用，轉載請聯絡小編並註明來源。

1、背景

線上有套10節點clickhouse叢集，5分片 * 2副本，版本19.7.3。

開發執行一個建立分散式表的操作，9個節點都成功返回，有個節點報錯，返回資訊如下：

Code: 159. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: Wa
tching task /clickhouse/task_queue/ddl/query‐0003271440 is executing longer
than distributed_ddl_task_timeout (=180) seconds. There are 1 unfinished ho
sts (0 of them are currently active), they are going to execute the query i
n background.

2、診斷

登入該節點檢視show processlist，正在執行1個分散式ddl，該ddl已經執行100多個小時，應該是卡住了。

clickhouse的分散式ddl是序列執行的，每次將任務儲存到zookeeper
的/clickhouse/task_queue/ddl目錄，按照FIFO排列。

對於每個節點，只有當前的ddl執行完畢，後面的才能被呼叫。

select * from zookeeper where path='/clickhouse/task_queue/ddl' order by ctime desc\G

剛剛發起的建立分散式表ddl排在第一位，上述截圖中的optimize table排在第23，說明被其阻塞的ddl有22條之多，開發也確認最近兩天的ddl任務在該節點上都沒有成功。

嘗試將其kill，等待幾個小時仍然沒有效果。

加sync關鍵字，直接卡住。

嘗試重啟ck例項也卡住，最後只能Kill -9。

重啟例項後該任務依然存在，而且執行了10多分鐘沒有要結束的意思，kill操作仍然無效。

既然這個ddl無法繞過，執行的時候又長時間不結束，只能曲線救國，重新命名該表讓其臨時消失一會。

rename table log_catch_data_local to log_catch_data_local1;

optimize table當即返回，並且其後22個ddl也很快執行完畢，最後再將其重新命名回原表。

此時再次執行optimize table，只需5s便成功返回，該問題解決。

3、總結

clickhouse的分散式ddl在每個節點是FIFO序列執行的，任意1個ddl卡住了都會阻塞後續任務。

本例中的卡住的ddl是optimize table，可以通過重新命名錶跳過；如果是增刪列，可以在rename後手工對該表執行本地ddl。

如果上述方法都不行，可以在出問題的節點將本地表直接drop，等待所有阻塞ddl執行完畢後，重新建立1個空表，會自動從另一個副本中同步資料。

最後，19.x版本已經很舊了，我們在使用過程中遭遇了各種問題，要儘快升級到20.x系列

相關文章