# 正确删除并理解ClickHouse表和分区-Toy模板网

这篇具有很好参考价值的文章主要介绍了# 正确删除并理解ClickHouse表和分区。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

ClickHouse表有一组数据块组成，称为分区和部分，分区是逻辑概念，对应磁盘上的目录，部分对应磁盘上的实际文件。

我们可以从表中分离（detach) 分区(partition)或部分(parts)，并没有实际删除数据，意味着数据从表中删除，并没有从磁盘上删除，我们可以在未来某个时刻重新附着分区或部分。

硬删除表数据

当删除原子数据库引擎表时，数据和表本身没有立刻从磁盘删除。只有当表不再被并发查询使用并且从收到查询已过去8分钟（old_parts_lifetime参数设置）时才会被真正删除。

例如，在某些情况下在删除并重新创建表时，可能会导致Zookeeper出现问题。因为表元数据仍然存在，等待异步删除，但此时试图再次创建它。例如:删除已复制的表并立即重新创建它将导致Zookeeper错误。

production-01 :) drop table test.myTable;

DROP TABLE test.myTable

Query id: 5a1e5daa-567e-49fb-aa11-c08c31fcde40

Ok.

0 rows in set. Elapsed: 0.005 sec. 

production-01 :) CREATE TABLE test.myTable
                 (
                     `timestamp` DateTime,
                     `event_type` String
                 )
                 ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/test.myTable', '{replica}')
                 PARTITION BY toYear(timestamp)
                 ORDER BY (timestamp)

CREATE TABLE test.myTable
(
    `timestamp` DateTime,
    `event_type` String
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/test.myTable', '{replica}')
PARTITION BY toYear(timestamp)
ORDER BY timestamp

Query id: 26669a72-ba6f-4c99-860c-67f75272f3c2


0 rows in set. Elapsed: 0.030 sec. 

Received exception from server (version 22.10.1):
Code: 253. DB::Exception: Received from clickhouse-01:49000. DB::Exception: Replica /clickhouse/tables/01-01/test.myTable/replicas/clickhouse-01 already exists. (REPLICA_IS_ALREADY_EXIST)

为了避免这种错误，可以增加sync修饰符，它会同步删除数据和表元数据，直到所有数据都被清除后才返回。这时重新创建表不会产生错误：

production-01 :) CREATE TABLE test.myTable2
                 (
                     `timestamp` DateTime,
                     `event_type` String
                 )
                 ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/test.myTable2', '{replica}')
                 PARTITION BY toYear(timestamp)
                 ORDER BY (timestamp)

CREATE TABLE test.myTable2
(
    `timestamp` DateTime,
    `event_type` String
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/test.myTable2', '{replica}')
PARTITION BY toYear(timestamp)
ORDER BY timestamp

Query id: 55afb63f-c4aa-46cb-b00b-c33bc7750c16

Ok.

0 rows in set. Elapsed: 0.045 sec. 

production-01 :) DROP TABLE test.myTable2 SYNC;

DROP TABLE test.myTable2 SYNC

Query id: 645e3e7b-17ea-4857-a405-d789378bdb2c

Ok.

0 rows in set. Elapsed: 0.046 sec. 

production-01 :) CREATE TABLE test.myTable2
                 (
                     `timestamp` DateTime,
                     `event_type` String
                 )
                 ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/test.myTable2', '{replica}')
                 PARTITION BY toYear(timestamp)
                 ORDER BY (timestamp)

CREATE TABLE test.myTable2
(
    `timestamp` DateTime,
    `event_type` String
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/test.myTable2', '{replica}')
PARTITION BY toYear(timestamp)
ORDER BY timestamp

Query id: 4dc22cdb-7e39-415c-8813-63a76c9ba3de

Ok.

0 rows in set. Elapsed: 0.039 sec.

注意，SYNC也在删除数据库时也可使用：

DROP DATABASE test SYNC;

实际应用中会遇到一些表的分区或部分数据不能正确加载，通过查看系统表可以看到这些分区或部分的状态，下面一节我们分析造成这些状态的原因，以及如何查询定位，方便后续手动修复。

分离分区或部分的原因

有以下几种原因导致有分离状态的分区或部分：

执行手动命令产生的分离状态分区或部分：[ALTER TABLE DETACH PART|PARTITION](https://clickhouse.com/docs/en/sql-reference/statements/alter/partition/#detach-partitionpart)
在本地存在的part，在Zookeeper元数据中却没有，其状态会被设置未：“unexpected” 或 “ignored”
在本地和Zookeeper元数据中都存在的part，但状态不匹配。part将被设置未 “broken” ，并从另外服务器从新下载
法定数量未达到的part。将设置为 “noquorum”

还有其他原因，但上述几个是最常见的。大多数情况下是由于不正当关闭ClickHouse造成的。当ClickHouse服务启动时开始执行正常检查，通过分离受影响的部分，ClickHouse可以继续启动(而不是崩溃)，并允许您修复问题。

查询分离的表分区和部分

通过查询system.detached_parts表，你能发现ClickHouse服务器所有已分离的部分。文章来源地址https://www.toymoban.com/news/detail-499217.html

    SELECT *
    FROM system.detached_parts

    Query id: fbc3d2b7-94c1-4ba4-8197-d3781efea792

    ┌─database─┬─table──────────────────────────────┬─partition_id─┬─name──────────────────────────────┬─disk────┬─reason──┬─min_block_number─┬─max_block_number─┬─level─┐
    │ database │ t_957657bace18444a80fc9b465269e132 │ 202203       │ broken_202203_4554988_4554988_0   │ default │ broken  │          4554988 │          4554988 │     0 │
    │ database │ t_957657bace18444a80fc9b465269e132 │ 202201       │ ignored_202201_6774780_6774868_20 │ default │ ignored │          6774780 │          6774868 │    20 │
    │ database │ t_7777dbf2efff4253b7d0802112ae4061 │ 202103       │ 202103_764230_1414635_14_984413   │ default │         │           764230 │          1414635 │    14 │
    │ database │ t_7777dbf2efff4253b7d0802112ae4061 │ 202103       │ 202103_1414636_1448800_9          │ default │         │          1414636 │          1448800 │     9 │
    │ database │ t_7777dbf2efff4253b7d0802112ae4061 │ 202103       │ 202103_730438_764229_9            │ default │         │           730438 │           764229 │     9 │
    │ database │ t_7777dbf2efff4253b7d0802112ae4061 │ 202103       │ 202103_0_730437_45                │ default │         │                0 │           730437 │    45 │
    │ database │ t_ab2e566af7e74637977f07ba42339f1e │ 202103       │ 202103_192019_400537_14_717974    │ default │         │           192019 │           400537 │    14 │
    │ database │ t_ab2e566af7e74637977f07ba42339f1e │ 202103       │ 202103_95413_192018_13_717974     │ default │         │            95413 │           192018 │    13 │
    └──────────┴────────────────────────────────────┴──────────────┴───────────────────────────────────┴─────────┴─────────┴──────────────────┴──────────────────┴───────┘