当前HDFS状态

hdfs fsck /输出的摘录，显示损坏的HBase区域文件：

/user/hbase/table_foo_bar/295cff9c67379c1204a6ddd15808af0b/n/ae0fdf7d0fa24ad1914ca934d3493e56: 
 CORRUPT blockpool BP-323062689-192.168.12.45-1357244568924 block blk_9209554458788732793
/user/hbase/table_foo_bar/295cff9c67379c1204a6ddd15808af0b/n/ae0fdf7d0fa24ad1914ca934d3493e56:
 MISSING 1 blocks of total size 134217728 B

  CORRUPT FILES:        1
  MISSING BLOCKS:       1
  MISSING SIZE:         134217728 B
  CORRUPT BLOCKS:       1

The filesystem under path '/' is CORRUPT

丢失的数据无法恢复（磁盘损坏）。

当前HBase状态

另一方面，根据HBase，一切都很好，花花公子

hbase hbck说：

Version: 0.94.6-cdh4.4.0
...
 table_foo_bar is okay.
   Number of regions: 1425
   Deployed on:  ....
...
0 inconsistencies detected.
Status: OK

此外，似乎我们仍然可以查询来自损坏区域文件的非丢失块的数据（据我认为我能够根据该区域的开始和结束行键进行检查）。

后续步骤

由于文件块数据无法恢复，因此似乎唯一的选择是删除完整的损坏文件（使用hadoop fs -rm或hadoop fsck -delete /）。这将＆＃34;修复＆＃34; HDFS级别的腐败。
但是，我担心删除HDFS文件会导致HBase级别的损坏，因为完整的区域文件将会消失
我考虑hadoop fsck -move /将损坏的文件移至/lost+found并查看HBase如何处理该问题，但转移到/lost+found是not as reversible as it seems，所以我是对此也犹豫不决

具体问题：

我应该删除该文件吗？（丢失对应于该区域的数据对我们来说相当合适。）当您在HDFS中手动删除HBase区域文件时会发生什么不好的事情？它只是删除数据还是会在HBase中引入丑陋的元数据损坏，还需要处理？

或者我们真的可以保持现状，这似乎目前有效（HBase不抱怨/看到腐败）？

Answer 1

我们遇到了类似的情况：5个丢失的块，5个损坏的HBase表文件 HBase版本：0.94.15
发行版：CDH 4.7
操作系统：CentOS 6.4

恢复说明：

切换到hbase用户：su hbase
hbase hbck -details了解问题的范围
hbase hbck -fix尝试从区域级别的不一致中恢复
hbase hbck -repair尝试自动修复，但实际上增加了1个不一致的数量
hbase hbck -fixMeta -fixAssignments
hbase hbck -repair这次表得到了修复
hbase hbck -details确认修复

此时，HBase运行正常，添加了其他区域，并取消引用了损坏的文件。但是，HDFS仍然有5个损坏的文件。由于它们不再被HBase引用，我们将其删除：

切换到hdfs用户：su hdfs
hdfs fsck /了解问题的范围
hdfs fsck / -delete仅删除损坏的文件
hdfs fsck /确认健康状况

注意：完全停止堆栈以重置缓存很重要（停止所有服务 thrift，hbase，zoo keeper，hdfs 并以相反的顺序重新启动它们。）

[1] hbck命令的Cloudera页面：
http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/admin_hbck_poller.html

Answer 2

供参考：我决定咬紧牙关并用以下方法从HDFS手动删除损坏的文件：

hdfs dfs -rm /user/hbase/table_foo_bar/295cff9c67379c1204a6dd....

（hdfs fsck -move对我不起作用，不确定原因）

之后，我用hbck检查了HBase的健康状况，但没有检测到任何不一致

$ hbase hbck
...
0 inconsistencies detected.
Status: OK

所以在我们的例子中，手动删除区域文件没有引入HBase损坏，如果我理解正确，这很好，但令人困惑。（我希望这不会适得其反，腐败在以后的某个时间点也不会显现出来）

问题已关闭

您的里程可能会有所不同。

Answer 3

如果找到区域级别的不一致，请使用-fix参数指示hbck尝试修复它们。遵循以下步骤：

$ ./bin/hbase hbck -fix

-fix包括

运行不一致的标准检查。
如果需要，可以对表进行修复
如果需要，可以对地区进行维修。修复期间地区关闭。

所以在运行-fix之前如果想分别修复单个区域级别的不一致

-fixAssignments（相当于0.90 -fix选项）修复未分配，错误分配或多次分配的区域。

-fixMeta在HDFS中不存在相应区域时删除元行，如果它们在HDFS中存在而不在META中，则添加新的元行。

-fix包括{-fixAssignments＆amp; -fixMeta}

 $ ./bin/hbase hbck -fixAssignments
 $ ./bin/hbase hbck -fixAssignments -fixMeta

有几类表完整性问题是低风险修复。前两个是退化（startkey == endkey）区域和后向区域（startkey＆gt; endkey）。这些是通过将数据边缘化到临时目录（/ hbck / xxxx）来自动处理的。第三个低风险类是hdfs区域漏洞。这可以通过使用：

-fixHdfsHoles选项用于在文件系统上制作新的空区域。如果检测到漏洞，您可以使用-fixHdfsHoles，并且应该包含-fixMeta和-fixAssignments以使新区域保持一致。

 $ ./bin/hbase hbck -fixAssignments -fixMeta -fixHdfsHoles

-repairHoles includes {-fixAssignments -fixMeta -fixHdfsHoles}

 $ ./bin/hbase hbck -repairHoles

HDFS

当前HDFS状态

当前HBase状态

后续步骤

3 个答案: