集群中壹個CK節點，因服務器電壓不穩意外重啟後，CK啟動失敗，壹直報錯：
查找官方文檔中，在 Data Replication 說明這裏，提到了故障恢復方法：
註意這裏flage目錄可以是妳安裝時指定的具體clickhouse根目錄。然後重啟CK服務，CK會從另外壹個備份中恢復數據。
這裏是CK自帶的故障恢復機制，前提是使用復制表（Replicated開頭），本質是告訴CK，強制重建數據。建議使用此方法。
如果數據完全丟失的情況，進行restore時，CK本身沒有帶寬限制，表很多或數據量很大的話，需要做好網絡壓力以及時間評估。
目錄下的所有文件都是空的（0B大小），原因無從得知，只能假定是因為服務器級別的異常重啟，數據仍然在緩沖區中，沒有寫入磁盤？於是有了上面的“ParsingException”，CK沒有讀取到期望的值。
得到CK的邏輯為：
啟動時，檢查本地文件系統中的數據集是否與預期的數據集（ ZooKeeper 中信息）壹致。如果存在輕微的不壹致，系統會通過與副本同步數據來解決，如果系統檢測到損壞的數據片段（如文件大小錯誤）或無法識別的片段（寫入文件系統但未記錄在 ZooKeeper 中的部分），則會把它們移動到 ‘detached’ 子目錄（相當於邏輯刪除），然後再從其他備份中去恢復這個數據片段。
但是註意這裏是有壹個安全機制的，即CK判斷妳損壞的片段大於壹定的值（max_suspicious_broken_parts，對應源碼圖二中的邏輯），即“本地數據集與預期數據的差異太大”，CK將會拒絕幫妳自動修復，並拋出異常、阻塞啟動，這個時候妳就必須手動執行恢復。
通過查詢配置得到，max_suspicious_broken_parts參數的默認值是10：
通過此次異常處理，更加深了CK“壹輛性能超強的手動跑車”的印象，如同傳說中的法拉利開啟了ESC-OFF死亡模式，生死完全掌握在使用者的手上，不愧是戰鬥名族開源出來的系統。在完善周邊支撐的道路上，CK還有很長的路要走。