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<[email protected]> 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
