背景

我们CH整体部署情况如下，1分片4副本：

发现CH01和CH02两个节点的ch无法正常启动。错误异常如下：

2023.04.27 16:03:16.309390 [ 1988 ] {} <Error> Application: Coordination::Exception: No node, path: /clickhouse/tables/01-01/***/replicas/cluster01-01-01/metadata: Cannot attach table .from metadata file /mnt/data/clickhouse/metadata/***/***.sql from query ATTACH TABLE *** ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/***', '{replica}') *** SETTINGS index_granularity = 8192: while loading database*** from path /mnt/data/clickhouse/metadata/***

从报错信息中可以看出，表副本信息在ZK中丢失了，导致整个CH启动不起来。

排查步骤

1、查看Zookeeper信息，发现确实丢失两个副本信息，如下：

只剩下3和4两个副本，丢失1，2副本。我们来看下具体的本地磁盘数据，是否还在：

ZK中为何丢失node1、node2的副本，已经无从查起。来看如何来恢复，首先我们要把CH启动起来。 2、执行如下命令，停掉CH。

systemctl stop clickhouse-server.service

3、针对有问题的表，将CH的data及meta数据进行备份、

tmp文件夹最终需要从CH的data目录中移出，可以把它移动到/mnt/data/ch-data-tmp/下。记得将data和meta数据都要进行备份，形如：

1文件夹中放data备份数据，2文件夹下放meta备份数据。 4、启动CH

systemctl start clickhouse-server.service

此时CH将能正常启动，日志如下：

5、针对有问题的表，重新创建ReplicatedMergeTree表 新建副本表的时候，CH会自动将别的节点上的数据同步过来。那么就存在一个问题，对于我们备份的数据我们要如何处理？可能备份的数据与同步的数据还有交集。我们来对比下同步后的数据目录和备份的区别（左侧为当前，右侧为历史备份）：

整体的文件part目录是差不多的，只有最近的4月份还没有进行完全合并完，导致两边差异。尝试进行历史备份数据恢复：

alter table ods_**_* attach PART '202205_0_5142_115';

当然你也可以以分区的粒度进行数据添加。

alter table ods_**_* attach PARTITION '202205';

总结

至此完成丢失副本恢复的工作，一并将备份的数据也恢复了。