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

Question

我们有这个HBase集群:30多个节点,48个表,HDFS级别40 + 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

我们遇到了类似的情况:5个丢失的块,5个损坏的HBase表文件.
HBase版本:0.94.15
发行版:CDH 4.7
OS: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不适合我，不知道为什么）

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

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

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

问题已结束

你的旅费可能会改变。