hadoop:fsck结果显示丢失的副本

umuewwlo  于 2021-06-03  发布在  Hadoop
关注(0)|答案(1)|浏览(558)

有人能告诉我如何修复丢失的复制品吗?

总尺寸:3447348383 b
目录总数:120
文件总数:98
总块数(已验证):133(平均块大小25919912 b)
最小复制块数:133(100.0%)
复制块上:0(0.0%)
复制块下:21(15.789474%)
错误复制的块:0(0.0%)
默认复制因子:3
平均块复制:2.3834586
损坏的块:0
缺少副本:147个(46.37224%)
数据节点数:3
机架数量:1

根据指南,
损坏或丢失的数据块是引起关注的最大原因,因为这意味着数据已经丢失。默认情况下,fsck会留下损坏或丢失块的文件,但您可以告诉它对这些文件执行以下操作之一:
•使用-move选项将受影响的文件移动到hdfs中的/lost+found目录。文件被分解成连续的区块链,以帮助您可能尝试的任何打捞工作。
•使用-delete选项删除受影响的文件。文件删除后无法恢复。
这里我的问题是如何找出受影响的文件?我已经与hive合作,以获得所需的输出而没有任何问题。它是否会影响查询处理的性能/速度。
当做,
拉吉

ujv3wf0j

ujv3wf0j1#

丢失的复制副本应该可以随着时间的推移自我修复。但是,如果要将它们移动到lost+found,可以使用:

hadoop fsck / -move

或删除它们:

hadoop fsck / -delete

如果您只想标识复制块不足的文件,请使用:

hadoop fsck / -files -blocks -locations

这将提供很多细节,包括预期/实际块复制计数的列表。

相关问题