HDFS上区域文件已损坏的HBase群集

Question

我们有这个HBase集群：30多个节点，48个表，40多个HDFS级别的TB，复制因子2。由于两个节点上的磁盘故障，我们在HDFS上有一个损坏的文件。

当前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 /）。这将"修复"HDFS级别的损坏
• 然而，我担心删除HDFS文件会导致HBase级别的损坏，因为完整的区域文件将消失
• 我考虑过hadoop fsck -move /将损坏的文件移到/lost+found，看看HBase会如何处理，但移动到/lost+found并不像看起来那样可逆，所以我对此也很犹豫

具体问题：

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

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

Answer 1

我们遇到了类似的情况：HBase表有5个丢失的块，5个损坏的文件
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 /确认健康状态

注意：完全停止堆栈以重置缓存非常重要
（停止所有服务节俭、hbase、动物园管理员、hdfs，然后按相反顺序重新启动）。

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

Answer 2

FYI：我决定咬紧牙关，用手动删除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

-修复包括

1. 将运行不一致性的标准检查
2. 如果需要，会对桌子进行维修
3. 如果需要，将对区域进行维修。区域在修复期间关闭

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

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

-fixMeta，当HDFS中不存在相应的区域时删除元行，如果HDFS中存在新的元行，而meta中不存在这些区域，则添加新的元列。

-修复程序包括｛-fixAssignments&-fixMeta｝

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

有几类表完整性问题属于低风险修复。前两个是退化（startkey==endkey）区域和向后区域（startkey>endkey）。通过将数据搁置到临时目录（/hbck/xxxx）中，可以自动处理这些问题。第三个低风险类别是hdfs区域空穴。这可以通过使用：进行修复

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

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

-repairHoles包括｛-fixAssignments-fixMeta-fixHdfsHoles｝

 $ ./bin/hbase hbck -repairHoles