[
https://issues.apache.org/jira/browse/HBASE-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747602#comment-13747602
]
stack commented on HBASE-8348:
------------------------------
Should this be in there still:
+ options.addOption(new Option("check", "checkForHFileV1", false, "Checks
for HFileV1 in "
+ + " the hbase.rootdir (or provided directory)."));
If the v1 check does not work in 0.96, is there anything done when the check
runs?
Thanks for making the log. The usage though needs a bit of work. It says:
usage: $bin/hbase upgrade [-check] [-dirTocheck <arg>] [-execute] [-h]
[-ns] [-zk]
The problem w/ the above is that you do not convey that check and execute are
mutually exclusive. This is normally done by doing:
upgrade --check|--execute|--help
You can override the usage that is output by Option, IIRC?
If --check now does nothing, it should be removed.
Make this option shorter because it makes less room for the option descriptions
-- call it 'dir' only?:
-dirTocheck,--dirToCheckForHFileV1 <arg> Relative path of directory to
The example usage is good but again, if v1 check does not work, it should not
be included here:
To check for HFileV1 in hbase.rootdir:
$ bin/hbase upgrade --check
... it will only confuse.
Anything on meta flush issue?
Should upgrade check for WAL files?
The log is nice. Thanks for making it. Helps w/ review.
I'd say hide the zk, ns, and help options? Or at least try and not have them
show in the main usage line. They only confuse. You want operators to focus
on check or execute. Besides, if ns or zk or already upgraded, don't the calls
to ns or zk become noops (would be good to check) so there is no harm running
both each time? If so, remove this distinction I'd say. More options means
more likely folks will be confused.
I someone wants to run the v1 check against a running 0.94 instance, how do
they do that now? They do it out of a 0.96 binary?
In the process check, do we check for zk? If zk is down, how does it get
'udated'?
Good stuff.
> Polish the migration to 0.96
> ----------------------------
>
> Key: HBASE-8348
> URL: https://issues.apache.org/jira/browse/HBASE-8348
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.95.0
> Reporter: Jean-Daniel Cryans
> Assignee: rajeshbabu
> Priority: Blocker
> Fix For: 0.96.0
>
> Attachments: HBASE-8348-approach-2.patch,
> HBASE-8348-approach-2-v2.1.patch, HBASE-8348-approach-2-v2.2.patch,
> HBASE-8348-approach-2-v2.3.patch, HBASE-8348-approach-3.patch,
> HBASE-8348_trunk.patch, HBASE-8348_trunk_v2.patch, HBASE-8348_trunk_v3.patch,
> log
>
>
> Currently, migration works but there's still a couple of rough edges:
> - HBASE-8045 finished the .META. migration but didn't remove ROOT, so it's
> still on the filesystem.
> - Data in ZK needs to be removed manually. Either we fix up the data in ZK
> or we delete it ourselves.
> - TestMetaMigrationRemovingHTD has a testMetaUpdatedFlagInROOT method, but
> ROOT is gone now.
> Elliott was also mentioning that we could have "hbase migrate" do the HFileV1
> checks, clear ZK, remove ROOT, etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
