寫 ClickHouse 的人十有八九都躲不過 ON CLUSTER 刪表這個(gè)坎。平時(shí)一條DROP TABLE IF EXISTS xxx ON CLUSTER cluster_name敲下去幾秒鐘就返回感覺比本地刪表還省心。但一旦趕上 ZooKeeper 抖動(dòng)、某個(gè)副本悄悄掛了這條命令就會(huì)變成一把懸在頭上的刀——要么卡住不動(dòng)要么報(bào)一堆看不懂的錯(cuò)誤更麻煩的是集群里有的節(jié)點(diǎn)表沒了、有的節(jié)點(diǎn)表還在整個(gè)元數(shù)據(jù)狀態(tài)變成一鍋粥。這篇文章就把這事徹底講明白。我會(huì)從分布式 DDL 的調(diào)度原理講起沿著一次真實(shí)故障的排查鏈路走一遍最后給出幾種不同場景下的恢復(fù)手段和日常預(yù)防參數(shù)。不管你是剛接觸 ClickHouse 的初學(xué)者還是已經(jīng)被 ON CLUSTER 折磨過的運(yùn)維老手這篇都能幫你省下幾個(gè)熬夜排查的晚上。1. ON CLUSTER 刪表的調(diào)度流程與依賴1.1 分布式 DDL 的調(diào)度鏈路先明確一個(gè)容易被忽略的事實(shí)ClickHouse 里的ON CLUSTER并不是直接把一條 DDL 廣播給所有節(jié)點(diǎn)執(zhí)行而是把這條語句當(dāng)作一個(gè)任務(wù)先寫到 ZooKeeper或者 ClickHouse Keeper下面統(tǒng)一叫 ZK的某個(gè)隊(duì)列路徑下然后由集群內(nèi)每個(gè)節(jié)點(diǎn)上的DistributedDDLWorker后臺(tái)線程去拉取并執(zhí)行。這條隊(duì)列路徑一般是/clickhouse/task_queue/ddl。當(dāng)你在任意一個(gè)節(jié)點(diǎn)執(zhí)行DROP TABLE ON CLUSTER時(shí)該節(jié)點(diǎn)會(huì)生成一個(gè)帶唯一標(biāo)識(shí)的 DDL 任務(wù)節(jié)點(diǎn)寫入這個(gè)隊(duì)列這個(gè)節(jié)點(diǎn)本身扮演的就是“協(xié)調(diào)發(fā)起者”的角色。其他節(jié)點(diǎn)上的后臺(tái)線程會(huì)發(fā)現(xiàn)隊(duì)列里有新任務(wù)于是各自把它拉下來在本機(jī)執(zhí)行對(duì)應(yīng)的 SQL。這里有個(gè)關(guān)鍵點(diǎn)雖然語句是在一個(gè)節(jié)點(diǎn)上發(fā)起的但任務(wù)對(duì)所有節(jié)點(diǎn)是公平可見的。只要 ZK 正常、節(jié)點(diǎn)和 ZK 之間的會(huì)話沒斷理論上所有存活節(jié)點(diǎn)都會(huì)各自執(zhí)行一次刪表操作。這個(gè)機(jī)制的好處是天然并發(fā)壞處是——只要有一個(gè)節(jié)點(diǎn)和 ZK 會(huì)話出問題它就不會(huì)執(zhí)行這個(gè)任務(wù)于是整個(gè)環(huán)境就變得不一致。1.2 本地副本刪除時(shí)依賴哪些 ZK 路徑DROP TABLE在語義上分成兩步。第一步是從元數(shù)據(jù)里把表定義干掉第二步是刪掉本地?cái)?shù)據(jù)目錄里的物理文件。如果是ReplicatedMergeTree系列的表引擎還會(huì)涉及和 ZK 的交互因?yàn)楦北咀?cè)信息是存在 ZK 里的。具體涉及的關(guān)鍵路徑大致有/clickhouse/tables/{shard}/{uuid}或舊版本里的/clickhouse/tables/{database}/{table}存放的是表級(jí)別的副本注冊(cè)信息包括每個(gè)副本的元數(shù)據(jù)版本、日志指針、活躍狀態(tài)等。/clickhouse/task_queue/ddl就是前面說的分布式 DDL 任務(wù)的隊(duì)列目錄。/clickhouse/session節(jié)點(diǎn)與 ZK 建立會(huì)話的臨時(shí)節(jié)點(diǎn)路徑會(huì)話過期的話這個(gè)路徑下會(huì)有殘留也會(huì)影響副本狀態(tài)判定。一個(gè) ReplicatedMergeTree 表在刪表時(shí)會(huì)先從 ZK 里刪除自己這個(gè)副本對(duì)應(yīng)的注冊(cè)節(jié)點(diǎn)然后清理本地的 metadata 文件、WAL、數(shù)據(jù)目錄等。如果這些步驟中任何一環(huán)在 ZK 會(huì)話層面失敗那么本地文件可能刪了一半ZK 里的注冊(cè)信息也可能還在那一半的狀態(tài)就非常難受。1.3 DDL 任務(wù)超時(shí)與返回機(jī)制distributed_ddl_task_timeout這個(gè)參數(shù)控制的是發(fā)起點(diǎn)等待集群內(nèi)其他節(jié)點(diǎn)執(zhí)行 DDL 任務(wù)的超時(shí)時(shí)間。默認(rèn)值是 180 秒。這個(gè)參數(shù)不是“只要超時(shí)就失敗”而是超時(shí)后發(fā)起點(diǎn)會(huì)主動(dòng)放棄等待只返回當(dāng)前已經(jīng)收到響應(yīng)的節(jié)點(diǎn)列表。新版本里還有一個(gè)distributed_ddl_output_mode參數(shù)用來控制返回結(jié)果的展示方式。比如none表示不等待響應(yīng)直接返回throw表示只要有一個(gè)節(jié)點(diǎn)報(bào)錯(cuò)就拋出異常。實(shí)際使用中很多人會(huì)遇到“命令執(zhí)行了但是報(bào)錯(cuò)說某節(jié)點(diǎn)沒響應(yīng)”這大概率就是這個(gè)超時(shí)機(jī)制在起作用——任務(wù)還在 ZK 隊(duì)列里沒被執(zhí)行但發(fā)起點(diǎn)已經(jīng)不想等了。理解了這條鏈路下面看故障現(xiàn)象就清楚多了。大概率不是 SQL 語法的問題而是這個(gè)分布式調(diào)度鏈路里某個(gè)環(huán)節(jié)斷了。2. 故障現(xiàn)象與根因庫2.1 常見的故障表現(xiàn)分類根據(jù)我遇到過的情況DROP TABLE ON CLUSTER的故障大致能分成三類。第一類是卡住不動(dòng)。命令敲下去之后一直不返回既不報(bào)錯(cuò)也不成功。這種一般有兩種可能要么發(fā)起點(diǎn)連不上 ZK要么 ZK 里的 DDL 隊(duì)列任務(wù)在等待某個(gè)不可用節(jié)點(diǎn)的響應(yīng)而那個(gè)節(jié)點(diǎn)已經(jīng)聯(lián)系不上了。第二類是直接報(bào)錯(cuò)錯(cuò)誤信息五花八門。最常見的有Code: 342. DB::Exception: The replica is not active、All replicas are lost、Cannot drop table because it is in readonly state等等。這些錯(cuò)誤翻譯成人話就是這個(gè)表有副本但是副本的 ZK 會(huì)話已經(jīng)斷了或者副本自己都覺得自己已經(jīng)不健康了。第三類最隱蔽命令返回成功但集群狀態(tài)不對(duì)。有的節(jié)點(diǎn)表刪了有的節(jié)點(diǎn)表還在甚至有的節(jié)點(diǎn)上的表變成了只讀狀態(tài)。這種問題最坑的地方在于你以為刪完了實(shí)際上某個(gè)分片的數(shù)據(jù)還在磁盤上占著空間后續(xù)重新建表還可能因?yàn)樵獢?shù)據(jù)殘留而失敗。2.2 根因庫速查表結(jié)合實(shí)踐經(jīng)驗(yàn)我把常見的根因整理成一個(gè)速查表排查的時(shí)候可以先對(duì)照一下。故障現(xiàn)象核心根因關(guān)鍵排查點(diǎn)命令卡住不返回ZK 會(huì)話異常或者某個(gè)節(jié)點(diǎn)失聯(lián)system.replicas、ZK 節(jié)點(diǎn)狀態(tài)報(bào) replica is not active某個(gè)副本的 ZK 會(huì)話過期system.replicas.is_active字段部分節(jié)點(diǎn)成功部分失敗失敗節(jié)點(diǎn)當(dāng)時(shí)和 ZK 斷連DDL 隊(duì)列殘留任務(wù)表變成 readonly元數(shù)據(jù)和 ZK 狀態(tài)不一致system.replicas的 readonly 字段重新建表失敗本地 metadata 殘留檢查 metadata 目錄一直顯示 deleted 狀態(tài)DDL 任務(wù)已標(biāo)記刪除但未清理ZK 任務(wù)隊(duì)列殘留2.3 為什么不同節(jié)點(diǎn)狀態(tài)會(huì)不一致ClickHouse 的集群一致性并不是“強(qiáng)同步”的它依賴 ZK 這個(gè)外部協(xié)調(diào)者來達(dá)成最終一致。每個(gè)節(jié)點(diǎn)都有自己的本地元數(shù)據(jù)ZK 里存的是集群維度的公共狀態(tài)。兩者之間靠會(huì)話和心跳維持同步。當(dāng)某個(gè)節(jié)點(diǎn)的 ZK 會(huì)話超時(shí)后這個(gè)節(jié)點(diǎn)上的副本會(huì)被標(biāo)記為readonly它不再接收寫入也不再參與副本同步。但它本地的元數(shù)據(jù)文件并不會(huì)自動(dòng)消失。這個(gè)時(shí)候你發(fā)起一個(gè)DROP TABLE ON CLUSTER健康節(jié)點(diǎn)正常執(zhí)行刪除但這個(gè)斷連節(jié)點(diǎn)不響應(yīng) DDL 任務(wù)于是整個(gè)集群的元數(shù)據(jù)就不一致了。更麻煩的是如果這個(gè)會(huì)話長期沒有恢復(fù)ZK 里的副本注冊(cè)信息也會(huì)變成失聯(lián)狀態(tài)。此時(shí)即使你手動(dòng)在這個(gè)節(jié)點(diǎn)上執(zhí)行本地DROP TABLE也會(huì)因?yàn)?ZK 狀態(tài)校驗(yàn)不過而報(bào)錯(cuò)。這就是為什么很多人最后只能選擇停掉節(jié)點(diǎn)手動(dòng)清理元數(shù)據(jù)文件才能恢復(fù)。3. 完整排查實(shí)錄從故障到定位3.1 一次典型的 Drop On Cluster 卡住故障之前一個(gè)業(yè)務(wù)團(tuán)隊(duì)遇到的情況非常有代表性。某天他們?cè)诶星謇磉^期分區(qū)時(shí)執(zhí)行了一條DROP TABLE IF EXISTS ods_order_temp ON CLUSTER cluster_01;命令敲下去之后終端直接卡住CtrlC 都救不回來。過了好幾分鐘才返回了一個(gè)類似這樣的報(bào)錯(cuò)Received exception from server (Version 23.8.1): Code: 159. DB::Exception: Timeout exceeded while waiting for the DDL task to be executed on servers.這個(gè)報(bào)錯(cuò)翻譯過來就是發(fā)起節(jié)點(diǎn)已經(jīng)把 DDL 任務(wù)寫進(jìn) ZK 了也等了一段時(shí)間但有一些服務(wù)器沒有在超時(shí)時(shí)間內(nèi)確認(rèn)執(zhí)行完成。當(dāng)時(shí)我第一反應(yīng)是去看system.replicas因?yàn)閯h表卡住的本質(zhì)往往是副本狀態(tài)不健康而不是 SQL 本身的問題。SELECT database, table, is_readonly, is_session_expired, zookeeper_exception, replica_is_active FROM system.replicas WHERE database default;結(jié)果非常直觀其中某個(gè)分片的一塊副本is_session_expired 1replica_is_active 0。也就是說這個(gè)副本和 ZK 之間的會(huì)話已經(jīng)過期了它完全不知道自己應(yīng)該執(zhí)行什么任務(wù)。3.2 順著 DDL 隊(duì)列查無用功確認(rèn)副本不健康之后還需要確認(rèn) DDL 任務(wù)本身的狀態(tài)。ClickHouse 在較新版本里提供了一個(gè)內(nèi)部表system.distributed_ddl_queue可以直接查到 DDL 任務(wù)的執(zhí)行情況。SELECT query, host, status, create_time, cluster FROM system.distributed_ddl_queue ORDER BY create_time DESC LIMIT 10;從結(jié)果里能看到這條DROP TABLE任務(wù)的狀態(tài)是in_process也就是還在等待中。而正常執(zhí)行完的任務(wù)狀態(tài)應(yīng)該是finished。另外一步值得做的操作是去 ZK 里直接看 DDL 任務(wù)隊(duì)列目錄。ClickHouse 提供了system.zookeeper表可以像查普通表一樣查詢 ZK 節(jié)點(diǎn)內(nèi)容SELECT name, value, num_children FROM system.zookeeper WHERE path /clickhouse/task_queue/ddl LIMIT 20;這里能看到所有待執(zhí)行的 DDL 任務(wù)節(jié)點(diǎn)。正常來說這個(gè)目錄應(yīng)該是空的或者只有極少數(shù)正在執(zhí)行的任務(wù)。如果你發(fā)現(xiàn)里面堆積了大量歷史任務(wù)說明之前有多次刪表/建表操作失敗過殘留的任務(wù)一直沒被清理。3.3 定位到問題副本并驗(yàn)證確認(rèn)問題副本后下一步要判斷這個(gè)副本還有沒有救。當(dāng)時(shí)我直接在一個(gè)健康的副本上執(zhí)行SYSTEM SYNC REPLICA ods_order_temp ON CLUSTER cluster_01;結(jié)果也是超時(shí)說明不只是當(dāng)前 DDL 卡住而是這個(gè)分片內(nèi)部的副本同步鏈路已經(jīng)斷了。再回頭看system.replicas里的zookeeper_exception字段里面會(huì)出現(xiàn)類似這樣的報(bào)錯(cuò)All connection attempts to ZooKeeper failed這個(gè)字段是排查 ZK 會(huì)話類問題的金鑰匙。一旦出現(xiàn)這個(gè)值基本可以斷定該節(jié)點(diǎn)和 ZK 之間的網(wǎng)絡(luò)鏈路或者 ZK 自身的會(huì)話管理出了狀況。這個(gè)時(shí)候如果你不死心想直接在問題節(jié)點(diǎn)上執(zhí)行本地刪表DROP TABLE IF EXISTS default.ods_order_temp;大概率也會(huì)報(bào)錯(cuò)。因?yàn)樵?ZK 的副本注冊(cè)信息里當(dāng)前節(jié)點(diǎn)可能已經(jīng)不是 active 狀態(tài)了本地刪表操作過不了校驗(yàn)。3.4 復(fù)盤當(dāng)時(shí)為什么沒更早發(fā)現(xiàn)這個(gè)案例到最后雖然救回來了但復(fù)盤時(shí)發(fā)現(xiàn)一個(gè)很明顯的問題這個(gè)不健康的副本其實(shí)已經(jīng)異常存在了一段時(shí)間如果平時(shí)有巡檢system.replicas的習(xí)慣早就應(yīng)該看到is_readonly 1或者zookeeper_exception不為空。但因?yàn)檫@個(gè)表平時(shí)讀取壓力不大業(yè)務(wù)側(cè)也沒發(fā)現(xiàn)異常直到刪表時(shí)才踩中。所以我現(xiàn)在做任何 ON CLUSTER 操作之前都會(huì)先看一眼集群整體副本健康度。與其等 DDL 卡住再去救不如在動(dòng)手前就把不健康的副本排除掉。這個(gè)習(xí)慣幫我避了好幾次坑。4. 分場景恢復(fù)方案與強(qiáng)制清理4.1 場景一單副本會(huì)話過期表本身可以重建如果只是會(huì)話過期且表的數(shù)據(jù)已經(jīng)不是很重要最簡單的方式是先把不健康的副本清理掉。ClickHouse 提供了SYSTEM DROP REPLICA之類的命令可以刪除本地這副本在 ZK 里的注冊(cè)信息。SYSTEM DROP REPLICA replica_name FROM TABLE default.ods_order_temp;這個(gè)命令的作用是告訴 ZK這個(gè)副本我放棄了請(qǐng)移除它的注冊(cè)信息。之后再回到這個(gè)節(jié)點(diǎn)上執(zhí)行普通建表語句讓副本重新拉取元數(shù)據(jù)。注意一個(gè)細(xì)節(jié)replica_name不是隨便填的它是該節(jié)點(diǎn)配置的macros里的replica值?？梢杂眠@條 SQL 查到SELECT * FROM system.macros;確認(rèn)replica的取值后再執(zhí)行SYSTEM DROP REPLICA。4.2 場景二表數(shù)據(jù)不重要直接走強(qiáng)制清理如果表已經(jīng)沒有任何保留價(jià)值也沒必要費(fèi)勁修復(fù)副本直接走強(qiáng)制清理流程。步驟一把所有節(jié)點(diǎn)的 ClickHouse 進(jìn)程停掉。這一步是為了避免在清理過程中有后臺(tái)線程悄悄改 ZK 或本地元數(shù)據(jù)。步驟二找到 ClickHouse 的數(shù)據(jù)目錄默認(rèn)是/var/lib/clickhouse在metadata/目錄下找到對(duì)應(yīng)的數(shù)據(jù)庫文件。比如default庫的元數(shù)據(jù)路徑是/var/lib/clickhouse/metadata/default.sql。打開這個(gè)文件搜到ods_order_temp這張表對(duì)應(yīng)的CREATE TABLE語句手動(dòng)刪掉。步驟三在metadata/{database}/目錄下可能會(huì)有該表的獨(dú)立元數(shù)據(jù)文件一并刪掉。同時(shí)檢查data/{database}/目錄下有沒有對(duì)應(yīng)的物理數(shù)據(jù)目錄有的話也一起刪除。步驟四再去看 ZK 里該表對(duì)應(yīng)的路徑是否還有殘留。用之前的system.zookeeper查詢方式先找SELECT * FROM system.zookeeper WHERE path /clickhouse/tables;找到對(duì)應(yīng)表路徑后確認(rèn)沒有其他副本還在使用的情況下可以直接刪掉這個(gè) ZK 節(jié)點(diǎn)。不過這一步要非常謹(jǐn)慎最好在確認(rèn)所有節(jié)點(diǎn)都已經(jīng)停掉之后再操作否則容易引發(fā)其他副本的狀態(tài)混亂。4.3 場景三DDL 隊(duì)列殘留導(dǎo)致新 DDL 永遠(yuǎn)卡住還有一種情況某次 DDL 超時(shí)后那個(gè)任務(wù)節(jié)點(diǎn)一直殘留在 ZK 的 DDL 隊(duì)列里導(dǎo)致后續(xù)所有 ON CLUSTER 操作都要排隊(duì)甚至直接卡住。這種問題的解法相對(duì)簡單直接清掉這個(gè)殘留任務(wù)節(jié)點(diǎn)。查詢/clickhouse/task_queue/ddl找到那個(gè)查詢對(duì)應(yīng)的節(jié)點(diǎn)名稱在 ZK 客戶端里刪除它就行。用 clickhouse-client 操作的話需要借助system.zookeeper找到精確路徑然后調(diào)用zookeeper刪除接口。較新版本里 ClickHouse 提供了一個(gè)zk命令可以直接操作clickhouse-keeper-client --connection-stringlocalhost:9181進(jìn)入客戶端后執(zhí)行rmdir /clickhouse/task_queue/ddl/ddl_query_id_xxx但說實(shí)話我一般不太推薦在生產(chǎn)環(huán)境直接對(duì)著 ZK 目錄刪東西。更穩(wěn)的方式是確認(rèn) DDL 任務(wù)確實(shí)已經(jīng)沒用了再重啟下出問題的節(jié)點(diǎn)。ClickHouse 啟動(dòng)時(shí)如果發(fā)現(xiàn) DDL 隊(duì)列里有尚未完成的任務(wù)會(huì)嘗試重新執(zhí)行或標(biāo)記失敗并清理。多數(shù)情況下重啟節(jié)點(diǎn)就能把臟隊(duì)列帶出來。4.4 場景四表已經(jīng)只讀但還有歷史數(shù)據(jù)要保留如果表里還有需要保留的數(shù)據(jù)不能直接丟棄那就得先想辦法恢復(fù)副本的讀寫狀態(tài)。第一步先排查 ZK 鏈路看看zookeeper_exception是否已經(jīng)恢復(fù)。如果 ZK 連接恢復(fù)了直接在只讀副本上執(zhí)行SYSTEM RESTORE REPLICA;這個(gè)命令會(huì)嘗試用本地的元數(shù)據(jù)狀態(tài)去和 ZK 里的信息對(duì)齊重建會(huì)話狀態(tài)。執(zhí)行完后再看system.replicas如果is_readonly變成 0說明副本恢復(fù)了。如果執(zhí)行SYSTEM RESTORE REPLICA失敗或者報(bào)錯(cuò)說 ZK 路徑不存在那說明 ZK 里的表注冊(cè)信息已經(jīng)被清理過了。這種情況想保留數(shù)據(jù)只能先停掉節(jié)點(diǎn)然后把本地的data目錄復(fù)制出來再重新建表導(dǎo)入數(shù)據(jù)。5. 參數(shù)調(diào)優(yōu)與日常預(yù)防建議5.1 調(diào)整 DDL 超時(shí)與輸出模式經(jīng)驗(yàn)不足的時(shí)候很多人會(huì)直接把distributed_ddl_task_timeout調(diào)大覺得等久一點(diǎn)總能成功。實(shí)際上這個(gè)策略是錯(cuò)的調(diào)大超時(shí)只是讓卡住的時(shí)間更長并不能解決問題本身。我的建議是把這個(gè)值調(diào)到一個(gè)“可接受的等待上限”比如 60 秒。同時(shí)把distributed_ddl_output_mode設(shè)置為throw這樣只要集群內(nèi)有節(jié)點(diǎn)反饋執(zhí)行異常發(fā)起點(diǎn)會(huì)第一時(shí)間把錯(cuò)誤拋出來而不是默默等超時(shí)。profile distributed_ddl_task_timeout60/distributed_ddl_task_timeout distributed_ddl_output_modethrow/distributed_ddl_output_mode /profile這樣設(shè)置之后刪表操作如果遇到問題會(huì)很快暴露出來而不是卡到地老天荒。5.2 刪表前的副本健康檢查三件套在我自己的運(yùn)維習(xí)慣里只要涉及 ON CLUSTER 的寫操作尤其是刪表這種破壞性操作動(dòng)手前必須先過三關(guān)。第一關(guān)看system.replicas確認(rèn)所有相關(guān)表的副本都處于 active 狀態(tài)。SELECT database, table, count() AS total_replicas, sum(replica_is_active) AS active_replicas FROM system.replicas GROUP BY database, table HAVING total_replicas ! active_replicas;這條 SQL 會(huì)直接把有非活躍副本的表列出來。只要結(jié)果是空的說明副本層面是健康的。第二關(guān)看 ZK 的 DDL 隊(duì)列是否干凈。SELECT count() FROM system.zookeeper WHERE path /clickhouse/task_queue/ddl;這個(gè)數(shù)量最好常年為 0偶爾有 1 到 2 個(gè)正在執(zhí)行中的任務(wù)也正常。如果積壓了幾十個(gè)就先排查歷史故障原因。第三關(guān)確認(rèn) ZK 本身狀態(tài)正常。如果用的是 ZooKeeper 集群直接看監(jiān)控里的節(jié)點(diǎn)連接數(shù)、延遲、leader 狀態(tài)。如果用的是 ClickHouse Keeper可以用內(nèi)置的system.keeper相關(guān)表檢查。5.3 監(jiān)控與告警在故障之前接住它其實(shí)大部分 DROP TABLE ON CLUSTER 故障都是可以提前發(fā)現(xiàn)的。關(guān)鍵在于監(jiān)控里有沒有盯住下面幾個(gè)指標(biāo)監(jiān)控指標(biāo)推薦監(jiān)控內(nèi)容閾值建議副本活躍度replica_is_active為 0 的副本數(shù)持續(xù) 0ZK 連接狀態(tài)zookeeper_exception非空次數(shù)持續(xù) 0DDL 隊(duì)列積壓/clickhouse/task_queue/ddl子節(jié)點(diǎn)數(shù)超過 5 告警只讀表數(shù)量is_readonly為 1 的表數(shù)量持續(xù) 0這些指標(biāo)在 ClickHouse 的 prometheus 導(dǎo)出接口里基本都有暴露接入 Grafana 就能做成監(jiān)控大盤。比起事后救火提前盯住這幾個(gè)指標(biāo)能避免絕大多數(shù)麻煩。5.4 規(guī)避性的運(yùn)維規(guī)范建議最后說幾條我在實(shí)際生產(chǎn)環(huán)境里總結(jié)出來的運(yùn)維規(guī)范每條都踩過坑寫出來給大家避雷。第一個(gè)規(guī)范生產(chǎn)環(huán)境禁止直接對(duì) ON CLUSTER 的 DROP 操作不加思考地執(zhí)行。尤其是大表先確認(rèn)這張表是否有下游依賴是否有備份是否真的不需要了?？梢杂肧HOW CREATE TABLE看一下表的引擎類型和集群定義心里先有個(gè)底。第二個(gè)規(guī)范執(zhí)行刪除前先備份元數(shù)據(jù)。最簡單的辦法是先執(zhí)行一次SHOW CREATE TABLE把結(jié)果保存到本地。萬一刪表過程中元數(shù)據(jù)殘留導(dǎo)致建表失敗有這條語句就能快速手工重建。第三個(gè)規(guī)范ZooKeeper 或 ClickHouse Keeper 的會(huì)話超時(shí)相關(guān)參數(shù)不要隨便改。調(diào)大了會(huì)導(dǎo)致副本故障發(fā)現(xiàn)變慢調(diào)小了又會(huì)造成誤判。默認(rèn)值通常是合理的除非你有充分的理由否則不要?jiǎng)铀?。第四個(gè)規(guī)范千萬不要在集群內(nèi)單個(gè)節(jié)點(diǎn)上直接執(zhí)行不帶 ON CLUSTER 的DROP TABLE。這在 ReplicatedMergeTree 表上往往不會(huì)成功就算僥幸成功也會(huì)立刻被其他副本把元數(shù)據(jù)同步回來造成狀態(tài)混亂。最后再分享一個(gè)實(shí)操小技巧如果你發(fā)現(xiàn)某個(gè) ON CLUSTER 語句卡住了但又不確定到底卡在哪個(gè)節(jié)點(diǎn)上可以在執(zhí)行新語句之前先手動(dòng)清理一下本地 DDL 隊(duì)列里的歷史任務(wù)。SYSTEM FLUSH DISTRIBUTED DDL;這命令會(huì)把本地已經(jīng)完成但還沒上報(bào)的 DDL 任務(wù)狀態(tài)刷新到 ZK能讓后續(xù)狀態(tài)查詢更準(zhǔn)確。雖然它不能直接解決卡住的問題但能讓你的排查視野更干凈。我個(gè)人的體感是ClickHouse 的 ON CLUSTER 機(jī)制本身設(shè)計(jì)得并不復(fù)雜真正復(fù)雜的是它依賴的外部協(xié)作者——ZK。大部分故障都不是 ClickHouse 自身壞了而是它和 ZK 之間的關(guān)系出了問題。所以下次再遇到 Drop Table On Cluster 的故障先別急著懷疑 SQL 寫錯(cuò)了靜下心來查一查副本狀態(tài)和 ZK 隊(duì)列答案往往就在那里。