一个 Clickhouse 集群磁盘损坏恢复数据的案例

通过一个故障案例，理解 ClickHouse 分布式机制。

作者：张宇，爱可生DBA，负责数据库运维和故障分析。擅长 ClickHouse、MySQL、Oracle，爱好骑行、AI、动漫和技术分享。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 1500 字，预计阅读需要 5 分钟。

业务场景

在日常运维的某个系统下，有一套 4 分片 3 副本的高可用分布式的 ClickHouse 集群。当前分片的每个节点的数据量为 5.6TB。

故障背景

监控发现其中的一个节点无法使用，后续排查发现 5 块磁盘已经损坏，Raid10 也无法保证数据完整，导致数据目录全部重新换成新的磁盘，而且使用的是传统机械盘，速度慢。现在联系厂商更换磁盘，需要停用此节点，等厂商更换完毕之后，需要配合恢复数据。

恢复思路

ClickHouse 的集群是一个分布式的集群，每个分片的数据不同，所有分片的数据加起来才是一份完整的数据，每个分片副本的数据是相同的，这就是 ClickHouse 数据的高可用。

本次也是非常典型的故障，硬件做了 Raid10，但是 Raid10 磁盘基本上全部坏掉了，导致 Raid10 离线也无法使用，最后更换了所有的磁盘，导致整个数据目录变成了空的。

因为此副本为一个分片中的其中一个副本，还有其他两个副本在线，所以业务使用无影响，而且我们可以通过其他副本里面的数据开始恢复此副本的数据。

恢复的基本原理： 同一个分片里面 Zookeeper 路径相同的表，但是副本名不同。数据是会自动验证同步的，所以我们只需要重建表，并且保证 Zookeeper 地址一致，副本名不一致，就会自动开始同步数据，直到两个副本数据完全一致。

副本之间是如何同步数据的呢？

Zookeeper 里面存放了副本数据文件 parts 的路径。如果当前副本没有这些 parts 就会通过 Zookeeper 得到其他副本的 parts 路径，然后通过 9009 端口进行数据文件的传输，然后恢复数据。

如下是官方的原理图：

查看节点是否存在残留数据

• clickhouse-1：同一个分片正常副本
• clic