由于一系列不幸的事件,一个程序从 /dataN/dfs/dn/current/BP-XXXXXXX/current/finalized/subdirN/subdirN/blk_NNNNNNNNNN
进入 /tmp/blk_NNNNNNNNNN
我没有任何记录从程序来告诉在哪里原始的 subdirN/subdirN/
目录是。
有没有办法根据fsimage文件、块文件本身或其他元数据来确定此块应该位于何处?
我可以通过查找相应的*.meta文件来恢复一些块,但是仍然有一些漏洞。复制使我免于最糟糕的情况,但我仍然缺少5个我想尝试恢复的“任务关键型”文件。
从 hdfs fsck /
我可以知道丢失的块是什么,它们属于什么hdfs文件,但我不能知道它们应该放在块池中的什么位置。 hdfs fsck / -delete
不是解决办法。我不想删除东西,我要尽我最大的努力恢复文件,因为我有块。我只是不知道他们去哪了。 $ hdfs version Hadoop 2.6.0-cdh5.4.4
2条答案
按热度按时间pqwbnv8z1#
这是我最后为解决这个问题所做的。这在所有情况下都不起作用,但在我的情况下起作用。
我利用了这样一个事实,即输入文件分隔符是“行输入记录分隔符”,hadoop中的块可以与丢失的块连接起来。数据的顺序对我来说并不重要,只是所有的行都在那里。
我只是检索了文件的所有块(包括已移动到新位置的hdfs中不再存在的块),将它们连接在一起。从hdfs中删除了文件并执行了
hdfs -put
以恢复内容。不是很完美,但很有效。这使我不必对任何东西进行反向工程,也证明了恢复数据的最简单方法。
谢谢你的帮助。我相信这里有有用的信息给下一个有这个问题的人。
np8igboo2#
不确定是否可以手动恢复,但您可以尝试。
细分曲面的计算方式如下:
DatanodeUtil.idToBlockDir(...)
使用以下代码:如果文件是手动移动的,fsimage可能仍然包含块id,请使用
hdfs oiv
要转换的命令fsimage
至XML
并通过删除的文件名获取blockid。