rollback to 0.20

[Dave Latham <la...@davelink.net>]

The HBase book ( http://hbase.apache.org/book/upgrading.html ) states,

> This version of 0.90.x HBase can be started on data written by HBase 0.20.x or HBase 0.89.x. There is no
> need of a migration step. HBase 0.89.x and 0.90.x does write out the name of region directories differently --
> it names them with a md5 hash of the region name rather than a jenkins hash -- so this means that once
> started, there is no going back to HBase 0.20.x.

Does this mean that if we prevent region splits, that it would be
possible to rollback to HBase 0.20.6, or are there other data format
changes that would prevent that?

Dave

Re: rollback to 0.20

[Stack <st...@duboce.net>]

On Thu, Apr 28, 2011 at 1:58 AM, Jan Lukavský
<ja...@firma.seznam.cz> wrote:
> and therefore we have new region names in 0.20.6. Does this mean we can
> upgrade and downgrade hbase versions without any worries? Or do we need to
> take care of something else?
>

Region naming is the only difference between the data format in 0.20.x
and 0.90.x.

You should be fine just starting up a 0.90.x
(http://hbase.apache.org/book/upgrading.html).

St.Ack

Re: rollback to 0.20

[Jan Lukavský <ja...@firma.seznam.cz>]

Hi all,

we were forced to backport to  0.20.6 the new format of region names (we 
had region hash collisions), that is we have 
HRegionInfo.encodeRegionName as follows

   /**
    * @param regionName
    * @return the encodedName
    */
   public static String encodeRegionName(final byte [] regionName) {
     String encodedName;
     if (hasEncodedName(regionName)) {
       // region is in new format:
       // <tableName>,<startKey>,<regionIdTimeStamp>/encodedName/
       encodedName = Bytes.toString(regionName,
           regionName.length - MD5_HEX_LENGTH - 1,
           MD5_HEX_LENGTH);
     } else {
       // old format region name. ROOT and first META region also
       // use this format.EncodedName is the JenkinsHash value.
       int hashVal = Math.abs(JenkinsHash.getInstance().hash(regionName,
                                                             
regionName.length,
                                                             0));
       encodedName = String.valueOf(hashVal);
     }
     return encodedName;
   }

and therefore we have new region names in 0.20.6. Does this mean we can 
upgrade and downgrade hbase versions without any worries? Or do we need 
to take care of something else?

Thanks,
  Jan

On 27.4.2011 20:13, Stack wrote:
> On Wed, Apr 27, 2011 at 11:08 AM, Dave Latham<la...@davelink.net>  wrote:
>> The HBase book ( http://hbase.apache.org/book/upgrading.html ) states,
>>
>>> This version of 0.90.x HBase can be started on data written by HBase 0.20.x or HBase 0.89.x. There is no
>>> need of a migration step. HBase 0.89.x and 0.90.x does write out the name of region directories differently --
>>> it names them with a md5 hash of the region name rather than a jenkins hash -- so this means that once
>>> started, there is no going back to HBase 0.20.x.
>> Does this mean that if we prevent region splits, that it would be
>> possible to rollback to HBase 0.20.6, or are there other data format
>> changes that would prevent that?
>>
> This is the only data format change.
>
> What you suggest -- preventing new regions being created -- should
> work but I've not tried it Dave.
>
> St.Ack

Re: rollback to 0.20

[Stack <st...@duboce.net>]

On Wed, Apr 27, 2011 at 11:08 AM, Dave Latham <la...@davelink.net> wrote:
> The HBase book ( http://hbase.apache.org/book/upgrading.html ) states,
>
>> This version of 0.90.x HBase can be started on data written by HBase 0.20.x or HBase 0.89.x. There is no
>> need of a migration step. HBase 0.89.x and 0.90.x does write out the name of region directories differently --
>> it names them with a md5 hash of the region name rather than a jenkins hash -- so this means that once
>> started, there is no going back to HBase 0.20.x.
>
> Does this mean that if we prevent region splits, that it would be
> possible to rollback to HBase 0.20.6, or are there other data format
> changes that would prevent that?
>

This is the only data format change.

What you suggest -- preventing new regions being created -- should
work but I've not tried it Dave.

St.Ack