我们有这个 HBase 集群:30 多个节点、48 个表、40 TB 以上的 HDFS 级别、复制因子 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
此外,似乎我们仍然可以从损坏区域文件的非丢失 block 中查询数据(据我认为我能够根据区域的开始和结束行键进行检查)。
后续步骤
- 因为文件 block 数据不可恢复,似乎唯一的选择是删除完整的损坏文件(使用
hadoop fs -rm
或hadoop fsck -delete/
).这将“修复”HDFS 级别的损坏。 - 但是,我担心删除 HDFS 文件会在 HBase 级别引入损坏,因为整个区域文件都将消失
- 我考虑过
hadoop fsck -move/
将损坏的文件移动到/lost+found
并查看 HBase 如何处理,但移动到/lost +found
是 not as reversible as it seems ,所以我对此也很犹豫
具体问题:
我应该只删除文件吗? (丢失与该区域对应的数据对我们来说是合理的。)当您手动删除 HDFS 中的 HBase 区域文件时会发生什么坏事?它只是删除数据还是会在 HBase 中引入丑陋的元数据损坏,而这些元数据损坏也必须加以处理?
或者我们真的可以让情况保持原样,这在目前似乎有效(HBase 没有提示/看到腐败)?
最佳答案
我们有类似的情况:5 个丢失的 block ,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
关于hadoop - HBase 集群在 HDFS 上有损坏的区域文件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31011148/