[
https://issues.apache.org/jira/browse/HADOOP-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560753#action_12560753 ]
jimk edited comment on HADOOP-2668 at 1/19/08 5:06 PM:
----------------------------------------------------------------
It didn't occur to me that migration was the way to fix the missing version file.
From HMaster.java(894, 5):
{code}
throw new IOException(
"file system not correct version. Run hbase.util.Migrate");
{code}
I also figured we should just auto-migrate this one case of a missing version file (If in future,
version file goes missing, I'd think it the job of hbsfck recreating it, rather than migration?).
Suppose you have a file system that has not been migrated? (i.e. regions are stored in
{code}/hbase/hregion_nnnnnnn{code}) The master would start up write the version file and then
proceed to recreate the root and meta regions because they aren't under
{code}/hbase/-ROOT-{code} and {code}/hbase/.META.{code} respectively.
Additionally the first thing the migrate tool does is look for the version file. If it finds it and
the version number matches, it figures that the file system has been upgraded already
and does nothing.
But I'm fine w/ forcing users to run the migration. It needs to be better documented and added
to the bin/hbase script with verb 'migrate' I'd say.
Agreed. How about this changing this patch to update bin/hbase and add documentation
(where ?)?
I tried to run the migration but it wants to connect to a HMaster. That ain't going to work (Cluster
won't start because no version file... can't migrate because cluster ain't up...).
It tries to connect to the master to ensure it isn't running (uses HBaseAdmin.isMasterRunning())
We wouldn't want to do a upgrade with the cluster running.
was (Author: jimk):
It didn't occur to me that migration was the way to fix the missing version file.
From HMaster.java(894, 5):
{code}
throw new IOException(
"file system not correct version. Run hbase.util.Migrate");
{code}
I also figured we should just auto-migrate this one case of a missing version file (If in future,
version file goes missing, I'd think it the job of hbsfck recreating it, rather than migration?).
Suppose you have a file system that has not been migrated? (i.e. regions are stored in
=/hbase/hregion_nnnnnnn=) The master would start up write the version file and then
proceed to recreate the root and meta regions because they aren't under
=/hbase/-ROOT-= and =/hbase/.META.= respectively.
Additionally the first thing the migrate tool does is look for the version file. If it finds it and
the version number matches, it figures that the file system has been upgraded already
and does nothing.
But I'm fine w/ forcing users to run the migration. It needs to be better documented and added
to the bin/hbase script with verb 'migrate' I'd say.
Agreed. How about this changing this patch to update bin/hbase and add documentation
(where ?)?
I tried to run the migration but it wants to connect to a HMaster. That ain't going to work (Cluster
won't start because no version file... can't migrate because cluster ain't up...).
It tries to connect to the master to ensure it isn't running (uses HBaseAdmin.isMasterRunning())
We wouldn't want to do a upgrade with the cluster running.
[hbase] After 2643, cluster won't start if FS was created by an older hbase version
-----------------------------------------------------------------------------------
Key: HADOOP-2668
URL:
https://issues.apache.org/jira/browse/HADOOP-2668Project: Hadoop
Issue Type: Bug
Components: contrib/hbase
Reporter: stack
Assignee: stack
Priority: Blocker
Fix For: 0.16.0
Attachments: migrate.patch
Hbase now checks for a version file. If none, it reports a version mismatch. There will be no version file if the hbase was made by a version older than r613469
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
