clickhouse DML 语句Sync 解决大部分元数据处理不及时的问题

 

Clickhouse sync 解析

作用：

可以更及时清理Atomic 数据库内部的表元数据信息。

无 cluster 模式

以 Drop table table_map sync; 此处是本地表。

结论

Sync 语法无法改变 BackgroundSchedulePool 使用线程异步执行的本质，只能是让这个任务被执行的优先级变高。整体仍然是生产/消费模型。

详细描述

生产:
    sync 会让Drop任务放在list头部，然后schedule线程执行。

消费:
    schedule执行时，会从唤醒后端可以消费Drop 任务的线程执行。因为find_if函数是从list头部开始查找任务执行。这样越靠近头部的Drop任务会被先被执行。

void DatabaseCatalog::dropTableDataTask(){
    ...
    auto it = std::find_if(tables_marked_dropped.begin(), tables_marked_dropped.end(), [&](const auto & elem)
    ...
}

后面会针对这个table对应的IStorage类型，执行对应的Drop table语句。
# 比较关心的有Zookeeper参与的ReplicatedMergeTree

　　

 

后面会针对这个table对应的IStorage类型，执行对应的Drop table语句。

# 比较关心的有Zookeeper参与的ReplicatedMergeTree

总结:

在绝大部分情况下，执行DDL语句最后加上Sync 关键字，是可以对zookeeper的元数据以及本地的数据目录进行清理的。特殊情况下除外，比如zookeeper执行超时异常，会导致元数据无法删除，会导致后续建表出现zk路径重复问题。

　　

 

Storage 架构图

每一张表都对应一个IStorage。

 

 

 

Cluster 模式

因为on cluster 模式，sql在 DDLWorker中被处理成 一个执行语句，会在zookeeper上创建结点。由监听此结点的任务执行，监听此结点的任务执行时，就变成 上面的模式执行。

结论

正常情况下，on cluster 模式，会让元数据信息清理更及时。