ClickHouse源码分析：Clickhouse的高危操作truncate table

为什么说truncate是个高危操作呢？看下它的处理流程就知道了。

StorageReplicatedMergeTree::truncate // 入口
	// 如下遍历所有分区
    dropAllPartsInPartition // 停止merge并在zk上创建删除分区的log， 类型为LogEntry::DROP_RANGE
    waitForAllReplicasToProcessLogEntry // 等待所有副本执行完删除分区操作
    	// 如下遍历所有副本，包括自己
        waitForTableReplicaToProcessLogEntry
        	// 根据log_pointer和log编号判断是否已经处理完当前log-entry，没有处理完或者没有满足stop_waiting的条件，则一直等待
            // 等待queue节点下文件消失

// 将log节点下的内容拉取到queue节点下，并将entry放到变量queue中
ReplicatedMergeTreeQueue::pullLogsToQueue
	...
    
// 处理队列的后台线程
StorageReplicatedMergeTree::getDataProcessingJob
    selectQueueEntry
    processQueueEntry // 处理队列中的任务
        processEntry
            executeLogEntry
                executeDropRange // 真正删除part
            removeProcessedEntry // 删除queue和zk上的队列

从上面的流程可以看出几点问题：

1、truncate table操作会等待所有的副本处理结束，即使某些副本出现故障了，也还会继续等待，没有设置超时时间（这不是瞎等吗）

2、truncate 操作没有回滚机制，在它分别遍历分区和副本时，如果存在多个分区和多个副本，且某个副本存在故障时，那么遍历到故障副本时，流程会一直卡住（无法满足stop_waiting条件，该副本的log一直无法处理）。但是，此时，之前遍历过的副本已经处理完了truncate操作。这就导致两点不一致：

（1）副本间的数据已经不一致了；

（2）已经遍历过的副本只删除了部分数据，一般是只有第一个分区的数据被删除了