5

我们有这个 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

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

下一步

  • 由于文件块数据不可恢复，似乎唯一的选择是删除完整的损坏文件（使用hadoop fs -rm或 hadoop fsck -delete /）。这将在 HDFS 级别“修复”损坏。
  • 但是，我担心删除 HDFS 文件会在 HBase 级别引入损坏，因为完整的区域文件将消失
  • 我考虑hadoop fsck -move /将损坏的文件移动到/lost+found并查看 HBase 将如何处理，但移动到/lost+found并不像看起来那样可逆，所以我也对此犹豫不决

具体问题：

我应该删除文件吗？（丢失与该区域对应的数据对我们来说是合理的。）当您手动删除 HDFS 中的 HBase 区域文件时会发生什么坏事？它只是删除数据还是会在 HBase 中引入丑陋的元数据损坏，也必须加以处理？

或者我们真的可以让情况保持原样，目前似乎有效（HBase 没有抱怨/看到腐败）？

4

3 回答 3

9

我们也遇到过类似的情况：一个 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 /确认健康状况

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

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

于 2015-06-26T23:19:09.233 回答
3

仅供参考：我决定硬着头皮手动从 HDFS 中删除损坏的文件：

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

（hdfs fsck -move不适合我，不知道为什么）

之后，我检查了 HBase 的健康状况hbck，但没有发现任何不一致的地方

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

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

问题已关闭

你的旅费可能会改变。

于 2015-06-24T21:48:17.897 回答
1

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

$ ./bin/hbase hbck -fix

-修复包括

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

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

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

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

-fix 包括 {-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
于 2017-08-24T05:29:56.127 回答