[ 
https://issues.apache.org/jira/browse/HBASE-21072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590546#comment-16590546
 ] 

stack commented on HBASE-21072:
-------------------------------

bq. Will this cause additional issues for anybody trying rollback? Or is that 
case too far gone to worry about?

Yes. Smile. We don't support rollback. Worst case, someone rolls back, tries to 
do hbck1 fixup... and it fails complaining lock file in place. Operator removes 
lock file -- they might even read the content which would point them to here -- 
and away they go.

> Block out HBCK1 in hbase2
> -------------------------
>
>                 Key: HBASE-21072
>                 URL: https://issues.apache.org/jira/browse/HBASE-21072
>             Project: HBase
>          Issue Type: Sub-task
>          Components: hbck
>    Affects Versions: 2.0.1
>            Reporter: stack
>            Assignee: stack
>            Priority: Major
>         Attachments: HBASE-21072.branch-2.0.001.patch, 
> HBASE-21072.branch-2.0.002.patch, HBASE-21072.branch-2.0.003.patch
>
>
> [~busbey] left a note in the parent issue that I only just read which has a 
> prescription for how we might block hbck1 from running against an hbase-2.x 
> (hbck1 could damage a hbase-2....Its disabled in hbase-2 but an errant hbck1 
> from an hbase-1.x install might run).
> Here is quote from parent issue:
> {code}
> I was idly thinking about how to stop HBase v1 HBCK. Thanks to HBASE-11405, 
> we know that all HBase 1.y.z hbck instances should refuse to run if there's a 
> lock file at '/hbase/hbase-hbck.lock' (given defaults). How about HBase v2 
> places that file permanently in place and replace the contents (usually just 
> an IP address) with a note about how you must not run HBase v1 HBCK against 
> the cluster?
> {code}
> There is also the below:
> {code}
> We could pick another location for locking on HBase version 2 and start 
> building in a version check of some kind?
> {code}
> ... to which I'd answer, lets see. hbck2 is a different beast. It asks the 
> master to do stuff. It doesn't do it itself, as hbck1 did. So no need of a 
> lock/version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to