由於服務器電壓不穩定，群集中的CK節點意外重啟後，CK無法啟動並不斷報告錯誤:
在官方文檔中，在數據復制描述中，提到了故障恢復方法:
請註意，此處的flage目錄可以是安裝時指定的特定clickhouse根目錄。然後重新啟動CK服務，CK將從另壹個備份中恢復數據。
這裏是CK自己的故障恢復機制，前提是使用了復制表(在復制開始時)。實質是告訴CK強行重建數據。建議使用這種方法。
如果數據完全丟失，CK本身在恢復時沒有帶寬限制。如果表格多或者數據量大，就要評估網絡壓力和時間。
目錄中的所有文件都是空的(0B大小)，原因未知。只能假設數據還在緩沖區中，沒有寫入磁盤，因為服務器級的異常重啟。所以有了上面的“ParsingException”，CK並沒有讀到預期的值。
得到CK的邏輯是:
啟動時，檢查本地文件系統中的數據集是否與預期數據集(ZooKeeper中的信息)壹致。如果有輕微的不壹致，系統將通過將數據與副本同步來解決。如果系統檢測到損壞的數據碎片(如文件大小錯誤)或無法識別的碎片(寫入文件系統但沒有記錄在ZooKeeper中的部分)，它會將它們移動到' detached '子目錄中(相當於邏輯刪除)，然後從其他備份中恢復這個數據碎片。
但是註意這裏有壹個安全機制，就是CK判斷妳損壞的碎片大於某個值(max _ suspective _ broken _ parts，對應源代碼圖2中的邏輯)，也就是“本地數據集和預期數據相差太大”，CK會拒絕自動幫妳修復，拋出異常，阻止啟動。此時，您必須手動執行恢復。
根據查詢配置，max _ suspective _ broken _ parts參數的默認值為10:
通過這次異常處理，加深了CK“壹輛性能超強的手動跑車”的印象，就像傳說中的法拉利開啟了ESC-OFF死亡模式，生死完全掌握在用戶手中，不愧為格鬥家的開源系統。在改善周邊配套的道路上，CK還有很長的路要走。