8

将我们的小型 Cloudera Hadoop 集群升级到 CDH 5 后,删除文件不再释放可用存储空间。即使我们删除的数据多于添加的数据,文件系统也会不断填满。

集群设置

我们在物理专用硬件上运行一个四节点集群,总存储容量约为 110 TB。4 月 3 日,我们将 CDH 软件从 5.0.0-beta2 版本升级到 5.0.0-1 版本。

我们以前以大约 700 GB/天的速度将日志数据以纯文本格式放在 hdfs 上。在 4 月 1 日,我们改为将数据导入为 .gz 文件,这将每日摄取率降低到约 130 GB。

由于我们只想将数据保留到一定年龄,因此每晚都有删除过时文件的工作。这样做的结果过去在 hdfs 容量监控图表中是清晰可见的,但现在已经看不到了。

由于我们每天导入的数据比我们删除的数据少约 570 GB,人们预计使用的容量会下降。但是,自从集群软件升级以来,我们报告的 hdfs 使用量一直在不断增长。

问题描述

运行hdfs hadoop fs -du -h /给出以下输出:

0       /system
1.3 T   /tmp
24.3 T  /user

考虑到导入文件的大小,这与我们期望看到的一致。使用 3 的复制因子,这应该对应于大约 76.8 TB 的物理磁盘使用量。

相反,运行hdfs dfsadmin -report结果不同:

Configured Capacity: 125179101388800 (113.85 TB)
Present Capacity: 119134820995005 (108.35 TB)
DFS Remaining: 10020134191104 (9.11 TB)
DFS Used: 109114686803901 (99.24 TB)
DFS Used%: 91.59%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0

在这里,DFS Used 报告为 99.24 TB,这是我们在监控图表中看到的。所有这些数据是从哪里来的?

我们尝试过的

我们首先怀疑的是垃圾的自动清空功能不起作用,但似乎并非如此。只有最近删除的文件在垃圾箱中,一天后它们会自动消失。

我们的问题似乎与执行 hdfs 元数据升级但未最终确定会发生的情况非常相似。我认为在这些版本之间进行升级时不需要这样做,但仍然“以防万一”执行了这两个步骤。

在本地文件系统的DN存储卷上,`previous/finalized'下有很多数据。我对 hdsf 的实现细节知之甚少,不知道这是否重要,但这可能表明最终确定的某些内容不同步。

我们很快就会用完集群上的磁盘空间,因此非常感谢任何帮助。

4

1 回答 1

13

我在我们的集群上发现了一个类似的问题,这可能源于升级失败。

首先确保在namenode上完成升级

hdfs dfsadmin -finalizeUpgrade

我发现数据节点由于某种原因根本没有最终确定它们的目录。

在您的数据节点上,您应该看到以下目录布局

/[mountpoint}/dfs/dn/current/{blockpool}/current

/[mountpoint}/dfs/dn/current/{blockpool}/previous

If you have not finalized the previous directory contains all data that was created before the update. If you delete anything it will not remove it - hence your storage never reduces.

Actually the most simplest solution was sufficient

Restart the namenode

Watch the log of the datanode, you should see something like this

INFO org.apache.hadoop.hdfs.server.common.Storage: Finalizing upgrade for storage directory

Afterwards the directories will be cleared in the background and the storage reclaimed.

于 2014-04-25T18:15:01.133 回答