hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arinto Murdopo <ari...@gmail.com>
Subject HBase Region always in transition + corrupt HDFS
Date Mon, 23 Feb 2015 07:47:34 GMT
Hi all,

We're running HBase (0.94.15-cdh4.6.0) on top of HDFS (Hadoop
For all of our tables, we set the replication factor to 1 (dfs.replication
= 1 in hbase-site.xml). We set to 1 because we want to minimize the HDFS
usage (now we realize we should set this value to at least 2, because
"failure is a norm" in distributed systems).

Due to the amount of data, at some point, we have low disk space in HDFS
and one of our DNs was down. Now we have these problems in HBase and HDFS
although we have recovered our DN.

*Issue#1*. Some of HBase region always in transition. '*hbase hbck -repair*'
is stuck because it's waiting for region transition to finish. Some output

*hbase(main):003:0> status 'detailed'*
*12 regionsInTransition*
state=OPENING, ts=1424227696897, server=null*
state=OFFLINE, ts=1424227714203, server=null*
state=OPENING, ts=1424227701234, server=null*
state=OPENING, ts=1424227708053, server=null*
state=OPENING, ts=1424227701484, server=null*
state=OPENING, ts=1424227705353, server=null*
state=OPENING, ts=1424227706293, server=null*
state=OPENING, ts=1424227680569, server=null*
state=OPENING, ts=1424227680538, server=null*
state=OPENING, ts=1424227710847, server=null*
state=OPENING, ts=1424227700962, server=null*
state=OPENING, ts=1424227691774, server=null*

*Issue#2*. The next step that we do is to check HDFS file status using '*hdfs
fsck /*'. It shows that the filesystem '/' is corrupted with these
* Total size:    15494284950796 B (Total open files size: 17179869184 B)*
* Total dirs:    9198*
* Total files:   124685 (Files currently being written: 21)*
* Total blocks (validated):      219620 (avg. block size 70550427 B) (Total
open file blocks (not validated): 144)*
*  *********************************
*  CORRUPT FILES:        42*
*  MISSING BLOCKS:       142*
*  MISSING SIZE:         14899184084 B*
*  CORRUPT BLOCKS:       142*
*  *********************************
* Corrupt blocks:                142*
* Number of data-nodes:          14*
* Number of racks:               1*
*FSCK ended at Tue Feb 17 17:25:18 SGT 2015 in 3026 milliseconds*

*The filesystem under path '/' is CORRUPT*

So it seems that HDFS loses some of its block due to DN failures and since
the dfs.replication factor is 1, it could not recover the missing blocks.

*Issue#3*. Although '*hbase hbck -repair*' is stuck, we are able to run '*hbase
hbck -fixHdfsHoles*'. We notice this following error messages (I copied
some of them to represent each type of error messages that we have).
- *ERROR: Region { meta =>
hdfs => hdfs://nameservice1/hbase/plr_id_insta_media_live/1528f2884*
*73632aca2636443574a6ba1, deployed =>  } not deployed on any region server.*
- *ERROR: Region { meta => null, hdfs =>
deployed =>  } on HDFS, but not listed in META or deployed on any region
*- ERROR: Region { meta =>
hdfs => null, deployed =>  } found in META, but not in HDFS or deployed on
any region server.*
-ERROR: There is a hole in the region chain between
\x099599464:7:5;3595;8a:57868;95 and \x099;56535:4632439643a82826562:.  You
need to create a new .regioninfo and region dir in hdfs to plug the hole.
-ERROR: Last region should end with an empty key. You need to create a new
region and regioninfo in HDFS to plug the hole.

Now to fix this issue, we plan to perform this following action items:

   1. Move or delete corrupted files in HDFS
   2. Repair HBase by deleting the reference of corrupted files/blocks from
   HBase meta tables (it’s okay to lost some of the data)
   3. Or create empty HFiles as shown in

And our questions are:

   1. Is it safe to move or delete corrupted files in HDFS? Can we make
   HBase to ignore those files and delete corresponding HBase files?
   2. Any comments on our action items?

Best regards,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message