[
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-2668
> Project: 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.
