Clickhouse MergeTree异常数据处理

俊达1年前技术文章1055

说明



clickhouse mergetree的数据文件如果遇到数据损坏,可能会导致clickhouse无法启动。

本文章说明如何处理这类问题。


测试

我们先人为模拟破坏mergetree数据文件:

detach table:

ck01 :) detach table metrics;

DETACH TABLE metrics

Query id: bb7f334b-5203-4040-8282-eb45b01b1b72

Ok.

0 rows in set. Elapsed: 0.001 sec.


清空data.mrk文件

root@ck01:/data/clickhouse/clickhouse/data/local/metrics/20221129_12_12_0# ls -l
total 36
-r--r----- 1 root root 251 Dec  6 05:37 checksums.txt
-r--r----- 1 root root 129 Dec  6 05:37 columns.txt
-r--r----- 1 root root   1 Dec  6 05:37 count.txt
-r--r----- 1 root root 164 Dec  6 05:37 data.bin
-r--r----- 1 root root 176 Dec  6 05:37 data.mrk3
-r--r----- 1 root root  10 Dec  6 05:37 default_compression_codec.txt
-r--r----- 1 root root   8 Dec  6 05:37 minmax_tt.idx
-r--r----- 1 root root   4 Dec  6 05:37 partition.dat
-r--r----- 1 root root  24 Dec  6 05:37 primary.idx

root@ck01:/data/clickhouse/clickhouse/data/local/metrics/20221129_12_12_0# echo > data.mrk3



配置参数

max_suspicious_broken_parts默认为10,表示可以容忍10个part数据异常。这里我们将max_suspicious_broken_parts设置为0。

root@ck01:/data/log/clickhouse-server# cd /data/etc/clickhouse-server/config.d/

root@ck01:/data/etc/clickhouse-server/config.d# cat max_suspicious_broken_parts.xml
<?xml version="1.0"?>
<yandex>
     <merge_tree>
         <max_suspicious_broken_parts>0</max_suspicious_broken_parts>
     </merge_tree>
</yandex>

启动实例

2022.12.06 06:50:39.749105 [ 64066 ] {} <Error> Application: DB::Exception: Suspiciously many (1 parts, 592.00 B in total) broken parts to remove while maximum allowed broken parts count is 0. You can change the maximum value with merge tree setting 'max_suspicious_broken_parts' in <merge_tree> configuration section or in table settings in .sql file (don't forget to return setting back to default value): Cannot attach table `local`.`metrics` from metadata file /data/clickhouse/clickhouse/store/8a5/8a567911-82c1-402d-8e61-76dd938e89ef/metrics.sql from query ATTACH TABLE local.metrics UUID 'def88518-fd7b-418d-a7dd-6564e38bba39' (`tt` DateTime, `tags` Map(String, String), `metric` String, `value` Float64, `str_value` String) ENGINE = MergeTree PARTITION BY toYYYYMMDD(tt) ORDER BY (metric, tt) SETTINGS index_granularity = 8192, max_suspicious_broken_parts = 0
2022.12.06 06:50:39.749145 [ 64066 ] {} <Information> Application: shutting down
2022.12.06 06:50:39.749151 [ 64066 ] {} <Debug> Application: Uninitializing subsystem: Logging Subsystem
2022.12.06 06:50:39.749253 [ 64067 ] {} <Information> BaseDaemon: Stop SignalListener thread


这时候,我们发现,实例已经无法正常启动了。


解决方法


方法1:

如果可以接受数据丢失,可以将参数max_suspicious_broken_parts设置得大一些

<?xml version="1.0"?>
<yandex>
     <merge_tree>
         <max_suspicious_broken_parts>1000</max_suspicious_broken_parts>
     </merge_tree>
</yandex>


方法2:

使用force_restore_data标记文件

touch /data/clickhouse/clickhouse/flags/force_restore_data
clickhouse-server --config-file /data/etc/clickhouse-server/config.xml --daemon



启动后,可以从detached_parts表中查看detach的part信息:

ck01 :) select * from detached_parts where table='metrics';

SELECT *
FROM detached_parts
WHERE table = 'metrics'

Query id: c6f61369-259d-4c07-b730-7572c3095bad

┌─database─┬─table───┬─partition_id─┬─name─────────────────────────────┬─disk────┬─reason──────────┬─min_block_number─┬─max_block_number─┬─level─┐
│ local    │ metrics │ 20221129     │ broken-on-start_20221129_12_12_0 │ default │ broken-on-start │               12 │               12 │     0 │
└──────────┴─────────┴──────────────┴──────────────────────────────────┴─────────┴─────────────────┴──────────────────┴──────────────────┴───────┘

1 row in set. Elapsed: 0.002 sec.


异常数据被移到了detached目录

ls detached/
broken-on-start_20221129_12_12_0




如果不允许丢失数据,需要从备份中恢复数据。

可以使用alter table attach part命令从备份中将part恢复出来。


相关文章

Redis 命令行 redis-cli 介绍

前言redis-cli 是 Redis 自带的命令行工具,是运维和开发人员常用的工具,本篇文章将介绍它的使用技巧和一些有趣的功能。1. 连接 Redis 服务redis-cli 默认连接的是 127....

PostgreSQL 会话管理

说明当数据库发生持续的 CPU 使用率打高时,数据库中很可能正在跑一些大查询或者较复杂的 SQL,如果不及时处理很可能会影响到业务,此时我们需要通过查询会话找到 “罪魁祸首” 并 kill 掉它,然后...

CDH实操--CDH集成Trino(三)

CDH实操--CDH集成Trino(三)

1、将parcel包放到对应下载目录将parcel包放到/var/www/html/trino目录下修改httpd配置文件新增parcel文件类型然后通过命令启动httpd服务:systemctl s...

 MySQL性能优化(十)in参数列表过长导致的性能问题

MySQL性能优化(十)in参数列表过长导致的性能问题

有时候可能有人会问:where条件中使用in和or有什么区别,哪种写法性能更好?in参数个数有没有限制?下面就是一个由于in参数列表过长导致的性能问题。一个例子当时使用的是mysql 5.6版本SEL...

Elasticsearch数据生命周期如何规划

Elasticsearch中的open状态的索引都会占用堆内存来存储倒排索引,过多的索引会导致集群整体内存使用率多大,甚至引起内存溢出。所以需要根据自身业务管理历史数据的生命周期,如近3个月的数据op...

Ranger-hdfs插件部署

Ranger-hdfs插件部署

部署在两个namenode节点解压插件cd /opt/hadooptar -xzvf ranger-2.4.0-hdfs-plugin.tar.gz -C /opt/cd /opt/ranger-2....

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。