On Fri, Aug 12, 2011 at 5:37 PM, Geoff Hendrey <[email protected]> wrote:
> Notice that endkey "X" doesn't exist anywhere as a startkey. I want to
> fix this by doing a put that will replace start/end pair {B,C} with
> {B,D} to "unlink" the orphaned row {C,X} from the ".META.".

You should remove the {C,X} row first (I see that you do

Is it really an X as in an end row that sorts after 'D'?  If so, that
could be a problem.  You'll have entries in this {C,X} region that
will be outside of the new {C,D} boundary.

If it is outside of the boundary, then we need to be careful putting
back the store files after you make the new {C,D} region.  We need to
not put back storefiles with entries that sort after the 'D'.

> I have
> already backed up all the data in the orphaned region. Then I intend to
> delete the unlinked orphaned row {C,X} and subsequently PUT back all the
> backed up data back into the table.
>

This should work w/ above caveat



> My concerns is that the "ENCODED" column in .META. encodes the endrow.
> Is this the case? (In which case I need the encoding function in order
> to make my proposed fix work).
>

When you create a region, it will do the encoding for you.  See here
http://hbase.apache.org/xref/org/apache/hadoop/hbase/HRegionInfo.html#225

You should be able to create a region in the shell and toString the
output to find the encoding as in:

hbase> import org.apache.hadoop.hbase.HRegionInfo
hbase> hri = HRegionInfo.new(tablename, startrow, endrow)
hbase> puts hri.toString()

You might have to mess around to get byte array version of string and
row names (Use to_java_bytes if you have strings)

St.Ack

>
>
> Looking for someone to ack that my repair strategy is viable. Please
> advise.
>
>
>
> -geoff
>
>

Reply via email to